FatFS LFN Support testing

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

I've adding some support for LFNs to FatFS and am wondering if there are folks interested in helping test and debug?

Read and Dir reads looks to be working, and I've added the code for adding new directory entries and writing them out, but I'm still debugging that (should be working by tonight).

I've previously implemented LFN support in my own FAT16/32 library, but FatFS looks more full featured, so I thought it might be best to simply add the LFN support. As with the rest of FatFS, all mods are surrounded by #if/#endifs to allow FatFS to be built without LFN support.

Code is by no means optimized (I'm still learning my way around FatFS), but I figure that's a small issue to address.

Additional tweaks I am intended is to get FatFS to use 1 common work buffer and no file-work buffers while still allowing multiple filesystems (I plan to switch my project over to FatFS, but RAM is tight and I need these features)

Jim

Jim Brain

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

It looks like f_open(FA_WRITE|FA_CREATE_NEW) works now, with LFNs. There are few corner cases I have not checked (part of the LFN entries are on one sector, while the rest are on another), but folks can test.

f_rename, f_unlink and such are not converted yet, but should be easy, as they are just an excercise in removing dir entries. f_mkdir just needs the same code as f_open (I'm surprised f_mkdir isn't just a call to f_open for the first part).

To speed development, I imaged a CF card as a flat file and wrote an ATA.c that simply reads and writes to the img. Thus, I can test on the PC.

Testers welcome. THose who have used the library would be helpful as well, as there are a few things I don't understand:

FA_CREATE_NEW doesn't trigger the date/time to be added to the entry. It appears you need FA_CREATE_ALWAYS, but that doesn't make sense. As well, FA_CREATE_ALWAYS sets the archive flag.

FA_CREATE_NEW should sync the FS after the dir entries are added, but it does not. It waits until the sector is moved before doing so. If someone does a FA_CREATE_NEW but not FA_WRITE on the open, the dir entries never get written.

I assume this stuff is correct behavior, but it baffles me, given my other FAT16/Fat32 implementation.

Jim

Jim Brain

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

Hi Jim,

Out of curiosity what are you going to do about Microsoft's patent on LFN handling? I believe this is the reason FatFS hasn't done it already (http://elm-chan.org/fsw/ff/en/ap... under ideas)

I've been poking around and have been debating between FatFS and EFSL for an AVR and/or Cortex-M3 project I'm work on and am leaning towards FatFS. LFN support would be icing on the cake if you're able to publish it.

- Kyle

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

As Chan notes, commercial products may have issues. But, I see no issues with allowing the library to support LFNs. Each user must decide how to proceed.

LFN adds about 2K of code space, as my quick testing shows.

Concerning FatFs and EFSL, I looked at both, but I feel FatFs is the better of the two. I remember looking at EFSL in 2005, and it only allowed one open file. FatFs allows multiple open files.

I actually need an even more memory frugal FAT library, and the one I had developed used only 512 bytes for all filesystems, and no bytes per open file. (It was a block transfer library). Of course, performance was suboptimal, along the lines of Tiny FatFs, but I have code room to spare, and performance is not my main concern, but RAM usage is.

I'm happy to publish what I have, but I'd rather a few people test it first. It's in a public SVN repo right now, I was hopeful people would PM me for the link.

Jim

Jim Brain

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

A few notes on progress:

Reduced footprint:
I went through and optimized the codebase. As such, I was able to shave 58 bytes off the AVR compilation of the std ff.c.

Bufferless reads, writes, and seeks:
The normal code double reads a sector in certain circumstances (file pointer is on a 512 byte boundary and you ask for a multiple of 512 bytes, last sector will be preloaded for the next read, but the next read will be loaded directly into your buffer, bypassing internal preloaded buffer). I changed that so the buffer is loaded on demand.

No FIL buffer operation:
The code can now act like tff.c in that only the Filesystem buffer is used. But, you still have all the regular FatFs functionality, including multiple filesystems.

And...

1 Buffer operation:
All operations can use a single 512 byte buffer for data access. Obviously, there are performance hits if you have multiple files open, but you can minimize impacts by reading and writing 512 byte chunks of data on sector aligned boundaries.

All functions should be LFN aware. I need to add the checksum function to the LFN records, but otherwise I am just in testing mode.

Jim Brain

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

Hi,
I use TinyFATFS in one of my personal project but I miss the LFN support... I guess I could use your FATFS implementaion instead, is this somewhere available ?

thanks for your work

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

Hi,

I am interested in Checking the LFN Support for Fatfs. Can you share the source.

Thanks in advance

Regards
Gururaja

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

Gururaja, Jim said above (9 months ago) to PM for a link for the subversion repository. He may very well not be reading this old thread.

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

kmr wrote:
Jim said above (9 months ago) to PM for a link for the subversion repository. He may very well not be reading this old thread.

Sorry,

My mistake. Will check with him by PM.

Regards
Gururaja

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

Good luck, perhaps you want to report back on this thread what you learn from your PM.

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

I'll work on putting it up on jbrain.com, but you can PM me for it and I'll send a link. I know I can put it up here, but I'd rather keep it on the server so I can track it and keep it updated.

A few additional notes:

Optimized the seek so it doesn't scan the entire FAT when moving forward in the file.

You can configured the code to allow passing a FATFS structure for the drive on calls, bypassing the need to use a drive number

Multiple partitions can be scanned on a drive. No additional code needed. If enabled, top 4 bits of drive is drive, bottom 4 is partition number. 0 "superfloppy"

Added ability to open a file with just the starting cluster number. Also added an option to readdir to provide the starting sector.

Merged in most of the newest FatFs. CHaN used a different approach to optimize seek, and ours looks better at present, so we kept it.

Jim

Jim Brain

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

No, it pings me when someone adds something to the thread. I've been busy working on the project that uses this library, so I've put off making a nice web page and such. All in good time.

Jim Brain

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

Nice to hear from you, Jim. I agree, good coding takes precedence over HTML.

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

Hi,

I am myself very interested in implementing/testing lfn support to existing FAT library. I would be glad to have a look at the code.
Can someone send it to me by mail (serres.noe@gmail.com) or give me a link to a repository?

Thanks in advance.

Noé Serres
Midi Ingenierie
Toulouse (FR)

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

Since there has been a bunch of "I need FAT library for AVR" threads as of late, just bumping this. Also, I thought I'd add a bit more detail to what is available:

  • The multi-partition code works well with multiple drives, so you can have up to 15 partitions on up to 15 drives (still with 1 512 byte buffer)
  • Although not part of FatFs proper, someone has implemented code that handles multiple drive types. In our project, the 15 drives have types. Drives 0-1 are ATA, 2-3 are ATA (second channel), 4-5 are SD, and so on. Using GCC's "weak_alias" attribute, each drive interface driver can be used with or without a mux. If compiled in, the mux will dole out drive requests to the correct driver.
  • Again, though not part of the FatFs-LFN code, sd2iec has a very robust SD/SDHC driver, and I contributed a pretty robust ATA/IDE/CF driver that does not use timers (like CHaN's original does) The ATA/IDE/CF code is being tested for 48 bit addressing at present, so that should work soon.
With the exception of the "weak_alias" construct, all code is straight C. Performance is very good, though one will get better performance without the single buffer RAM limitation. My tests open 15 files at once for updates, with good performance.

As always, the code is on my SVN server, just PM or email me for access (It's GPL code, but I put a password on the SVN to keep the bots at bay)

Jim

Jim Brain

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

You'd probably get more uptake if it was more accessible - ever thought of putting it on somewhere like Sourceforge?

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

Hi Jim,

Thanks for porting LFN to FatFS.

I tried testing it on our customized board. fopen, fread all works gr8. except fwrite. This corrupts the entire file system and i have to format the SD Card.

1. i am using mmc card access through SPI mode.
File system corruption occurs irrespective of sd card size. i tried from 16 mb to 1gb. all same.

2. size of file i am trying to write varies from 200kb to 12 mb

3. I tried stopping fwrite in the middle of write ( i.e around 1mb) and i found file system already corrupted.

Right now i am trying the ata mode & will update once i get through it.

Is there any way i can fine tune how to find the bug.issue.

Also, is it possible to download files from your website in raw mode. right now i cannot access files through svn mode yet.

Thanks in advance

regards
Gururaja

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

Afaik M$ actually patented LFN on FAT , do check before using it commercialy.

They could'nt patent FAT , even though they tried hard.

But they did patent LFN.

/Bingo

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

hbr_in wrote:
Hi Jim,

Thanks for porting LFN to FatFS.

I tried testing it on our customized board. fopen, fread all works gr8. except fwrite. This corrupts the entire file system and i have to format the SD Card.


I would go into ff.h and turn off all the optimizations (single buffer per FS, single buffer for all FS, LFN, etc.) and see if the problem still shows up.
Quote:

Also, is it possible to download files from your website in raw mode. right now i cannot access files through svn mode yet.

I posted a copy of the code (and sample main.c and working sdcard driver in another thread here the other day.

https://www.avrfreaks.net/index.p...

Jim Brain

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

Dear Jim,
I'm very interested in your work.
Could I get your testing source?
My Email: michaelpan0129@gmail.com
Thanks!

Michael

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

Hi everyone,

i would like to thank Jim's work. It is very nice to have LFN support.
I am looking for the sources to give them a try. Where can i find them?

Thank you.