This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Difference between persistent storage libraries

In the nrf5 sdk (version 11.0.0) there are three different modules which, as near as I can tell, do the same thing. These are:

  • pstorage
  • fstorage
  • ble_flash

All three look to be used in various different examples, and when bringing in ble modules they all seem to be required.

What are the differences between these modules? Under what circumstances do I need to include each one?

  • There are indeed three, in fact four, and two of them do the same thing. They all manage flash access in some ways and they are all designed to be used with the softdevice (flash access stops the CPU and that's bad when you're in connection).

    Starting with the simplest, ble_flash is a thin layer over direct flash access which, when fed with events from the radio notification service, delays flash operations until 'safe' times. You get raw access to flash this way, no structure, just memory you can read from and write to. I've not seen this in use.

    pstorage is a more structured way of accessing flash. You register to use blocks of a certain size and make calls to write or erase them, which call you back when complete. You still have to manage your data layout and work out when you need to clear full pages, but pstorage is high enough level that multiple modules can register and work with flash storage at the same time. pstorage has been, until SDK11, the way most of the other modules and most developers store persistent data.

    fstorage is the new version of pstorage, basically. It's a little more modern, it uses section names in compilation to mark off blocks of storage instead of the block registration in pstorage which seemed to trip people up more often than you might expect. It's still pretty raw access, you get pages, you read and write to them, you are responsible for managing the storage. If you were starting a new project now and were going to use pstorage, you probably want to use fstorage instead as long as none of the modules you also need to use are still using pstorage.

    Finally there's FDS, also new in SDK11. FDS is Flash Data Storage and is underpinned by fstorage (and is probably why fstorage was written). FDS is a very simple filesystem for flash which stores variable length records you can retrieve in a couple of different ways. It allocates an extra page of flash which is used for garbage collection when flash needs compacting. FDS provides the kind of functions you always ended up writing on top of pstorage yourself to actually manage the formatting of data on the chunk of raw flash, but it does it without being too heavy and saves you writing code to buffer updates, find data and deal with fragmented flash.

    so ble_flash is very basic and probably not very used. pstorage has been the workhorse of persistence for 5 generations of the SDK and is pretty well understood. fstorage and FDS are the latest generation which aim to provide a bit more generic functionality, the kind you need when you are actually storing and retrieving data and ended up writing yourself.

    I use FDS these days and will fix up older projects to use it when I revisit them.

  • Fantastic overview, thank you! It's good to have it put in perspective of both complexity and ancestry.

    When bringing in various components under the components/ble/ directory, I find myself required to bring in both pstorage and fstorage (both are used by different components). Is this just the way things have to work, or am I doing something wrong by (say) bringing in outdated code that I shouldn't be using?

  • some modules, like the new device manager, or is that peer manager, have been updated to use fstorage, lots of old ones haven't yet and still use pstorage. So if you are using modules which use both, that's where the requirement to pull in both comes from. However I recall seeing a thread here the other day suggesting they don't work together

    devzone.nordicsemi.com/.../

    but then there's another post from someone who is using them together

    devzone.nordicsemi.com/.../

    so I really don't know which is really the case. I suspect they may jump on each other's use of flash if not careful with the linker map, but I've not tried.

  • hello 

    can we use this library function for external flash memory store data ? 

Related