What are the implications of using PROGMEM?

Question

With large amounts of text variables, I've found it necessary to store them in the Flash memory using PROGMEM. What are the positive and negative consequences of storing large variables in Flash (using PROGMEM) vs SRAM vs EEPROM on the Arduino?

score 12 · Accepted Answer · answered Apr 10 '13 at 18:48

12

Here is a quick comparison of FLASH, EEPROM and SRAM on the AtMega328, the microcontroller in many of the current Arduino boards (excluding Due, Leonardo, older Arduinos and some other compatible boards).

FLASH: 10,000 write/erase cycles. Access is fast, but slower than SRAM. Code accesses via PROGMEM.
EEPROM: 100,000 write/erase cycles. Access is slooooooow, in milliseconds. Relatively complex access procedure.
SRAM: Unlimited write/erase cycles. Access is very fast, 2 clock cycles. Direct access by code.

So, the key hypothetical negative consequence of using PROGMEM is the 10,000 write cycle limit. The key negative consequence of using EEPROM is the complexity of code to read/write/copy data. SRAM, it's just very limited in capacity.

answered Apr 10 '13 at 18:48

Anindo Ghosh

50,188
8
103
200

Where are you getting the info about the EEPROM access? From a bit of [looking](http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=57649&start=0) [about](http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=30020&view=previous), it looks like EEPROM *reads* take something like ~5 clock cycles. *Writing* is slow, but not reading. – Connor Wolf May 24 '14 at 12:33
OP wants to *store* lots of stuff. – Anindo Ghosh May 24 '14 at 12:36
Yeah, but is that write once, read many, or the inverse? "Text variables" are likely something that are specified at compile time, burned to the device, and never changed after that (e.g. menu text or sommat). – Connor Wolf May 24 '14 at 12:49
I read the *store* in the question as "store at compile/upload time". If a variable is meant to be used read/write at run time, it definitely should not be stored in FLASH. Isn't there the additional restriction that FLASH cannot be modified without erasing the whole page first? – microtherion May 24 '14 at 12:50
... text *variables* not string constants. – Anindo Ghosh May 24 '14 at 13:37

score 2 · Answer 2 · answered Apr 10 '13 at 22:55

The primary implication is that you can not modify the information stored in PROGMEM. You'll also take a (very small) performance hit as the string needs to be copied 1 byte at a time.

Wear-out of the FLASH isn't a (primary) concern since in order to make changes to your program you'd have to re-program the FLASH anyway.

With the IDE 1.x introduction the F() macro was included. This makes it easier to keep strings in PROGMEM.

For example instead of using: Serial.print("Hello World!");

You can now use:

Serial.print(F("Hello World!");

Note, that F() isn't a function, it is just a macro so its use is somewhat limited.

score 1 · Answer 3 · answered Apr 10 '13 at 18:32

PROGMEM is best used for immutable data. If you're going to keep rapidly changing variables, I would just store it in the SRAM. On the other hand, if you want to have some immutable text variables (eg stuff to be displayed) that won't be fetched too often, PROGMEM is a great idea.

Regarding EEPROM -- try to save this for persistent stuff. IIRC it is slower to fetch data from EEPROM over SRAM/PROGMEM. Usually I (and others) copy data from EEPROM over to SRAM (Even the official example does this) before using it.

What are the implications of using PROGMEM?

3 Answers3