Here's an example of what is happening using simpler variables:
char *global;
void setup() {
char text[10];
sprintf(text, "12345");
global = text;
Serial.begin(9600);
}
void loop() {
char local[10];
sprintf(local, "abcdefg");
Serial.print("Global = ");
Serial.println(global);
Serial.print("Local = ");
Serial.println(local);
delay(1000);
}
That results in:
Global = cdefg
Local = abcdefg
Global = cdefg
Local = abcdefg
Global = cdefg
Local = abcdefg
...
which is not what you were expecting.
So what exactly is going on here?
Ok. So we have a "global" pointer where we think we're going to store some data. Then in setup() we create a variable, into which we put "12345". We then assign that variable to the "global" pointer.
Then in loop() we make another variable, put "abcdefg" into it, and print it along with the "global" pointer.
But surely that should work, right?
Wrong.
It's all down to how the variables are created, as well as what the variables are.
Local variables (which are declared inside a function), like "text" or "local" in the code above only actually exist while you're inside that function, or within functions called by that function (and so on down the chain). As soon as you leave the function the variables are gone. The space for local variables is declared "on the stack". The stack is a flexible storage area that grows and shrinks. You can think of it as a stack of coins where each coin is a variable. When you enter the function coins are put on the top of the stack of coins, one for each variable, and when you leave the function the coins are removed again. There should always be the same number of coins removed as were put on, otherwise the stack will grow and grow until the system crashes.
So the "text" variable, which is assigned to "global" is being lost as soon as setup() exits. But you assigned it to global, though, so it's stored there isn't it?
No.
Now we look at what the variables are.
Doing that kind of assignment is perfectly fine when you're dealing with simple numbers, where the number itself is stored in the variable - you assign the variable and it copies the content. That's not what a character array (read: string) is. Remember, the Arduino is an 8-bit CPU. That means that only 8 bits of data can be stored in any one location. "byte" and "char" types are stored as such. "int" variables are made up of two memory locations as they are 16-bit values, but the compiler understands those and deals with them as a single number. But what is a string of characters? That's a chunk of 8-bit values. You can't store that lot in a single 8-bit value, nor in a 16-bit "int" value. So instead the variable just contains the "where", not the "what" of the variable. Instead of the variable containing "12345", it contains, say, the number 1736, which is the address of a memory location. That memory location contains the value "1", and the string continues from there, with 1737 having "2", 1738 having "3", etc.
So when you assign a pointer variable to another you're not copying the content of the string, only the address at which that string is located in memory.
And... that string is located in the stack, so the memory will be "lost" when the function returns, and re-used by the next function to be called - hence it is being overwritten by "cdefg" as the "local" variable now occupies the same memory area.
So... what can you do to work around it?
Well, there's three possibilities:
- Use global variables instead of local variables
Global variables are always going to be there wherever you are in the program. Their addresses won't change, and they won't get overwritten by other data. They can make your program a little more messy though and harder to understand.
- Copy the data
Only applicable if you don't mind modifying the library (or other destination of the data). Instead of just storing the pointer in the library you have a separate character array waiting to receive the data. Then instead of a simple assignment (a = b) you copy the content of the data (strcpy(a, b)). The destination character array has to be big enough to accept the data you are sending, and this can be wasteful of memory if you're allocating more than you really need most of the time.
- Make your local variables "static".
static char text[10];
Static variables are stored like global variables (in the same block of memory), and are treated the same way as far as their memory is concerned, however their "scope" (where the name of the variable is "known" about) remains local. The memory for the string is permanently allocated and won't be released when you exit the function, protecting your data. It does waste memory though as even when you're not using the variable it's memory is "locked". Also, static variables retain their values across calls to the same function, which can both be good and bad if you're not expecting it.
Now, what if the values you are working with don't change? They're just static strings that you send to the library at different times? Well, those shouldn't even be in RAM at all. You should be storing them in flash. That's a whole other can of worms though that I won't even go into here - just go look for the many tutorials on flash strings on the web.