Poll: do you use Arduino EEPROM?
Many (but not all) models of Arduino have some EEPROM storage that persists even when the power is off. http://arduino.cc/en/Reference/EEPROM
Question: have you ever used EEPROM storage in your projects, and if so, how much? A few bytes? Hundreds or thousands of bytes? None?
I’m trying to understand how much of an impediment it be if a new (strictly optional) feature needed, say, 10-20 bytes of EEPROM storage. Since some microcontrollers have no EEPROM (I’m looking at you, Arduino Due, and I’m not smiling), we obviously can’t depend on it. But it might be useful, so I’m curious how much of your existing EEPROM storage you’re already using.
Me, I’ve only ever used a couple of bytes of EEPROM storage to record the “current mode” of projects I have that can do multiple different animations which I can change with a button press.
By using EEPROM to store the “current mode”, I can turn the project off, and then back on again, and have it ‘remember’ which animation it was running before.
My total usage: never more than four bytes in a project.
In my non-Arduino AVR projects I use EEPROM all the time. I define structs and vars with EEMEM attribute. Great for setting initial config values. On Arduino I have a tougher time because the Arduino uploader doesn’t upload EEPROM, just flash, so there’s the copying of a flash struct to EEPROM in setup(). I think EEPROM is underutilized by Arduino users in general because of this and the rather simplistic EEPROM Arduino library.
I use EEPROM in a similar way to the “current mode” you described above. I keep track of a “current mode” per segment, with a start / length per segment and an arbitrary number of segments. I program these segments with a rotary encoder, choosing a start and end index and a mode for that segment. This way I don’t have to upload new code to the arduino when I’m using different lengths of LEDs etc.
I’ve used EEPROM both in a ‘current mode’ setup as well as storing a device’s ID (in a multi-node RF system) as well as storing larger amounts of data. Although for large amounts, I generally offload it to a separate EEPROM module as opposed to using the AVR itself. It’s not that I ran out of room on the AVR, I was learning how to use a separate module. Worked great.
I’m just beginning to experiment in the EEPROM realm, storing small variables like “mode” so upon re-boot, it remembers where it left off in the animations. No more than a couple bytes as well.
I use E2 quite a lot in non FastLED projects. But on FastLED projects the usage is much less.
I use AtmelStudio for most of my coding, so downloading it to the Arduinos is much less of a problem. Especially if you use the corrected bootloaders that don’t just throw the E2 programming data away!
Arduino have not really tightened up the IDE and the bootloader to pre-load E2 data with the programming of executable code. They expect you to ‘flash’ your initial values in from your own code. This wastes precious code space.
This could be an issue, Mark, for your proposed use and need.
With the large multi-node RF setup I did a few years back, I preloaded all of the EEPROM values and node IDs with one program, then loaded the actual program that was going to run on each unit. That was a bit of a hassle but it did the job.
My one project that uses it runs out by nature, though I have written the read/write layer such that it always wraps around to the first sector and overwrites sequentially.
Thinking of color readings in terms of frames, one frame being 3 bytes, there are only like 340 frames of reading, or maybe 12 seconds at 30 readings per second before wrapping around to the beginning again. I could have moved to a pared down, one byte, saturated representation of each color also I suppose, but then that project is also not using the fast_spi library anyway since it is on an 8mhz chipset (Flora)
Never ran out, but that’s mainly because I’m aware of what I’m sitting and such, and usually in the same address spot (which is actually bad because it wears out faster.). But as a round-robin setup, I’ve never “run out”.