SD Card FAT support issues (dosfs, fatfs,fatlib)

larwe wrote:

> 
> Observe that there are two known bugs in the current version of dosfs:
> 
> 1. Error crossing cluster boundaries on FAT32 volumes.
> 2. Cannot open file in root directory. (All the applications where I
> use the code work inside a subdirectory to avoid root entry limitations
> on FAT12/FAT16 - that's how this bug escaped).
> 

I should have noted in my previous post that my patches address
the root directory problem and also add FAT16 < 16MB support.

Regards,

Michael Grigoni
Cybertheque Museum

msg wrote:

> I should have noted in my previous post that my patches address
> the root directory problem and also add FAT16 < 16MB support.

Nitpick: My code is compliant to the letter with Microsoft's
instructions on how to select a filesystem (based on the total number
of clusters in a volume). If you changed that piece of code, you just
"fixed" something that was broken by design and entirely spec-compliant
:)

The page on MSDN where I read the details said something like "people
use all kinds of incorrect methods and slightly wrong numbers when
identifying the filesystem on a volume... here's the gospel:".

>>
>> I have an ARM7 based instrument that already is in production but would
> like
>> to a support for external memory cards to store measurement data and
>> configuration. The system only has 128K RAM and 4 MByte Flash internally
>> (plus 32K RAM in the CPU). Much of the RAM is used but can probably find 
>> a
>> few K, maybe 6K. There is already a file system in part of the Flash that
>> can store 'files' - about 2.5 MB, the rest of the flash is the code image
>> that runs directly. The file system is a simple one of my own design.
>>
>> Now, it would be nice if could optionally use a SD card to store this
> data,
>> or at least be able to backup and restore from it. To do this though I
> would
>> need to map the SD Card FAT system to match my API or at least pull the
> two
>> toward each other. I suspect that I use too much functionality though. I
> can
>> open, read, write and seek in files. I can create, delete and rename 
>> files
> &
>> directories (including moving in the tree), also inumerate directories.
>> There is a current working directory. File names are up to 31 characters,
>> including spaces and upper and lower case - but not Unicode.
>>
>> First problem. None of the three FAT modules above support long file
> names.
>> So, the first question is how easy might this be to add, or is there code
>> out there code available that can do this.
>

If you just need a SD card FAT storage module, look at the ROGUE Robotics 
uMMC.  As it has no source of RTC, the data/time tags on the files aren't 
filled in.  It uses a 5V TTL/CMOS level serial interface.  Up to 4 files may 
be open at a time.  www.roguerobotics.com

Don

"Donald Harris" <harrisdw1@verizon.net> wrote in message
news:jHtLg.27438$CL6.2164@trnddc06...
>
[snip]
>
> If you just need a SD card FAT storage module, look at the ROGUE Robotics
> uMMC.  As it has no source of RTC, the data/time tags on the files aren't
> filled in.  It uses a 5V TTL/CMOS level serial interface.  Up to 4 files
may
> be open at a time.  www.roguerobotics.com

Thanks. In fact I already have working hardware so I'm don't want to go
beyond that. Having said that, the expansion interface that I am using does
have a serial port available (at 3.3V).

Peter

"Mike Anton" <manton@nocompusmart.spamab.ca> wrote in message
news:4QlLg.9646$Mh7.4900@edtnps90...
>
> "Peter Dickerson" <first{dot}surname@tesco.net> wrote in message
> news:sAbLg.69$s4.18@newsfe3-win.ntli.net...
> > OK, firstly I should say that I'm aware there has been recent discussion
> of
[snip]
> >
>
> You may also want to take a look at EFSL, which is an open source file
> system
> library that has a port for ARM7.  It can be found
> at: http://sourceforge.net/projects/efsl/  Make sure you use the stable
> version.

Thanks, I will look into this.

Peter

I have just recently got DOSFS working in a media player project I'm 
doing with an AT91SAM7S ARM chip under WinARM, GCC 4.1.0. I had looked 
at efsl and fatlib as well as some other libraries but DOSFS seemed the 
least complicated to me and I didn't need the couple of things it 
doesn't have (yet) like the ability to create subdirectories.

FYI: I had to add the GCC __attribute__((packed)) to all of the FAT 
structures *as well as* the union. Happily there are no alignment 
issues. The biggest challenge after that was correctly getting the FAT16 
disk image onto my media (raw NAND flash via my own sector-to-flash 
management layer). After that it all worked fine.

I guess if you're using an SD card it will already be formatted, or 
easily can be.

GCC spits out a couple of warnings: one that isn't valid; the other 
simply an unused variable (de in DFS_UnlinkFile). (I also had warnings 
about different signedness of the strings (char vs. uint8_t) in places 
but today they are gone. Not sure why?)

Anyway, many thanks to Lewin for making this code available and under 
such a generous license.

-Dennis.

Dennis Greenwood wrote:
> I have just recently got DOSFS working in a media player project I'm
>
> FYI: I had to add the GCC __attribute__((packed)) to all of the FAT
> structures *as well as* the union. Happily there are no alignment

Oooh. __Good__ catch, I completely forgot to document this (I guess you
are running with an ARM?). There's a historical reason why it isn't in
there, but I won't bore you with it.

> issues. The biggest challenge after that was correctly getting the FAT16
> disk image onto my media (raw NAND flash via my own sector-to-flash
> management layer). After that it all worked fine.

It's fun to work with... :)

> I guess if you're using an SD card it will already be formatted, or
> easily can be.

With SD and MMC you don't need to perform the low-level NAND
management, fortunately.

> Anyway, many thanks to Lewin for making this code available and under
> such a generous license.

De nada.

larwe wrote:
> Dennis Greenwood wrote:
>   
>> I have just recently got DOSFS working in a media player project I'm
>>
>> FYI: I had to add the GCC __attribute__((packed)) to all of the FAT
>> structures *as well as* the union. Happily there are no alignment
>>     
>
> Oooh. __Good__ catch, I completely forgot to document this (I guess you
> are running with an ARM?). 
>   
Yep. Like I mentioned, my target is an AT91SAM7S ARM chip under WinARM, 
GCC 4.1.0. I think the OP is also targeting ARM which is why I thought I 
should share this. It would probably be good to include this caveat in 
your readme.txt file (which is otherwise great). On the other hand, most 
ARM developers will probably pick this up immediately. I'm sure I will 
will next time 8)

larwe wrote:
> Dennis Greenwood wrote:
>> I have just recently got DOSFS working in a media player project I'm
>>
>> FYI: I had to add the GCC __attribute__((packed)) to all of the FAT
>> structures *as well as* the union. Happily there are no alignment
> 
> Oooh. __Good__ catch, I completely forgot to document this (I guess you
> are running with an ARM?). There's a historical reason why it isn't in
> there, but I won't bore you with it.
> 

A good way to avoid this sort of problem is to add padding explicitly, 
so that all your data is correctly aligned, and make sure it always uses 
the natural alignment for the data.  That way it should be correct for 
(almost) all architectures.  I compile with the -Wpadded flag on, so 
that if the compiler has added alignment padding, I see it straight away.

"Dennis Greenwood" <dagwood@NOSPAMdagtronix.com> wrote in message
news:45013ABE.2090809@NOSPAMdagtronix.com...
> I have just recently got DOSFS working in a media player project I'm
> doing with an AT91SAM7S ARM chip under WinARM, GCC 4.1.0. I had looked
> at efsl and fatlib as well as some other libraries but DOSFS seemed the
> least complicated to me and I didn't need the couple of things it
> doesn't have (yet) like the ability to create subdirectories.

Unfortunately creating subdirectories was the first thing I needed to do :-(

> FYI: I had to add the GCC __attribute__((packed)) to all of the FAT
> structures *as well as* the union. Happily there are no alignment
> issues. The biggest challenge after that was correctly getting the FAT16
> disk image onto my media (raw NAND flash via my own sector-to-flash
> management layer). After that it all worked fine.
>
> I guess if you're using an SD card it will already be formatted, or
> easily can be.

Indeed.

> GCC spits out a couple of warnings: one that isn't valid; the other
> simply an unused variable (de in DFS_UnlinkFile). (I also had warnings
> about different signedness of the strings (char vs. uint8_t) in places
> but today they are gone. Not sure why?)
>
> Anyway, many thanks to Lewin for making this code available and under
> such a generous license.

I second that.

For now I have gone with fatfs because it had the nearest set of features to
my requirements and some API docs. It isn't perfect but I'm feeling
confident. I have one signed/unsigned warning and I had to set a macro for
misaligned access (using ARM7). It took about an hour to add working
directory support. I have this running on my target now. I managed to copy
files at about 70Kbyte/s using a ~2 Mbit/s SPI link using a 51 MHz ARM7
running out of slow flash over a 16 bit bus (thumb) and zero optimization
effort. I'm pretty happy with that.

In terms of behaviour the only problem so far is that . and .. don't work. I
made some changes that sort of fixed that for FAT16/12 but I need to look
into FAT32. The sort-of is that . doesn't work for the root directory. The
FAT32 problem is it doesn't work when .. is the root (to be honest, I
expected 16&12 to be a problem there and 32 to just work).

What is a problem is that the code contains very little explanation except
for the extern API.

Peter