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.
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
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.
