FatFs-LFN 0.5a Information

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wanted to relay to others who use FatFs or are working on a FAT-related project that I am reasonably happy with my variant, called FatFs-LFN. I probably should rename it (suggestions, as it's much more than just LFN). All of the following options can be enabled or disabled via compile time defines:

    ASCII LFN support
    Double Byte LFN support.
    Maximum LFN length setting. If defined, any LFN over the max will be returned as the short name. This allows you to reduce the memory footprint of the LFN buffer.
    (Deletes and moves of shortname files with LFNs will clean up old LFN entries if LFN support is enabled)
    Multiple partition support. When on, each drive can scan for up to 16 partitions, including the 4 primary partitions and 13 extended partitions. No API changes are needed. drv becomes 0x
    , where 0 is no partition (SuperFloppy) layout
    Single Buffer per partition operation (this means that only 1 512-byte buffer is needed for all file operations per partition.
    Single Buffer operation. In this mode, FatFs has the same data memory footprint as FatFs-Lite, but can still access multiple partitions (up to 240) while requiring only 1 512-byte disk buffer (of course, 240 partitions still require one FATFS structure per partition)
    Deferred Read optimizations. One sector aligned reads or writes, the code no longer prefills the internal buffer for the next read.
    Fseek optimizations. Fseek will not scan FAT chain for same sector or same cluster fseek()s.
    Support for current directories (fopen("currdir/filename",FA_READ) will work.
    Removal of internal drive array. Normally, FatFs manages the FATFS structures that you pass in f_mount, and you reference a drive by number (0:/dir/to/file.txt). This mode allows you to manage the FATFS structures yourself and you don't need to prepend the drive number to paths.
    low level functions. If you do a readdir and retrieve a file, you can then call l_open() with the cluster number returned in readdir to avoid the subsequent directory scan for the file.
    Immediate mount operation. FatFs defaults to deferred mounting, where the mount occurs on first disk access. However, you can switch so that the mount occurs at time of mount, if you need immediate success/fail information.
More specific error codes are provided in certain situations.
All standard 0.5a fixes are included and std behavior is included.

I and others are using the new code in some projects, and it's been tested pretty well. I am very happy with it. It's nice to offer multiple-partition, multiple file support using a single 512-byte buffer.

I mainly wanted to know how I should provide the resulting code for others, if interested. The only two files changed are ff.c and ffh, but I don't know if it's OK to just provide those two files and point users to the other files from the original archive. Thoughts/Comments welcome.

Jim

Jim Brain

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This site will let you create a "project" and you can attach your files there.

Or I can host them for you if you just want to give people a web link.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you ask Chan if he is interested in integrating your modifications? If LFN-support could be (de)activated by a define I don't see a reason why the extension should not be in the "upstream" (Chan's code). It will be much easier to keep one source up to date than porting extensions/fixes from one into the other (FatFs006 is out, you write that your code is based on 005...). Maybe you can create a sf.net project where Chan and you can keep the code up-to-date though svn or cvs.