Using LittleFS and SDFat together?

Status
Not open for further replies.

jstanley

Member
I'm interested in using LittleFS and SDFat libraries together with Teensy 4.1 (Teesnyduino 1.54), in order to have FAT files on the SD card and files in RAM on the Teensy 4.1. But when I include both LittleFS and SDFat in a project I get collisions of constants like FILE_READ that are defined in header files for both libraries.

Is there a way to build a project that uses both file systems?

Thanks for any word on this.
 
Include LittleFS.h first.

Code:
#include <LittleFS.h>
#include <SdFat.h>

Or include SD.h before SdFat.h

Code:
#include <SD.h>
#include <SdFat.h>
#include <LittleFS.h>
 
Thanks for your reply. This gives better results, but I still have one issue:

Code:
C:\Users\jim\Documents\Arduino\libraries\SdFat\src/SdFat.h:400:16: error: conflicting declaration 'typedef class File32 File'
 typedef File32 File;
                ^
In file included from C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\LittleFS\src/LittleFS.h:25:0,
                 from C:\Users\jim\Documents\Arduino\sketch_jul28a\sketch_jul28a.ino:1:
C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4/FS.h:49:7: note: previous declaration as 'class File'
 class File : public Stream {
       ^
Multiple libraries were found for "BufferedPrint.h"
 Used: C:\Users\jim\Documents\Arduino\libraries\SdFat
 Not used: C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\SdFat
Error compiling for board Teensy 4.1.


Does this mean I'm using the wrong SDFat library?
 
Yes.
delete this from your system : Used: C:\Users\jim\Documents\Arduino\libraries\SdFat

Using TeensyDuino 1.54 includes the recent and fitting copy of SdFat
 
I've asked that before, but got no answer:

Do SDFat and littlfs care about SPI? Is it ok to use them in an interrupt, with SPI communication in the program? If not, is usingInterrupt() OK?
Do they handle file accesses in interrupt + main program correctly?
How do I know if a "File" is on a SPI device? Is there a way to know on which filesystem (littlfs/sd..) it is?
 
I've asked that before, but got no answer:

I don't have 100% certain answers to all these questions, but here's a quick try....


Do SDFat and littlfs care about SPI?

Both use SPI in some configurations, but not in others.


Is it ok to use them in an interrupt, with SPI communication in the program? If not, is usingInterrupt() OK?
Do they handle file accesses in interrupt + main program correctly?

I haven't looked at this in detail, but I'd be pretty surprised if they are fully interrupt safe.


How do I know if a "File" is on a SPI device?

From only File, you don't know. It's an abstraction layer.

The situation is similar to a conventional operating system.

File *fp = fopen("myfile.txt", "r+");

When you have only the pointer from fopen(), you can't know whether the media is SSD or mechanical hard drive or CDROM or network filesystem or something else.


Is there a way to know on which filesystem (littlfs/sd..) it is?

Unless the top-level code which opened the file somehow remembers, no, you can't tell if a generic File object will access SD card or flash via LittleFS or USB MSC or some other type of media (when more libraries are eventually added).
 
I've asked that before, but got no answer:

Do SDFat and littlfs care about SPI? Is it ok to use them in an interrupt, with SPI communication in the program? If not, is usingInterrupt() OK?
Do they handle file accesses in interrupt + main program correctly?
How do I know if a "File" is on a SPI device? Is there a way to know on which filesystem (littlfs/sd..) it is?

Didn't see this asked before :( - not sure of an answer ... seems something complex needing tested ???

Most of the testing done was on non SPI devices - ( though QSPI may have same concern? ) and not sure if any was on complex systems where all I/O wasn't in main loop() thread?

Testing done here was using LFSIntegrity for a single device and just doing repeat I/O to verify FS integrity driven by loop().

Doing I/O in an _isr() ? Or just alternating to _isr() while LFS was using the (Q)SPI bus for file I/O?

On the desk is a T_4.1 with 4 SPI Flash chips and PSRAM and some QSPI Flash - do you have an idea for a sketch? Starting with one of the Integrity examples adding an interrupt for some SPI device? Maybe even QSPI PSRAM access?

This doesn't relate to SdFat - should it be on the LittleFS thread?

Original LFSIntegrity.ino has an interval timer just to interrupt and also show signs of life if something got stuck - it never showed anything and that extra code was removed for release.
 
Thank you!
It's for the audio wave player i'm working on. It has to read from a "File" during update() which is called by the audio software interrupt.
 
Thank you!
It's for the audio wave player i'm working on. It has to read from a "File" during update() which is called by the audio software interrupt.

So, what would be a safe way?
Due to the nature of it, the wave player has no information about the user program.
It does not know wether qspi and/or spi is used. Or if a display etc is connected.
I see myriads of crashes on the horizon... ;)
 
So, what would be a safe way?
Due to the nature of it, the wave player has no information about the user program.
It does not know wether qspi and/or spi is used. Or if a display etc is connected.
I see myriads of crashes on the horizon... ;)

That seems likely :(
 
All I can do is calling AudioUsingSPI. Regardless if "my" file uses SPI or not - I don't know that.
QSPI.. SDfat...littlefs.. don't know...
Before T4, things were simple :)
 
The simplest would be to disallow audio interrupts during open, read, seek and close. I'd add write() too, perhaps.. for recording.
But it needs to be fast.
 
The simplest would be to disallow audio interrupts during open, read, seek and close. I'd add write() too, perhaps.. for recording.
But it needs to be fast.

That would probably catch one common conflict - does NoAudioInterrupts() go NULL when Audio isn't included in a sketch? Or would that pull in the Audio lib to get that?

I started an Integrity sketch variation with the intervalTimer back in - not sure when that'll finish and what it will do ... I'd start with PSRAM as it can be a drive and also storage memory. That should work with the CPU handling the QSPI direct addressing - versus Flash using SPI transaction begin and end over a group of I/O.
 
Status
Not open for further replies.
Back
Top