Can imp006/impOS conveniently interface with FAT32 SD cards over SPI in 2020?

I read some older threads on this forum from multiple years ago where people asked about interfacing imp with your standard microSD cards over SPI which is a basic staple on most Arduino-based platforms.

I am really loving ElectricImp, but I am disappointed to see that there does not appear to be an off-the-shelf Squirrel/impOS equivalent to SdFat in C/Arduino - is this correct?

Does anyone have code snippets for basic manual read/write on an SD card over SPI on an imp using Squirrel? My understanding is there exists a more raw, bare-bones manner of interfacing with an SD card which does not use a file system.

The built-in flash memory on imp006 is insufficient for multiple reason:

  1. The first interaction I ever had with it showed that it was buggy and unreliable to access (corrupted memory) (Did I screw-up my remote imp006 into needing a manual power cycle to reconnect to network?) (perhaps it was a bug in that software library, but corrupted memory was indeed the seeming cause);
  2. It only has, from my understanding, 4MB of space. I need to store 150-byte minutely packets for up to a few years and be able to remotely read/reupload these at command. Just one month would overflow 4mb; and
  3. The physically removable and replaceable nature of an SD card is highly desirable.


I’m not aware of any sdfat code that anyone has written, no.

The QSPI is not “buggy”, it’s flash, and will behave identically to any flash especially if power is lost during a write. There appeared to be a replaymessenger bug though, so modifying that to be more defensive would fix the issue.

The max QSPI size is 16MB for the system-managed flash. If you want more, you can certainly put a bigger SPI flash on one of the many SPI ports and run the same code against it (there’s an API-compatible SPI flash library which can then be used under replaymessenger or the spiffs).

SD cards are generally not recommended for long term storage as they are MLC and prone to a lot of problems - you get what you pay for.

Not sure why you would need many years of storage on a device, though. Why not store in (eg) an S3 bucket in the cloud? Rather more robust.