I am having lot of trouble with compiling and then running in the Uno R3( ATMEGA328P-P). I suspect it is to do with variables and memory. I am reading in float 50 temperature readings from the VTemp_A= analogRead(A0);
and coverted in to array Temp100_A*= equation* as they are read in - they are "printed " to the COMS port successfully. After the 50 values populate the array in a for loop , I print then out in another for loop and get rubbish. ... for (int i=1 ; i<51; i++) { // Print Array Serial.print("i=");Serial.print(i);Serial.print(" initial Array Temp100_A=" ); Serial.println(Temp100_A ); * } // Print Array* ... I suspect it is running out of memory - on compilation the summary message is "Binary sketch size: 5,970 bytes ( of a 32,256 byte maximum)" I would of though this is well short of the maximum with the boot loader taking up only a small amount of memory. Previously I have had this problem and just changed code to simplify it to "make it work" by progressive simplification- but I need a better way of know when I approach the "limit". Is there a rule of thumb I need to know ? Is " "Binary sketch size: xxxxx bytes ( of a 32,256 byte maximum)" a real guide? Look forward to advice / links, Regards, Peter.
Is "
"Binary sketch size: xxxxx bytes ( of a 32,256 byte maximum)" a real guide?
Yes and it's accurate to the byte. So the answer is your programs crap. Quit blaming other people who know what they are doing and always assume that it's your fault.
Binary sketch size: xxxxx bytes ( of a 32,256 byte maximum)" a real guide?
Yes, but it's a guide to the amount of flash memory used by the sketch, which is only slightly related to how much RAM memory is used by the sketch for variables/etc. (an Uno only has 2k of RAM. 51 long or float variables would use up 204 bytes.) (and as others have pointed out, it has NOTHING to do with possibly buggy array indexing code written by the user.)
If you upgrade to 1.6.x, you'll get some additional information about RAM consumption. However, this number is less "real", since it does NOT include things like local variables in functions.
Arrays are zero based, just like every other civilized language, you're reading it like it's one based, and hence reading off the end (or wiring off the end earlier - if you have array of length 50, and you x[50]=1;, you've corrupted the memory and skulls expect undefined behavior ). This is c, there is no array bound checking. One if the most common kinda pof bug in c.
Always suspect buffer overruns when Arduino code crashes, hangs, or resets itself.