ROBOTC 3.5: Global Vs. Local Variables and the Debugger

One comment

This is the first in a series of posts that will explain the new functionality behind the latest ROBOTC update. Beginning with ROBOTC 3.5 with all of the new functionality towards becoming an ANSI-C compliant language has brought some changes that may confuse veteran ROBOTC users. This week we’ll take a look at how global and local variables work in ROBOTC.

In previous ROBOTC releases, the compiler (the engine that converts your code from C-language to machine language) would treat all variables as “Global Variables” and would allocate (assign memory to) every variable when the program was compiled. This method caused issues because it would not allow the compiler to understand re-entrant functions (i.e. functions that could call themselves). This functionality was limiting because it prevent a key computer science concept called “Recursion” which is the ability to have a function call itself repeatedly (but not infinitely). Recursion is very useful when dealing with sorting data or calculating a series of data in different algorithms (one example: calculating a Factorial value – 5! = 5*4*3*2*1)

Example of Recursion: Calculating a Factorial Value

In ROBOTC 3.5, the compiler’s functionality has been extended in order to support recursive functions by supporting the concept of “Call Stack” variables. The idea of the Call Stack is that ROBOTC will now store local variables and return addresses of functions onto a Call Stack – This unlocks the ability to have recursive functions and variables that are truly “local”. With the Call Stack, ROBOTC is able to keep track of multiple calls of the same function and coordinate all of the variables so there’s no accidental overwriting of data or multiple copies of the same variables to keep track of – Everything automatically done by the compiler when the program is run!

A visual look at a “Call Stack” (from Wikipedia)

With the call stack, ROBOTC’s firmware assigns the memory address of local variables when they’re declared in the code (as opposed to compile time as before). Variables are allocated and discarded on the stack as needed – users do not need to modify their code to take advantage of this functionality. Programs do still need to specify a variable’s type and size ahead of time however. (i.e. no dynamically sized arrays)

Three different ways to allocate variables.

There is one big difference when it comes to debugging – users will see the old “Variables” display is now split between “Global” and “Local” variables in the ROBOTC Debugger. Because the ROBOTC IDE doesn’t know where the variable will be stored in the “call stack”, there’s no way to accurately know where the local variables are on the stack at any one time. What this means is that you will not be able to view your local variables during run-time like in previous versions of ROBOTC. This is a limitation of professional IDEs (Visual Studio, Eclipse, AVR Studio) that also support recursion and variable stacks. The new extended ANSI-C functionality brings ROBOTC close to the same level as those development environments including the same limitations when debugging.

Hey where are all of my variables?

The good news is that users have two options for debugging their program’s variables:

  1. Suspend your program by using the “Step” button– When the program execution is suspended, the IDE is able to display all of the current local variables for the current function/task selected. This will not display every local variable in your program, but only the currently executing function/task.

    When the program is suspended, ROBOTC can load the “Call Stack” and display Local Variables accurately.

  2. Use Global Variables– Because Global Variables are allocated at compile time, the ROBOTC IDE knows the memory location of every Global Variable and can keep track of these variables in the “Global Variables” debugger window. All Global Variables will be continuously updated as the program is executed.

    With Global Variables, ROBOTC know the address of the Variable at all times, so it is able to always display the value.

We understand some of the frustration that ROBOTC users are experience with the new ROBOTC 3.5 update with all of the new functionality, and we apologize for any issues. Our overall objective is to make ROBOTC as close to a true ANSI-C programming environment to make sure students and users are learning proper coding techniques.

As we continue to refine our implementation with the latest version of ROBOTC, we still are committed to addressing any reported issues and would love to hear from you if you are having any problems – Please send us a note using our Ticketing system at or directly at

Written by Tim Friez

October 24th, 2012 at 5:18 pm