core-common-lib
core-common-lib copied to clipboard
particle-iot-archived
Feature/sdcard fatfs support
With this FatFs module's application interface functions(http://elm-chan.org/fsw/ff/00index_e.html) can be used to mount the sdcard, perform file read/write operations etc. An Arduino wrapper for sdcard based on this feature would be provided in core-firmware repo.
Satish, I have not been able to get the SD stuff working. Maybe its me but I created an "application.cpp" that is based on the speed benchmark example I have. The plan is to use SD_Init() to connect to the SD, then SD_GetCardInfo() and print the info then run the test using f_open(), f_write(), f_read() and f_sync(). To compile application.cpp, I include sdcard_spi.h and ff.h. However, I had to add the path to ff.h in the core-firmware makefile. Though it finds the files, the compiler flags a re-declaration conflict of "INT" in integer.h (FatFs_Module) and spark_wiring.h. I cannot proceed.
Sorry @pkourany , I could not get the Arduino wrapper for this feature added in the core-firmware repo as planned. The error you are getting is because of the "INT" enum value in spark_utilities required for COAP use. Probably we need to rename this enum to some other and associated code changes. I thought of completing the development and end-to-end testing after coming back from vacation(after 9th May). In the mean while you will have to rename this INT and continue with testing.
Satish, I got everything to compile and load on a core. However, the could would not past SD.init() and I no time to dig in because of the upcoming Faire.
IMHO this shouldn't be part of the core firmware, but provided as a library. The core firmware is already pretty big! :)
When the spark libraries support dependencies, it would be good to provide fatfs as one library, and then the low level storage engines as separate libraries, and combining these give the complete stack. This will allow the same FAT code to be reused with different storage engines, to store to different types of media, e.g. SD card, FRAM shields (when ready), external flash (flashee library).
Thanks @m-mcgowan, totally agreed. This one is on hold until there's more testing and verification done, and it should definitely not increase binary size or RAM usage unless intentionally included by the user.
