Memory types

[Dan Moos]

Ok, I'm in the thick of my guitar pedal router project, and finding my memory needs are large.  I think I have more than enough in the atMega328 I'm using, if I'm clever about it.

My question relates to the longevity of flash and eeprom memory. I know in the long term they are an expendable resource, i.e., after enough writes, it eventually fails. Correct me if I'm wrong, but that sounds like I don't want to have my program write to the flash memory ever really. I was thinking it would be a good place for any global constants, but I presume that that means they'd still be written to flash every time the program runs. It'd really be nice  if those constants were written just once when the code gets flashed. Is there a way? Is the compiler smart enough to do this on its own? Am I worried about nothing here?

Next, what about eeprom? Does it have ba useful life expectancy?

Finally, I plan to use an SD card for storing settings that only need to be accessed at power up. But I've never used one before, and I'm curious if an SD card can be read fast enough to treat like a RAM source.

The gist of my questions can be boiled down to: what are the pros and cons of the various memory pools available in this chip?

[igendel]

The "longevity" limits on Flash and EEPROM are on the number of write operations (on the ATmega328P, I think the safe limit is 10K for the Flash and 100K for the EEPROM - and that's for each individual byte/page, not writes in general). Reading is free and harmless. Your running code will not write to these memories unless you instruct it to specifically, so there really isn't reason to worry.

The EEPROM is generally a good place to save settings, assuming they don't take too much space, and that you don't change them too often. For perspective, if you rewrite a setting in the EEPROM once an hour, it may start failing after 11.4 years... just be careful with your programming and make sure you really do write only when you have to; an infinite-writing-loop bug will write your EEPROM to death within minutes.

[Dan Moos]

I know those memory pools will only get written to if I purposely do so, but that's my possible intent.

Here is a specific desire. I need a number of strings for interface purposes. I'd like them to flash just once at programming time. I realize I can hard code them into my lcd.print() function calls, but I can think of times when using a constant to store these might be nice. Say, an array of strings. I'm not really wondering if that's a good coding idea (valid, but different question). I'm curious if there is a way to have these constants written to flash when the program it's first flashed. Maybe just using "const" mashes that happen? Seems like that would be the clever way, but I have no idea if that's how it works.

[igendel]

I see.

First of all, here's a little tip: After compilation, the IDE (Atmel Studio, Arduino) will show you how much Flash and how much RAM your code occupies. You can use this information to verify where your new consts are stored.

If I remember correctly, the compiler is smart enough to put simple const variables in Flash automatically. Strings are a different matter though, and on top of that there are C-style strings, C++ strings etc... there are probably experts here who can give you specific information.

Either way, whatever you write is burned onto the Flash only during programming.

[Someone]

Here is a specific desire. I need a number of strings for interface purposes. I'd like them to flash just once at programming time. I realize I can hard code them into my lcd.print() function calls, but I can think of times when using a constant to store these might be nice. Say, an array of strings. I'm not really wondering if that's a good coding idea (valid, but different question). I'm curious if there is a way to have these constants written to flash when the program it's first flashed. Maybe just using "const" mashes that happen? Seems like that would be the clever way, but I have no idea if that's how it works.

The flash is one continuous memory space with program code and constants, your compiler will be putting constants in there for you already (and will probably be able to determine which variables are never set if you get slack with the CONST keyword). It gets slightly more complicated when you then want to update just the flash constants in the field or dynamically, but thats possible if you know their addresses and formats.

[sleemanj]

When you program your ATMega328, the entire program instructions, and any data it requires (initialisation data for variables, constants) is written into the flash memory (aka program memory)

When your code runs, the instructions are read from the flash memory, memory on the stack (ram) is allocated for the variables (inc "const" declared ones where applicable but they can be optimised to just "hardcode" by the compiler where it is beneficial) and the data is copied from the flash memory into that allocated stack to initialise your variables (& constants if applicable).¹

Because of Harvard architecture, the running code can not *normally* access data in the flash memory, only in the ram.

You can however tell the compiler "look, really, you can just leave this thing in flash memory, don't allocate any memory on the stack for it, just give me the address in the program memory for it, I know I can't access it easily, but leave it there and I'll grab it only when I need it". 

You do that using "PROGMEM" and the various functions available in avr-libc for accessing progmem stored data.

http://www.nongnu.org/avr-libc/user-manual/pgmspace.html
http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
http://playground.arduino.cc/Main/PROGMEM
http://www.arduino.cc/en/Reference/PROGMEM

Note that in Arduinoland there is also the "F()" macro and "__FlashStringHelper" which is essentially an abstracted way of using PROGMEM for strings - provided the thing you are giving it to understands what to do with a __FlashStringHelper, which means it knows how to use PROGMEM stored data.



¹ - Note here well, the initialisation data is stored in flash and copied to ram.  If you have 'char *foo = "Hello World";' then Hello World is stored in flash, and copied into ram, taking equal memory in both places.  Even if it's 'const char *foo' the compiler will almost certainly not do any on-the-fly shuttling between flash and ram for you, it will take memory in both places.

[sleemanj]

One final note, some time ago I made an "easy to use" web page which can analyze your compiled program and tell you about it's memory usage in some detail to help you find areas for improvement.

http://sparks.gogo.co.nz/avr-ram-use.html

Of course it just uses standard tools in the avr-gcc distribution to do it, but it's easier than remembering how to drive those tools ever time I need to :-)

[obiwanjacobi]

I used the EEPROM to store the 'factory defaults' and have an external serial (I2C) EEPROMto store the user's data (presets and other settings) - they're small and cheap. If you detect a corruption in the external eeprom (use checksums) you can warn the user and overwrite with the factory defaults from EEPROM. If the part has become faulty, you only have swap out the ext. EEPROM and run the 'Restore Factory Defaults' function. Works great IMHO. Another bonus is that you can have a bigger (or smaller) size storage (how many presets would you like to store and how many bytes does one preset take + leave some room for future enhancements).

[2c]

[Kilrah]

I'm part of a project creating open source software for R/C model radio controllers, and the original hardware platform we started on is based on an atmega64. All the settings are stored in the internal EEPROM, and only written after a 5-second delay from when the last change happened (i.e. when setting a few things up your changes will likely be grouped in a single write). The project has been running for about 8 years now with a few thousand users, and we've never heard of an MCU dying of excessive writes. We've had a number of reports of faulty MCUs but never related.

That's what it's made for really.

We make extensive use of PROGMEM to store all the strings in FLASH and have them read directly from there to save RAM by not having them copied in it. If there is no reason to change them beyond a change of functionality (which would require reflashing new firmware anyway) that's where those things belong.

Basically you never write to flash, you write user settings to EEPROM only when necessary, and any other thing that needs writing at runtime (variables) are obviously in RAM.

It's hard to point you to what you may be misunderstanding without knowing more about how you intend to do things, but it does seem you're kinda confused and expecting to use other types of memories as you'd use RAM because you don't have enough, which would be "wrong" for several reasons. If you need fast runtime storage it needs to be in RAM. One reason is that other types of memory are VERY slow in comparison especially for writes.