I'm recognizing while my program grew, that all of a sudden a static var in a function isn't static anymore. In total I use about 20 vars static distributed in several functions. From my observations I could assume that ther maybe too many vars static but I'm really not sure.
Does anybody have a clue whether this assumption is reasonable or other ideas why static vars may be modified for any other reasons?
Arduinos have very little RAM, so there is a practical limit to how many variables you can have. There is no specific limit to the number you can have though, whether static or not.
Okay, my fault not posting the code take my appologies. However I'm unable to post, since the code (1300 somewhat lines) exeeds the forum limit obviosly by far. I have to find another solution...
However, I recognized, that other and additionaly introduced vars work nicely...
If it's too big to include in a post, your next option is to attach it to a post. Your last option is to post it on a public file-sharing site and post a link to it.
I highly appreciate your willingness to assist! Attached is the code.
Hava a look at the "int RTC (int command)" function. There are two static vars, yearRTC and yearRtc. One returns the correct value (see comments) the other one not because it is actually cleared after returning from the function. I don't have a clue.
Both vars used (consequently same treatment in all lines) are returning different values to main. During all my experiements, I also inserted some code sending the values via serial.print and it sends at the start of the next function call a 0 (zero). Funny though, I as well observed a shift from one var to another when experimenting with the code. Before the yearRTC was affected I had another var affected. By that time I thought it might be some prob with too many statics within one function and moved the code to another function. After that the moved var was fine but now yearRTC got corrupted.
My guess is that you have a pointer an array index somewhere else in the program that is going wildly out of range. However, it's worth checking the amount of free memory, because that's an easy thing to do. This is the code I use:
// Find out how much free memory we have
unsigned int getFreeMemory()
{
uint8_t* temp = (uint8_t*)malloc(16); // assumes there are no free holes so this is allocated at the end
unsigned int rslt = (uint8_t*)SP - temp;
free(temp);
return rslt;
}
It is fast, but if you are using the String class or anything else that uses dynamic memory, then it isn't reliable. There are other ways of getting free memory, based on calling malloc in a loop, that work in those cases.
dc42:
There are other ways of getting free memory, based on calling malloc in a loop, that work in those cases.
The approaches based on calling malloc() in a loop will tell you the largest contiguous piece of free memory in the heap but would surely not tell you how much space is available for the stack. In cases where the sketch makes little/no use of dynamic memory, the remaining stack space is far more important so the code you posted is what is needed.
@dc42 after wondering above I found that piece of code. That's where the "4652 bytes" left cam from. However, thanks for confirming me.
You're making a good point that somewhere in the program somthing might get out of range. I'm going to check on that as far as possible. Hypotheses is that it may be related to the Ethercard library from Jeelabs for ENC28J60. I already recognized that this lib, means the buffer used inside is subject to cause strange things...