next topic »

[Reply #15 on:]

Why then would the following string not be deleted when the void loop() exits and returns:

Would it make any difference if it was? The loop() function gets called again, and the string is needed again.

I'm just confused about how the Serial.print() function operates when you give it a string directly.

The compiler makes a pass through your code, and finds all constant strings, among other things, and places them at specific locations in SRAM. The call is then changed to print the string at that address. It does this for all constant strings, not just those used by Serial.print().

So would there be a difference between the above code, and the following code concerning how the 'string' array is saved (or deleted from memory).

No. The compiler is smart enough to do what that code sample does, for all strings. You can look at the assembler output for the two cases. I think that you'll find that they are very similar, if not identical. Different addresses, perhaps, in SRAM, but the same result - the Serial.print() function is called with the address where the string to print is stored.

Would this code clear the character array to_print[] from memory after the loop() function has finished executing?

No.

[Reply #16 on:]

1) A totally different approach relates to the content of the log file.
Have the log file be a data file, like xxx.CSV not a report, use comma instead of multiple blanks as delimiter, save space on SD card too.
also no headings, keep time in unixtime only.

Write a simple program to display the data or used a spread sheet program.

2) Additionally, now you know where "ERROR CODE #nnnn" comes from, instead of strings.

3) Reduce memory requirements (and have better code too) move duplicate code to a function:
i.e.
for(int i=1;i<=10;i++)
      {
       digitalWrite(green_led, HIGH);
       digitalWrite(red_led,HIGH);
       delay(500);
       digitalWrite(green_led,LOW);
       digitalWrite(red_led,LOW);
       delay(500);
      }

+++++++++++++++++
Then there is the difference between
the code generated for: if(ECHO_DEBUG)
as opposed
#if ECHO_DEBUG
 ...
#endif

The #if...#endif either generates the code if  ECHO_DEBUG is true otherwise doesn't generate code but
doesn't generate code to do the test which occurs at runtime.

It's not much, but sometimes every bbyte counts.
++++++++++
While we're on compiler directives ( #if, #endif) using that is a better approach than commenting out code like with calibrate. Defining a compile time variable to determine if the code is generated or not.  This also reduces chances for errors and forgetting to comment out one of several sections.

Let us know how you did.

[Reply #17 on:]

Great! Thanks for all the feedback.  Keeping an eye on available memory is certainly a good motivator to code better.  I've cleaned up alot of the slop and I can now run the code with a good bit of extra RAM (I used the memoryfree.h library for this).  I didn't get around to doing it, but if I expand the code some more and memory once again becomes an issue, then I will probably store most of the long strings (like the file header, etc...) in the program memory, and just poll it when needed.  using #if, #end if is certainly a good idea as well; no use in having the extra stuff floating around if ECHO_DEBUG is false...

Two questions still as to how I could do the following:
(1)

Defining a compile time variable to determine if the code is generated or not.

The arduino GUI will usually tell you when the code compiles incorrectly, but with my running-out-of-RAM problem, the GUI would say everything would compile correctly, but still not work.  Is 'defining a compile time variable' a way to check for deeper errors?

(2)

You can look at the assembler output for the two cases.

  Are there any good programs that will help to look at the assembler output/machine code, and show you where stuff is coming from/going?  I can imagine such a tool would be very useful in understanding the guts of a compiler, or coding in general.

Thanks again for all the tips!
-Nick

[Reply #18 on:]

Hi all

Am having a few problems with the SD Library. Have just added a #include at the top of an existing script and the complier takes a fit, doesnt like it at all. I am making a few changes to the rsteppercontoller script, i am adding an sd card function that i have been working on. Any ideas, i have tried compiling in an earlier version but no luck.
Clive

[Reply #19 on:]

Have just added a #include at the top of an existing script and the complier takes a fit, doesnt like it at all.

You've done something wrong.

That's probably not much help to you, but I'm sure you can figure out why it isn't possible to provide a more helpful answer based on the information you've provided so far.