How to reduce compiled size of redundant PSTR("aaa") strings

Projects Programming
1

I'm pushing the limits of PROGMEM on my Nano, largely due to strings needed for user interaction. In a few cases, I have the same string 2-3 times in the program, and I feel like there has to be a way to only have them in PROGMEM once.

To be clear, here is a trivial example of what I mean. Maybe I could put them into EEPROM? Speed is not a concern. My understanding is that reads from EEPROM have no limit, as opposed to the "write cycle" limit of EEPROM. Just want to be absolutely clear on that last question. Thanks!

void setup() {
  while (!Serial);
  Serial.begin(9600);
}

void loop() {
  func01();
  func02();
}

void func01() {
  char s[200];
  strcat_P(s, PSTR("Some longish string"));
  //do stuff with s
}

void func02() {
  char s[200];
  strcat_P(s, PSTR("Some longish string"));
  //do other stuff with s
}
2

Just make those long strings global constants

const char longString[] PROGMEM = "Some longish string";

void setup() {
  while (!Serial);
  Serial.begin(9600);
}

void loop() {
  func01();
  func02();
}

void func01() {
  char s[200];
  strcpy_P(s, longString);
  //do stuff with s
}

void func02() {
  char s[200];
  strcpy_P(s, longString);
  //do other stuff with s
}
3

Except that the compiler’s not stupid, and if you have multiple variables/arrays/structures of type const, and they have the exact same contents, then it will automatically fold them onto a single copy in Flash for you.

So...

Serial.println(“Some very long duplicated string.”);
Serial.println(“Some very long duplicated string.”);

Only one copy of that string in flash and copied into one copy in RAM during initialisation.

Interestingly though the F() wrapper seems to interfere with that, so you get two copies in Flash, but none copied at initialisation into RAM.

This is on the ProMini, not sure how much it relates to Nano.

4

"This is on the ProMini, not sure how much it relates to Nano."

Same '328P processor chip on both, so the compile should be the same.

5

Thank you, I figured there would be a well-known solution...

6

pcbbc:
Except that the compiler’s not stupid...

I initially hoped something like what you're saying, a compiler-built string table, would be done automatically, but it does not seem to be the case with PSTR()...

void setup() {
  while (!Serial);
  Serial.begin(9600);

  char message[1000];

  // Sketch uses 1592 bytes
  strcpy_P(message, PSTR("My redundant string which is long enough to try to optimize"));

  // Sketch uses 1684 bytes with this line added
  strcat_P(message, PSTR("My redundant string which is long enough to try to optimize"));
  
  // Sketch uses 1754 bytes with this line added
  strcat_P(message, PSTR("My redundant string which is long enough to try to optimize"));
  
  // Sketch uses 1848 bytes with this line added
  Serial.println("My redundant string which is long enough to try to optimize");
  
  // Compiler optimized, as pcbbc states:
  // Sketch uses 1856 bytes with this line added
  Serial.println("My redundant string which is long enough to try to optimize");
  
  Serial.println(message);
}

void loop() {}
7

PSTR() is the same as the F() macro referenced in reply #2

#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))