SdFat library port?

Firmware Libraries
21

Hi, I’m really busy finishing my project, so no time to put it into a repo. Before publisihing I will clean up first, and off course document the code.
This library is intended to write once, read many times. The intended use is for a web enabled device that contains a webserver to display it’s status, and off course to interact with the user.
So direct writing is no big deal, we have 100.000 times to go…
Just a question about your flash library, where do you store the intermediate data when you are not writing to flash directly? In RAM?

regards,
Marcus

22

@peekay123, @mdma, I was asked to hold on with the FatFs support till we complete other high priority stuff. I will check with @zachary as whether to complete the the SDCard stuff in next sprint!

23

@satishgn - OP was looking for a library that was source-compatible with the arduino SDFat library - it’s my understanding that you were looking at using a different library (fatfs.) That’s no problem - we can write a simple layer that mimics the public API of the arduino SDFat library and translates that into calls to the fatfs library.

I think fatfs is great, and I’ve already integrated it into my external flash eeprom emulation library.

Since fatfs is independent from the underlying persistence layer (via the interface in diskio.c), it would make sense to factor our fatfs use into these reusable libraries:

  1. the library for the fatfs filesystem code (ff.c)
  2. pluggable engines for different storage devices (implementations of diskio.c). E.g. external flash, SD Card SPI, FRAM, Network addressable storage

To do this effectively requires transitive dependency support in libraries - do you know how far away that is?

24

@mdma, We have the SD SPI support and for which the relevant diskio code was done. The last time where I left, I was in the process of bundling up some home made SD shield so as to test the SPI layer. So there testing is incomplete. Even external flash and FRAM should be doable by providing a wrapper for diskio interface. I’m not sure about the amount of work required for NAS!

25

Yes, I agree. That’s what I tried to say was that the diskio interface allows us to plug different storage back-ends into the library. I have already done this for external flash, which uses my wear-leveling flash library, so erases/rewrites are spread across the free space in flash.

26

@satishgn, I tried the SPI layer if you recall and did not have any luck. Other priorities prevented me from doing any serious debugging though.

1 Like
27

@peekay123, Glad to know you tried testing it and thanks for the heads-up. The SD card that you tested - was it a High Capacity one? Your test case might be helpful when I restart my work on this.

1 Like
28

@satishgn, I had to play with the code to get it to compile first. I can send you the code I used for testing, no problem. :smile:

29

I don’t suppose one of you kind sirs could translate this discussion into a ballpark timeframe for the SdFat port? I’m not in a rush, but it would help me to know if we’re talking days, weeks, or months. I certainly appreciate everyone’s willingness to help, and that there are higher priorities.

1 Like
30

@mdma, for the SdCard port, you can use the Arduino SdSpi code. It’s just a matter of setting the conditional compiles. Right now, the SPARK conditional does not seem to be working on the IDE or the CLI, just locally. Are you removing all the arduino stuff and if not, which conditional are you using? :smile:

31

Thanks. I’ve not looked at SdCard since you kindly pointed me to fatfs! You’re right that the spark conditional doesn’t work - I’ve had to hard-wire it in my libraries so far until it’s added across the board. Where’s the best place to flag this kind of issue - is there are repo for the online ide/CLI tools?

32

@mdma good question. It affects both the CLI and the IDE but really the production compiling servers. @Dave, where should this issue be raised?

33

Hmm, good question!

Maybe it makes sense to raise those on the core-firmware repo? Since that’s where the define was added?

34

@Dave, that flag works fine on the local compile. But was that compiler flag added to the IDE/CLI compiler servers?

35

I think so? It should be the same “-DSPARK=1” define below, but it’s not clear to me why it would work in one place and not the other:

Thanks,
David

36

I’ve not tried the CLI, but I can say it definitely doesn’t work in the online IDE. Try this example:

#ifdef SPARK
#error SPARK defined! yay!
#else
#error SPARK not defined! bah!
#endif

gives

/test.cpp:8:2: error: #error SPARK not defined! bah!
#error SPARK not defined! bah!
^
make: *** [/test.o] Error 1
37

Yup, and I tried this in the IDE and never got to an error.

    #if defined (SPARK)
    #error "it works"
    #endif
        
    #if (SPARK == 1)
    #error "it works"
    #endif
    
    #ifdef SPARK
    #error "it works"
    #endif
    
    void setup() {
    }
    
    void loop() {
   }

@Dave, are you sure that’s in the production?

1 Like
38

Yeah, I can confirm there are no differences between the main makefile on production and what you see in the repo. There is a subdirectory makefile similar to https://github.com/spark/core-firmware/blob/master/src/build.mk, but I don’t see the define there so I imagine it’s not necessary for user apps either… Hmm. I’ll try to look into this further, since this is a pretty annoying bug right now.

Thanks!
David

1 Like
39

I don’t mean to get entangled in your development processes, but it would be awesome if you could write a test to highlight the bug. That way you verify the bug, and also the fix. (And the test will fail if for some reason the bug ever comes back.) Another reason to do it is that a suite of tests then define your functional spec - can be useful down the line when you have to make a radical change yet support all the existing apps. Maybe you already do this, I don’t know!

I am a Test Evangelist - I spread the word of testability to all! :slight_smile:

1 Like
40

Of course! I’m also pro-tests! The define was a somewhat recent addition that happened in the firmware and didn’t involve compiler changes, so definitely adding a unit test for this would be a Good Thing TM :slight_smile:

1 Like