Hi,
I know that Riot hasn’t got a file system but I’m wondering if we could still save some raw data in the ROM which would be available after reset? Could we allow some space in the ROM and write some data?
By the way, have you planned to design a file system for Riot?
Hi Baptiste,
that is actually something being planned (although with low prio). Some of the older boards have this already implemented (look at the config module for the msba2 and msb-430). For streamlining this all across RIOT, I thing what we should to is to create a generic architecture like this:
----------------------------------------------------
| light-weight persistent storage API |
----------------------------------------------------
| some kind of (static) multiplexing |
----------------------------------------------------
| low-level | low-level`` | low-level | I2C | . |
| SPI flash | EEPROM | on-chip | EEPROM | . |
| driver | driver | flash dri | driver | . |
----------------------------------------------------
Through the API on top it should subsequently then also be possible to implement a real file system on top of this. In the end it think the most important part is the separation of API and the actual drivers for different storage ‘devices’!
Again, this is just a rough draft, feel free to advance this discussion!
Cheers, Hauke
Hello,
first we need an interface to read and write data to flash. An specification can be found in RIOT/drivers/include/flashrom.h or another specification in my pull request https://github.com/RIOT-OS/RIOT/pull/2239
At the moment i'm on the way to port http://bitlash.net/ to RIOT. For full functionality i need an interface to flash or access to an file system.
My idea was to build an configuration store which is compatible with various flash types. In MCU supported by RIOT there are build in Flash with Error Correction or without error correction. There are many different page sizes. There are Platforms with the possibility to overwrite single bits without erasing pages (e.g. NRF51) and i think there are platforms with error correction where i can only write an page once. This is also an memory alignment problem. In my PR i have written code to allow unaligned access but i don't know if this is portable to any platform.
Another problem is how often an page can erased. On many platforms 10.000 erase cycles are possible. This is not enough for counters in flash. My idea was to create an object store starting at top of flash memory. Every write allocates a new space until there are no free pages available. When no page is available the flash memory needs cleaning.
If possible counter objects are placed in a whole page and changed at bitlevel. So its possible to count 8,000,000 times per 1k page with 10.000 erase cycles.
At the moment i have no time to work on this topic.
Regards,
Frank
Sounds great Hauke! I like the multiplexing, it will allow all kind of storage to be implemented and to separate device driver and the “user space” (API). This could be used by OTAU as well!
By “config module for the msba2 and msb-430”, did you mean [1]?
Frank, flashrom.h is for me one part of the global architecture, this is for low level on-chip flash driver. Other kind of storage should be taken into account as Hauke mentionned.
For my purpose, I would only need to create the driver flashrom.c for the SAMR21. Hauke, do you think that is possible with the SAMD21? By the way, flashrom.h should provide a flashrom_read() function or I don’t see the utility.
Baptiste
[1] https://github.com/RIOT-OS/RIOT/blob/master/boards/msb-430-common/board_config.c
Hey,
Hey,
By the way, flashrom.h should provide a flashrom_read() function or I don't see the utility.
Flash is usually directly accessible, no need for read(), unless the flash chip is somehow externally connected.
Yes but it will avoid to have unreadble code on the top of the interface and it will clearer for future reader to have a write and read function.