While trying to debug my code I wrote a function that accepted an unsigned int a parameter.
So far so good but, I needed to call another function with the address of this parameter as its parameter.
The code is simpler, trust me:
- Code: Select all
void write_ee2prom(unsigned int uINT)
{
ext_uint = uINT;
//Note that at this point, ext_uint and uINT are the same value
apd_reply_ram(&ext_uint); // THIS ONE WORKS CORRECTLY
apd_reply_ram(&uINT); //PROBLEM IS HERE
}
I stripped away all the non relevant stuff in the code to show where it fails.
If I call the function above with a value of 0x1234, the pointer to the address is correct and has 0x234 in it.
If I do the same thing with &uINT it passes something else rather than the address of uINT. The contents of that address are not 0x1234
It's been a long time but afaik C supports pointing to local variables even if it is a risky thing to do.
In my case it's not so risky
1) I'm calling a routine with it rather than returning a value.
2) The called routine does not store the value, it uses it to get the data from it and send it to the RS232 port then returns. It has no global vriables of its own.
3) This is sequential code and not multi threaded. It's impossible for the local value to be reallocated before the other routine is finished with it.
It's riskier to make a global variable in my case since that takes up more memory and chews into the stack which kills the CPU process if it gets too big. I have 256 bytes of ram and I uses 185 bytes of global variables. Compiler uses 16 and the flash writes use 8. Doesn't leave much room for parameter passing or nested calls.
Yes the above code is using just as much as a global would but it's because I wanted to demonstrate the error and also it gets released once the functions are complete. A global wouldn't.