13
\$\begingroup\$

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?

\$\endgroup\$
11
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ Where are you getting the info about the EEPROM access? From a bit of looking about, it looks like EEPROM reads take something like ~5 clock cycles. Writing is slow, but not reading. \$\endgroup\$ May 24 '14 at 12:33
  • \$\begingroup\$ OP wants to store lots of stuff. \$\endgroup\$ May 24 '14 at 12:36
  • \$\begingroup\$ 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). \$\endgroup\$ May 24 '14 at 12:49
  • \$\begingroup\$ 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? \$\endgroup\$ May 24 '14 at 12:50
  • \$\begingroup\$ ... text variables not string constants. \$\endgroup\$ May 24 '14 at 13:37
2
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy