Persistent configuration interface


there are any plans to implement an persistent configuration store?

A lot of CPU's doesn't have an EEPROM included. My idea is to create an configuration store on top of Flash area.

I think its an good idea to define an key as uint16_t. An uint16_t can be split into 8192 blocks with 8 keys which can be assigned to packages or libraries. Some blocks should be reserved for application use. Keys 0x0000 and 0xffff must be reserved to detect deleted keys or the end of storage.

To reduce write cycles with every write to an key is added to the lower end of Flash. The old location of key value is set to 0x0000 when its supported by CPU.

Duplicate keys are cleaned when needed by defragmentation.

To save RAM a pointer is returned. This is easy for ARM and Intel like CPU's but on AVR CPU's it's needs to deal with PROGMEM.



Hi Frank,

shuch a solution is at least partly already in place in RIOT, however implemented only for the MSBA2/LPC23xx platform to my knowledge. It is however a more generic interface/approach missing that is feasible for all our platforms. In my opinion we should split the store at least in two major modules, one for providing an interface for actually storing and retrieving data, and one module for doing the low-level access to flash and/or EEPROM.

  I think your concept sounds very sensible, so looking forward to your PR :slight_smile:

Cheers, Hauke

Hi Hauke,

my concept is to implement an CPU specific Flash interface and an configuration interface. I have no plans to support EEPROMs. It looks like most actual micro controllers haven't an EEPROM. At AVR the EEPROM is accessed via registers and not via memory access. Returning Pointers wastes a lot of RAM is this case. Returning data via Stack creates a lot of overhead on all other Platforms.

I concentrate my work to find a way to handle the limited count of erase cycles best it's possible for me.

Regards, Frank

Hi Frank,

sounds good! Looking forward to your solution!

Cheers, Hauke