Basic SPIFlash file system

Libraries
1

I’m starting to look at offline persistent storage of data in the device. I was pleased to see the implementation of SPIFlashLogger in the electricimp github account. Is there any plan to implement a keyed file system where data could be stored in an area of flash and retrieved/written with the use of a string key? This would be a useful complement to the logger.

I imagine that the methods would be reasonably similar:

  • constructor([start] [,end] [,spiflash] [,serializer])
  • dimensions()
  • write(key,object)
  • read(key, onData [, onFinish])
  • readSync(key)
  • erase(key)
  • eraseAll([force])
2

A filename, or a key?

There’s this: https://developer.electricimp.com/libraries/hardware/spiflashfilesystem/?q=libraries%2Fhardware%2Fspiflashfilesystem%2F

3

A bit off-topic, but can we assume that the underlying SpiFlash api takes care of all semaphore handling to prevent simultaneous access attempts to the flash from different (semi) threads ? Or is this implicitely handled by the fact that the imp is in essence single threaded and (as far as i can see) mosrmt of the SpiFlash & derkved libs are purely synchronous ?

4

Thanks, I wasn’t aware that the file system library already existed. If covers many of my requirements, but I was looking for something less hefty.

Yes, it’s more of a keyed system I’m after, rather than a file system. The principle of wear-levelling is helpful, but there’d be no need for open/close/seek etc. You would either fetch an entire resource based on its key, or replace it entirely.

Maybe I’ll look at implementing something myself.

5

How big are the objects (each, and in aggregate)? Is encryption required?

One thought would be to take our imp005 config storage scheme (which is a secure tagged store in external SPI) and allow it to be instantiated and exposed to squirrel on any imp with SPI.

6

The objects would usually be less than 4K, but not always, which means they’d need to span multiple sectors. Encryption would be nice, but not essential. Writes would be uncommon is our use case, as the storage would be used for config, rather than status.