I know the default Arduino SD library was ported, but has anyone attempted SdFat? I have a big project that I’d like to bring over to Spark Core, but it makes extensive use of SdFat. The native Arduino SD library is actually based on an ancient branch of SdFat, and the library has gone on to become much more efficient since the Arduino team copied it to their /library folder. Unfortunately much of the syntax has changed since then too, so converting my code to be backwards compatible is proving difficult.
For what it’s worth, SdFat “just works” with Teensy 3.0, so hopefully it’s not a tough port? (Famous last words.) I wish setting up a local dev toolchain was easier, or I’d try it myself. I would be so grateful if anyone could help make this happen.
Cool! I got Spark CLI working and it’s a GREAT compromise between the web IDE and full toolchain. Thank you for the suggestion. I’ll followup here if I make any progress with the library.
I just started looking at the SDCard lib with a view to making the filesystem available in the spark’s external flash, now that I have coded up flashee.
It seems quite straightforward to remove the SDCard specifics and replace this with a general block read/write device.
After hacking away and removing what’s not needed, I have it compiling now, so time to write some tests.
Once libraries support dependencies, I can publish this as a stand-alone library. If we also define a library for an abstract block device, then it will make it possible to use any kind of storage - external flash, the new FRAM shield etc…
I’d not seen the SdFat project - is that where the SDCard spark library comes from?
Comparing the code between the two, SdFat looks a lot cleaner - I’d already started fixing problem in the SDCard library code (such as hard-wired writes to Serial) which are fixed in the SdFat code.
(Sorry, just re-read your original post again - you say SDCard comes from an old version of SdFat.)
Copy the ino file as your main app file in the online editor and create a userlib (right top button)
and put the cpp file in the cpp library file and the header file in the header library file.
rename the library files int sfs.cpp and sfs.h.
Why not share your code on a github repo so you can then publish it as a library for the online IDE. That would make it easier for folks to use.
I took a quick look through the code, it does what it says - a simple file system! Although how about throwing in a few unit tests?
It would help prospective users if you document the constraints also. I don’t know all of them, but those that I saw reading the code: maximum length of 64kb per file, maximum of 16 files, and you can only have one file handle open at a time, so not possible to read from one file and write to another.
Rather than writing directly to flash, you might want to consider using my flash library. This can provide you with access flash with the advantage of wear leveling so that you don’t always hammer the same flash pages for rewrites/erases. The API is very similar to the sFLASH api in the spark so it should be easy to drop in.
That doesn't surprise me. I'm not a very experienced coder, but I can tell you I gained literally hundreds of bytes of SRAM when I switched from the native Arduino SD library to SdFat, which I desperately needed.
I've been hacking at the library, and I'm afraid I'm out of my depth. The latest compile errors are SPI-related, and I think it needs Spark Core specific code. There is existing support for ARM (SAM3X and MK20DX128) that could possibly be leveraged, but I'm not sure what the Spark uses or how to hook it up. I'd happily send the library in its current Spark-CLI state if someone can help me out.
My initial interest is to pull out the FAT handling so I can use it to store data in the flash memory. I got that compiling after disabling all the SPI stuff…but of course that’s the bits you need!
Maybe you could look at the corresponding functions in the existing SD-Card library for the spark to see how they solved the SPI issues? You might event be able to simply copy the code over from the old to new library.
Thanks for the suggestion, MDMA. I did try comparing libraries, but the SdFat is several years more mature since Arduino forked it. There now exists an SdSpi class that didn’t before, and it uses defines to signal what processor is running. It might be an obvious fix for a better coder, but alas.
Hopefully the guys who did the Arduino SD port will have time to chime in with their expertise.
Yo, the original SD port was done somewhat quick and dirty by @BDub and I and I have to agree with @mdma that SdFat is cleaner and more complete. There is some work to be done but porting should be straight forward.
@mdma, it would be fantastic to have the Fat portion working with flashee!
I will be taking a crack at porting SdFat and as @Jerware pointed out, there are newer versions floating about.
I pushed where I am up to a repo, One thing that may be useful for you is that I made a second copy of Sd2Card that contains only the actual functions required (Sd2Card defines quite a few methods but only a subset are actually used by the FAT layer on top.)
I suggest a way for us to work in parallel (and in our respective halves of the library) is that you start with Sd2Card.h/Sd2Card.cpp and simply ignore all the FAT handling functionality - SdVolume, SdFat, SdFile etc… You can test and use the Sd2Card independently from the FAT file system. Then when you have that ready, we bring our two halves together to form the complete library. How does that sound?
Thanks for the heads up on that - I’d not seen the FatFs library - looks even smaller than SdFat, and they have properly decoupled the disk io layer from the file system.
@Jerware, does this also scratch your itch? Or do you still need a port of SdFlash?
@mdma, the only catch is I don’t know when @satishgn will get a chance to finish it. However, with your fantastic flashee library, there may be an incentive to get the Fat stuff completed!
From what I can see, the work satishgn did was to add the SdCard SPI - I think the FatFS library itself was left well alone since it’s already complete and has a nicely abstracted diskio interface. I should be able to hook the fatfs project up to flashee very quickly - I’ll get started on that now.
