I'm in the process of adding mesh support to our existing application and am a bit perplexed as to how best implement NVM. The mesh SDK documentation dissuades me from continuing to use fstorage, but instead asks me to use the mesh Flash Manager. All well and good, but the mesh Flash Manager implementation is poorly suited for using flash as simple mass storage.
My application uses a number of flash pages as a circular buffer storing fixed size event records. Events are logged to flash as they occur (typically 4-6 events per day), each event is 4-bytes. When one page is full, logging goes on to the next page. When all pages are full, the oldest is erased and reused. The store can be read by simply reading words sequentially from flash. This is all implemented using 2 api's, fs_store() and fs_erase().
My application also uses NVM as a random access device, where a flash page stores 2 sensor readings each day, using day of the year as the index into the flash page. This is also implemented using fs_store(), calculating write offset within the page from day of the year.
These NVM scenarios don't naturally fit into a handle/value mechanism. Handles are unnecessary and inefficient, 4 bytes of overhead for each 4 bytes of data; not to mention the extra logic needed to wrap the data with handles.
The mesh Flash Manager looks like a wonderful thing for storing handle/value pairs, but that is only one possible use of NVM. Storing sequential or random access data is fairly common in embedded systems and it doesn't benefit from a handle/value mechanism.
Nordic, please consider exposing a lower-level API (write_flash, read_flash, erase_flash) in the next version of mesh SDK. (or test/fix fstorage coexistence with mesh.)
TIA,
Richard
