This may be old hat to folks that are used to AVR/GCC and whatnot programming in environments like the AXON.
Now, please don't get me wrong, this is NOT a criticism of any of these; I think they are all great. I have a large amount of my first real robot complete in but a few weeks of spare time programming and construction because of the quality of all the above mentioned items...I love what one can do in a short time with these high quality tools.
However, here is the issue I faced tonight: I had two global variables:
int behavior_timer;
int behavior;
No matter what I did when I set behavior_timer to a value it did not stay 'set' coming out of the subroutine in which it was set. I pored over the code and finally proved with inspection and many many strategically placed rprintf's that the value simply was not making it out of the subroutine.
I scratched my head a lot on that one.. did I run out of variable space? changed some stuff around, nope...
I finally speculated, being an old compiler-writer, that since I had not used a global variable name that long that it might be related to that since a compiler has to actually keep extra information around for those versus variables local to a function. I shortened the name to
int behav_timer
and viola' works like a charm.
I assume the symbol table entries are not set up for names that long or in some fashion it lost the true reference to the variable. I am not using any optimizations so it should be a pretty straightforward compilation.
I found it interested and if you run into the same problem it might save you some time. Keep your global variable names short and try to keep them unique in the first 8 characters or so to avoid problems like this. I didn't spend any more time diagnosing so it might apply to the local names as well, but I haven't had that problem yet.
Thanks
Doug
