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

David Brown wrote:

> 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

Impossible, this structure is not an internal thing; it's a logical
construct that generates structure out of a flat binary read of a
FAT/dir/MBR sector. Microsoft chose the field order :)

larwe wrote:
> David Brown wrote:
> 
>> 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
> 
> Impossible, this structure is not an internal thing; it's a logical
> construct that generates structure out of a flat binary read of a
> FAT/dir/MBR sector. Microsoft chose the field order :)
> 

I was thinking about that possibility.  However, that only has an effect 
if you've got a structure like:

stuct {
	uint8 byte1;
	uint16 word1;
	uint8 byte2;
}

If you are facing something like that, things are going to go wrong no 
matter how you deal with it.  If you use packed structs, you are going 
to end up with non-aligned accesses, which can be a problem on some 
targets.  If you use non-packed structs, you'll get aligned accesses, 
but it won't match the real structure.

David Brown wrote:

> I was thinking about that possibility.  However, that only has an effect
> if you've got a structure like:
>
> stuct {
> 	uint8 byte1;
> 	uint16 word1;
> 	uint8 byte2;
> }
>
> If you are facing something like that, things are going to go wrong no
> matter how you deal with it.  If you use packed structs, you are going
> to end up with non-aligned accesses, which can be a problem on some

I don't handle it that way, because (worse than the problem you
describe above) this is not endian-neutral. Take a look at the
structures in dosfs...

larwe wrote:
> David Brown wrote:
> 
>> I was thinking about that possibility.  However, that only has an effect
>> if you've got a structure like:
>>
>> stuct {
>> 	uint8 byte1;
>> 	uint16 word1;
>> 	uint8 byte2;
>> }
>>
>> If you are facing something like that, things are going to go wrong no
>> matter how you deal with it.  If you use packed structs, you are going
>> to end up with non-aligned accesses, which can be a problem on some
> 
> I don't handle it that way, because (worse than the problem you
> describe above) this is not endian-neutral. Take a look at the
> structures in dosfs...
> 

Ah, yes - endian differences.  There's no end of fun to be had getting 
these structures to work correctly!  I seem to remember that Diab Data's 
compilers had pragmas allowing you to specifically declare data as 
little-endian or big-endian, and also as non-aligned - it would then 
generate correct code for when you accessed the structure, regardless of 
whether the endianness or alignment matched.  If only other compilers 
had the same sort of pragmas, your code would be a lot easier.

"larwe" <zwsdotcom@gmail.com> wrote in message
news:1157909783.631161.313910@e3g2000cwe.googlegroups.com...
>
> David Brown wrote:
>
> > I was thinking about that possibility.  However, that only has an effect
> > if you've got a structure like:
> >
> > stuct {
> > uint8 byte1;
> > uint16 word1;
> > uint8 byte2;
> > }
> >
> > If you are facing something like that, things are going to go wrong no
> > matter how you deal with it.  If you use packed structs, you are going
> > to end up with non-aligned accesses, which can be a problem on some
>
> I don't handle it that way, because (worse than the problem you
> describe above) this is not endian-neutral. Take a look at the
> structures in dosfs...

Its probably better in this case to use macros to define accessors. The
macros being there just to make the code more readable and self commenting.
There isn't any nice solution to this sort of problem for portable code.

Peter

Peter Dickerson <first{dot}surname@tesco.net> wrote:

> There isn't any nice solution to this sort of problem for portable code.

But of course there is: stop believing that C structs are meant to be
used as exact matches of externally defined data structures.  They're
not.  Use C structs for internal handling, but *only* interface them
to the outside world through a properly designed "serialization" layer
which handles the mapping from C integers to octets on the line or the
medium.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"Hans-Bernhard Broeker" <broeker@physik.rwth-aachen.de> wrote in message
news:4mlkj6F6o8lgU3@news.dfncis.de...
> Peter Dickerson <first{dot}surname@tesco.net> wrote:
>
> > There isn't any nice solution to this sort of problem for portable code.
>
> But of course there is: stop believing that C structs are meant to be
> used as exact matches of externally defined data structures.  They're
> not.  Use C structs for internal handling, but *only* interface them
> to the outside world through a properly designed "serialization" layer
> which handles the mapping from C integers to octets on the line or the
> medium.

So we agree. There are solutions, but they aren't nice. :-)

Peter

On Fri, 08 Sep 2006 11:41:18 +0200, Dennis Greenwood
<dagwood@NOSPAMdagtronix.com> wrote:

>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.

Using the __attribute__((packed)) breaks the code generated using the
header files defined for the Philips LPC series which uses bitfields
to define the LPC hardware registers. Many of the small development
boards come with examples using these header files. In the GCC
documentation it also warns that code compiled with this attribute set
might not be binary compatible with code compiled without it.

Regards
  Anton Erasmus

larwe wrote:
> Peter Dickerson wrote:
>
> > > > First problem. None of the three FAT modules above support long
> > > > file names. So, the first question is how easy might this be to
> > >
> > > Nor will they.  There are patent problems involved.
> >
> > I understand that there are patent problems although it I thought that this
> > was still an open question. If this is now resolved in MS's favour then I
> > won't go down that route.
>
> I'm not aware that there has ever been any litigation about this. I'm
> not even sure if MS actively enforce it. However it isn't a gray area:
> the way LFNs are implemented on FAT volumes is patented - and hence I'm
> not going to implement them (never mind that I have no use for them
> either).
>
This kind of stuff is a bit concerning you know. Patenting an algorithm
of some sort?

-Isaac

Isaac Bosompem wrote:
> This kind of stuff is a bit concerning you know. Patenting an algorithm
> of some sort?

Where have you been for the last decade or so?