In varoius threads, such as
there’s talk of an EEPROM library. Is this something that will be done during this sprint?
If not, I’d like to help out.
I’m going to write the library access to the CC3000’s eeprom, both with the same high and low level apis found on the Arudino.
The EEPROM in the CC3000 and external Flash both provide non-volatile storage. However, the flash may be more dangerous with some code, since it has to flash a whole a block at a time. (e.g. code writing to increasing addresses one byte at a time.)
Some implementation details: The CC3000 eeprom access would use the 2nd user file descriptor as it’s storage location. Since it comes after the spark descriptor, I wonder if we should increase the space in the spark eeprom file to allow additional values to be stored there in later firmware. Otherwise, if a new firmware release comes out that requires an extra byte or two, old content in user space eeprom will be invalid? Increasing the size of the spark core eeprom file to (say) 512bytes will offer room for growth, so firmware upgrades to add more content in eeprom if they need to without affecting the user code’s eeprom storage.
By default the spark EEPROM library would write to the spark core’s EEPROM. This aligns as closely as possible to the arduino behaviour, but we get several times more EEPROM capacity.
For users that don’t care about the block writes, or who want access to even more non volatile storage, they could use the same API, but switch the “back end”.
eeprom_select(NV_FLASH) can be used to instruct that subsequent EEPROM apis use the external flash rather than the CC3000’s eeprom. This would be a spark-specific addition, but means deveolopers on spark now have a choice about where the sketch stores eprom data, while maintaining code-compatibility with existing sources.
For clients wanting directly access to the flash, working with the page-level flash, there is no arduino library to emulate (since the eeprom library doesn’t require whole page erases.) Hence, a new API for writing to the user area in the external Flash will be created.
So, in a Nutshell an Eeprom library that can let existing Arduino code target both devices, plus a flash-specific API for working with block-level erases.
Spark team: If you’ve sketched out designs for this, any hints or pointers would be useful. I will be building this soon, so let me know if I should do this, or wait for the official support in the spark.