5
\$\begingroup\$

I know on some MCUs its possible to save data directly on program memory (flash memory). AVRGCC compiler uses "PROGMEM" keyworkd, MPLAB C18 uses a similar one with the same effect. However, what's the advantage of having data on program memory?

Maybe because those MCUs have a Harvard arquitecture and so read data from program memory is faster than read it from data memory? Is it "really so much faster" that it's worth to use it?

Thanks!

\$\endgroup\$
7
\$\begingroup\$

These microcontrollers have very limited RAM. So if you want a look-up table, it makes sense to store the large, constant data in program flash instead of the precious RAM.

\$\endgroup\$
  • 2
    \$\begingroup\$ It's important to note that you will ALWAYS store constants, and the rest of the program, in flash. Whether you /additionally/ store the data in RAM is up to you. \$\endgroup\$ – joeforker Feb 28 '11 at 14:21
6
\$\begingroup\$

You have two options for constant data on these flash microcontrollers.

  1. Load from flash when needed (PROGMEM)
  2. Load from flash into ram on program startup (not PROGMEM). The C compiler does this for you automatically if you forget to use PROGMEM because data is normally read/write in C.

It is much slower to load data from the program memory compared to loading from ram, but when you only have 128 bytes of ram, and the data has to be stored in the flash anyway, it pays off.

AVRs also tend to have, say, 128 bytes of EEPROM, and whatever flash memory you didn't need for your program. The microcontroller can then program its own flash memory to save measurements and settings. The flash memory is more plentiful than the EEPROM but, unlike EEPROM which usually appears to be rewritable 1 byte at a time, the Flash must be erased and rewritten in blocks.

\$\endgroup\$
4
\$\begingroup\$

If an MCU doesn't have a separate EEPROM area to save data in, then yes, you can save persistent data to an area of the flash memory not used by program code. This is only good for data that is updated infrequently (such as configuration data or user preferences), since there is a limit to the number of times you can rewrite the flash (typically a minimum of 10,000 erase/write cycles). The advantage to saving data in this way is that it won't be lost when the MCU loses power. Without some sort of non-volatile storage, you would need to have a battery-backed up RAM to save data during power shutdown.

The second reason for allowing a program to write to the flash, is that it allows programs to be updated remotely in the field. To do this, you need a portion of the program to be resident all of the time (the part that will write the new code to the updateable portion of the flash memory), and a means to download the updated code (e.g. Bluetooth, cellular, etc.). You want to make sure the always-resident portion of the code is as bug-free as possible, since it is harder to update that.

\$\endgroup\$
  • \$\begingroup\$ The "second reason" is usually called a bootloader. \$\endgroup\$ – Kevin Vermeer Feb 26 '11 at 21:52

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.