wmxz-eu/usdfs

uSD File system based on ELM-CHaN generic FAT system

uSDFS

uSD File system based on ELM-CHaN generic FAT system

The Teensy library contains a port of ELM_CHaN's generic FAT file system for the PJRC Teensy 3.5/6 and Teensy 4 MCU.

Examples

• uSDFS_test: basic test of uSD File system
• logger_RawWrite: testing writing to SD Cards

History:

- 18-feb-2023

• Version 1.1.4
  • upgraded to ELM-CHaN's ff15

- 23-may-2021

• Version 1.1.3
  • upgraded to ELM-CHaN's ff14b

- 09-aug-2020

• added example with fatfs=malloc(sizeof(FATFS)); (issue11)

- 01-july-2019

• Version 1.1.2
  • removed compatibility issues with TimeLib library

- 27-may-2019

• Version 1.1.1
  • added interface to GPT partitions (thanks to KurtE)

- 07-may-2019

• Version 1.1.0
  • upgraded to ELM-CHaN's ff13c
  • refactored library structure
  • added Teensy 4 low-level interface
  • added MSC (USB disk) interface
    • uses UHSHost_t36 (Teensy build-in library)
    • needs MSC library (https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments)

- 12-mar-2018

• Version 1.0.6
  • upgraded to ELM-CHaN's ff13a

- 03-may-2017

• Version 1.0.5
  • upgraded to ELM-CHaN's ff12c

- 29-oct-2106

• work in progress to stabilize use of multi-device settings (e.g. spi and sdhc)

- 26-oct-2016

• Version 1.0.4
  • added multi record operations for SPI (significant speed increase for large buffer read/write)
  • to be done
    • consolidations of SPI calls
    • variable speed settings for SPI (similar to begin/end transactions)
    • DMA support for SPI

- 20-oct-2016

• Version 1.0.3
  • added basic SPI support (8/16 bit FIFO)
  • User should edit src/uSDconfig.h to configure multiple uSD cards for both SPI (all teensies) and 4-Bit SDIO (T3.5/3.6 only)
  • multiple disks (mix of spi and sdio) are possible
  • to be done:
    • multi record operations for SPI
    • variable speed settings for SPI (similar to begin/end transactions)
    • DMA support for SPI

- 21-sept-2016

• -fshort-wchar addition in boards.txt is NOT neeeded any more
• changing _T(x) macro to #define _T(x) u ## x in ff.h does the job (u compiler directive indicate 16 bit)

- 12-sept-2016

• Version 1.0.2
  • upgraded to ELM-CHaN's ff12b
  • cleaned sdio.c
  • added cmd6 switch for high speed sdio
  • needs -fshort-wchar in boards.txt added to teensy36.build.flags.common for exFAT operation

- 09-aug-2016

• symbols aligned with Teensyduino_1.29

- 25-jul-2016

• upgraded to CHaN's ff12a version as of 25-July
• default configuration is now with exFAT
  • implies use of LFN
  • requires use of unicode

- 13-jul-2016

• corrected unicode char width (is 32 bit not 16 bit on FRDM K64, not sure for Teensy 3.6)

- 08-july-2016

• Working release

- 30-jun-2016

• First release V1.0.0
  • multi-buffer operation fixed

- 27-jun-2016

• work-around to get f_read/f_write working with buffer sizes >= 1024 bytes

- 26-jun-2016:

• Initial upload (K66 4-Bit SDIO)
• No speed optimization in FAT system

usdfs's Issues

Corrupted reads crossing sectors

I'm working on an application that involves reading records out of a database. Each entry in the database has a fixed size record header which contains the length of the record data which is read first, then based on the length in that header field, the actual data is read. In certain cases, the data in the second read (which in the failed case always exceeds a sector size) returns corrupted data. However, if I use a simple wrapper to ensure that I only read sector sized segments from the file system like this:

osint xfs_os_fopen(xfs_file *f, const char *pathname, xfs_mode mode)
{
    sdinit();
    int res = seterrno(f_open(&f->os, pathname, mode));
#ifdef FF_BUG_WORKAROUND
    if (!res) {
        if (mode == XFS_OPEN_READ) {
            /* Grab our first block */
            f->isreadfile = 1;
            f->offset = 0;
            if (f_read(&f->os, f->buf, sizeof(f->buf), &f->bufbytes))
                f->bufbytes = 0;
        } else
            f->isreadfile = 0;
    }
#endif
    return res;
}

xfs_off_t xfs_os_fread(void *ptr, xfs_off_t size, xfs_file *f)
{
    FRESULT res = 0;
    UINT br;
#ifdef FF_BUG_WORKAROUND
    xfs_off_t totalread = 0, count = 0;
#endif
    sdinit();
#ifdef FF_BUG_WORKAROUND
    if (f->isreadfile) {
        while (size) {
            count = size;
            if (count > f->bufbytes - (f->offset & FF_MASK))
                count = f->bufbytes - (f->offset & FF_MASK);
            //xfs_verbose(NULL, "size = %d, count = %d, offset = %d, bufbytes = %d", (int)size, (int)count, (int)f->offset, (int)f->bufbytes);
            memcpy(ptr, f->buf + (f->offset & FF_MASK), count);
            f->offset += count;
            ptr += count;
            size -= count;
            totalread += count;
            if (!(f->offset & FF_MASK)) {
                /* Time to read the next sector */
                //xfs_verbose(NULL, "fresh sector, expected at %d (vs %d)", (int)f->offset, (int)f_tell(&f->os));
                if ((res = f_read(&f->os, f->buf, sizeof(f->buf), &f->bufbytes))) {
                    xfs_verbose(NULL, "read returned %d", res);    
                    f->bufbytes = 0;
                    return seterrno(res);
                } else if (!f->bufbytes) {
                    /* We reached the end of the file */
                    break;
                }
            } else if (size) {
                /* If there is more to read and we're not at a sector boundary, then we have reached the end of the file */
                break;
            }
        }
        return res ? seterrno(res) : totalread;
    } else
#endif
        res = f_read(&f->os, ptr, (UINT)size, &br);
    return res ? seterrno(res) : (xfs_off_t)br;
}

Then the application works perfectly, albeit much more slowly. I am open to any suggestions you might have!

Mark

T4.1 and malloc'ed FATFS struct does not work with SDHC DMA

this due to the struct then beeing placed in OCRAM2. Took me a day to find out and is perhaps something to be mentioned in the readme?

A minor issue is that there is a warning about implicit definition of rtc_get, a missing include?

m_sdhc_baudrate caculation wrong

line 467 in sdhc.c (cosmetic?) is in error me thinks. it reads
m_sdhc_baudrate=F_CPU/((1<<minpresc)*(mindiv+1));

but minpresc is not a shift value, it should be minpresc << 1
BUT, that is not quite right either, because if minpresc is 0, you want the multiplier to be 1, so maybe
int tmp = minpresc << 1;
if (tmp == 0) tmp = 1;
m_sdhc_baudrate=F_CPU/(tmp*(mindiv+1));

Status of Teensy MassStorageDriver?

I found this 2019 thread:

https://forum.pjrc.com/threads/55821-USBHost_t36-USB-Mass-Storage-Driver-Experiments

As far as I can tell, this is the work that became the MassStorageDriver.cpp code in the USBHost_t36 library. Is that correct?

That code does not include a FAT filesystem. From the above thread, it sounds like I need the ELM-Chan FatFS library for that.

However, I'm not sure how to link that library with MassStorageDriver. The code in the uSDFS GitHub repo seems to be targeted at reading an SD card, and I assume it's based on a version of the mass storage code from before MassStorageDriver.cpp was incorporated into USBHost_t36.

What are the right steps needed to be able to read FAT drives on Teensy 4.1, using USBHost_t36?

Thanks!

what license is in effect?

I've got MicroPython running on the Teensy 3.6 and I'd like to add sdcard support. MicroPython already uses ELM-CHaN so I'd like to use the diskio and lower code.

Your files don't seem to have any copyright notices or any other licensing information.

MicroPython is currently licensed using MIT, so I'd like to find out if I can put copies of your diskio* and sd* files in the MicroPython/teensy tree under the MIT license.

I'd be happy to put a comment block at the top of each file I use to indicate its original source.

Thanks

How to avoid long writing time?

I use SD card as datalogger, but every 6 lines f_puts takes too long. I have changed example to reproduce it. See example.

https://drive.google.com/file/d/1ck2GOuDpOvRrhhMOZu5_sJptr5ijp3wr/view?usp=sharing

The serialprint output shows these times:

Create a new file HELLO14.TXT.
Write some text lines. (Hello world!)
173
19
19
21
33
19
766
21
32
19
19
21
1087
19
19
21
32
18
1074
22
33
19
19
21
1086
....

add support for teensy 3.5

Is it possible?

What is the licensing for uSDFS?

I looked at a sampling of the source files and saw no license information. Then I looked at the issues list and saw a closed issue asking the same question, but with no comment or answer.

It would be very helpful to show licensing information at least in the ReadMe, because some of us have restrictions on what we can and cannot use (e.g., medical devices cannot use any licensing with language that requires end-user modifiability).

Thanks!

Craig