Saving memory with macros (put strings from RAM to PROGMEM)

[VdesmedT]

Hey there,  I wondered if someone had a less chatty version of the Wireless69Hex library which apparently consumes 330bytes of memory, of which I suspect most are strings used for debugging. I can of course just remove those if(DEBUG) Serial.println... statements (or at least shorten them) but I dont wanna mess with the code and miss the next updates. Shall I start a branch for that ? Any other suggestion ?

[Felix]

You can move them in the flash by using PROGMEM. I should have done that in the first place ... If I ever refactor the libs I will put the strings in flash instead of ram.

[VdesmedT]

That's indeed a good option but we will then need to initialise the flash and the initializing code will take the same strings along...  So we will need a separate sketch to initialise the flash that needs to be run first on every node..  I'm I missing something ?

[TomWS]

That's indeed a good option but we will then need to initialise the flash and the initializing code will take the same strings along...  So we will need a separate sketch to initialise the flash that needs to be run first on every node..  I'm I missing something ?

You are correct IF the flash Felix was referring to was the outboard flash memory.  Fortunately, he was referring to the internal flash memory.  There is an easy way to move string constants to this space without doing any 'programming'...

Say you have the following code:

Code Select Expand

   Serial.println("I really don't like this being in data memory!");

If you use the 'F()' macro, you will move the string to PROGMEM as Felix suggested:

Code Select Expand

   Serial.println( F("I really don't like this being in data memory!") );
   Serial.println( F("Ahhh, this is MUCH better!") );

Note that the entire string is contained within:  F(...) so you'll have the double closing parenthesis at the end.  Also note that this will ONLY work with string constants that are retrieved as a block.  Consequently this will NOT work with sprintf() function, as in:

Code Select Expand

  Serial.print( F("This will work!") );
  sprintf(buf, F("This will NOT work!") );
  Serial.print(buf);

Tom

[VdesmedT]

I was not aware of that macro. Thanks !

[EloyP]

Also note that this will ONLY work with string constants that are retrieved as a block.  Consequently this will NOT work with sprintf() function, as in:

Code Select Expand

  Serial.print( F("This will work!") );
  sprintf(buf, F("This will NOT work!") );
  Serial.print(buf);

It should work if sprintf_P() is used instead. I say *should* because I am probably the only person here that does not use Arduino libraries or "language" to program his Moteinos/ATmegas, so I am not 100% sure. But, in the AVR libc world (which Arduino uses, I believe), if one #includes <avr/pgmspace.h> and uses sprintf_P() then the format string is expected to be in program memory. (An additional nice addition is that %S in the format string fetches the vararg string from program memory, unlike %s which fetches it from RAM.

Cheers!

[TomWS]

<snip>

It should work if sprintf_P() is used instead. I say *should* because I am probably the only person here that does not use Arduino libraries or "language" to program his Moteinos/ATmegas, so I am not 100% sure. But, in the AVR libc world (which Arduino uses, I believe), if one #includes <avr/pgmspace.h> and uses sprintf_P() then the format string is expected to be in program memory. (An additional nice addition is that %S in the format string fetches the vararg string from program memory, unlike %s which fetches it from RAM.

Cheers!

Thanks, Eloy!  That's useful information, especially with the constrained data memory in the 328P.

Tom

[Felix]

Good info EloyP!

[TomWS]

<snip>

It should work if sprintf_P() is used instead. I say *should* because I am probably the only person here that does not use Arduino libraries or "language" to program his Moteinos/ATmegas, so I am not 100% sure. But, in the AVR libc world (which Arduino uses, I believe), if one #includes <avr/pgmspace.h> and uses sprintf_P() then the format string is expected to be in program memory. (An additional nice addition is that %S in the format string fetches the vararg string from program memory, unlike %s which fetches it from RAM.

Cheers!

Thanks, Eloy!  That's useful information, especially with the constrained data memory in the 328P.

Tom

I tried this and sprintf_P does work from PROGMEM but you can't use the F() macro to define the format string.  You have to declare the format string as:

Code Select Expand

PROGMEM const char fmt[]="BBB Power is low! Current reading is:%d, should be %d\n";

...
    sprintf_P(buf, fmt, sysResetADC, SYS_RESET_POWER);

Thanks again for the tip!
Tom

[EloyP]

Hi Tom,

I tried this and sprintf_P does work from PROGMEM but you can't use the F() macro to define the format string.  You have to declare the format string as:

Code Select Expand

PROGMEM const char fmt[]="BBB Power is low! Current reading is:%d, should be %d\n";

...
    sprintf_P(buf, fmt, sysResetADC, SYS_RESET_POWER);

As far as I can tell, the F() macro, which I understand is provided by the Arduino include file(s), is similar (though apparently not interchangeable based on your testing) to the AVR libc PSTR() macro. You use it in a way similar to how you showed the F() macro being used:

printf_P(PSTR("I am in program memory\n") );

sprintf_P(buffer, PSTR("%S and myself are in program memory\n"), PSTR("this string") );

I put all my strings in program memory as putting them in RAM consumes both RAM and program space memory; a total waste of resources.

Cheers!

Eloy Paris.-