Forums

Embedded RTOS - features poll

Started by Stargazer September 19, 2010
In article <Xns9E005C2987DF7WarrensBlatherings@85.214.73.210>, 
ve3wwg@gmail.com says...
> Mark Borgerson expounded in > news:MPG.2706a0cd11868d9989c58@news.eternal-september.org: > > > In article <Xns9DFD9C76F438SnarkCharmedFerSure@188.40.43.230>, > > snark@cogeco.ca says... > > >> But but.. on a memory card, unlike a floppy, you don't need > >> to write _every_ sector. You need to write the boot sector, > >> root dir sector(s) (FAT16), and _one_ FAT table. If > >> you're formatting FAT32, then you also need to allocate one > >> cluster to hold the start of the root directory and fill > >> that cluster with zeros. All remaining clusters can > >> be left in "as is" condition. > > > > Are you assuming that the card has never been used and > > is starting with 0xFF in all sectors? I suppose that would > > be fine if the system was never reused or tested before > > being deployed. > ... > > Mark Borgerson > > It doesn't matter. Why would it? > > When you allocate a new cluster to a root/sub-directory, you > zero it then (zero is the 'end of directory' marker). When you > allocate a cluster to a file (being written and extended), you > just make the cluster available - the application just overwrites > the garbage in those sectors.
I think I misinterpreted your first statement. I missed the fact that you did say that you had to write _one_ FAT table when you format the card. However, on a large card, writing 16MBytes of FAT could take quite a while. I was thinking that, if the empty disk had all sectors filled with 0x00, you might not have to write all the FAT sectors, since 0x00000000 is the FAT marker for an unused cluster.
> > The flash controller takes care of erasing the "pages" of > memory and "rewrites" the sector as needed. To the end user, > it just looks like a disk. >
Mark Borgerson
Mark Borgerson expounded in news:MPG.270a85515a5d8ab5989c6a@news.eternal-
september.org:

> I think I misinterpreted your first statement. I missed the fact > that you did say that you had to write _one_ FAT table when you > format the card. However, on a large card, writing 16MBytes > of FAT could take quite a while.
Writing 32 sectors isn't huge (32k/512 bytes each). Comparing it to a file write, if you use 8 sectors per cluster, it is only two clusters worth of writing.
> I was thinking that, if the empty disk had all sectors filled > with 0x00, you might not have to write all the FAT sectors, > since 0x00000000 is the FAT marker for an unused cluster.
That doesn't work on a couple of levels. The first FAT entry is supposed to include the media type byte, though I doubt many implementations pay any attention to it there. Also if you use FAT32, your root directory is located in a cluster. So at least one cluster has to be pre-allocated. But those things could be localized to the first FAT sector. Warren
In article <Xns9E016F015CB2EWarrensBlatherings@85.214.73.210>, 
ve3wwg@gmail.com says...
> Mark Borgerson expounded in news:MPG.270a85515a5d8ab5989c6a@news.eternal- > september.org: > > > I think I misinterpreted your first statement. I missed the fact > > that you did say that you had to write _one_ FAT table when you > > format the card. However, on a large card, writing 16MBytes > > of FAT could take quite a while. > > Writing 32 sectors isn't huge (32k/512 bytes each). Comparing > it to a file write, if you use 8 sectors per cluster, it is only > two clusters worth of writing.
I don't understand this. IIRC, a cluster can be no more than 32KB for Windows and FAT32. A 32GB volume then needs about 1,024,000 entries of four bytes each. or 4MBytes for the minimum size FAT. I can't get from there to your 32 sectors.
> > > I was thinking that, if the empty disk had all sectors filled > > with 0x00, you might not have to write all the FAT sectors, > > since 0x00000000 is the FAT marker for an unused cluster. > > That doesn't work on a couple of levels. The first FAT entry > is supposed to include the media type byte, though I doubt > many implementations pay any attention to it there.
So, could you just write the first FAT entry and leave the rest of the sectors as 0x00s?
> > Also if you use FAT32, your root directory is located in > a cluster. So at least one cluster has to be pre-allocated. > > But those things could be localized to the first FAT sector. >
Mark Borgerson
Mark Borgerson expounded in
news:MPG.270bb366405ce964989c70@news.eternal-september.org: 

> In article <Xns9E016F015CB2EWarrensBlatherings@85.214.73.210>, > ve3wwg@gmail.com says... >> Writing 32 sectors isn't huge (32k/512 bytes each). Comparing >> it to a file write, if you use 8 sectors per cluster, it is only >> two clusters worth of writing. > > I don't understand this. > > IIRC, a cluster can be no more than 32KB for Windows and FAT32.
See: http://www.maverick-os.dk/FileSystemFormats/FAT16 _FileSystem.html#SectorsPerCluster "Sectors Per Cluster: This is the number of sectors per cluster. The allowed values are: 1, 2, 4, 8, 16, 32 or 128. But de-facto is that most combinations of 'BytesPerCluster' * 'SectorsPerCluster' which gives a total value over 32 Kb per cluster, are not supported on many system[s]." Note: in the above, I believe the author meant 'BytesPerSector', rather than 'BytesPerCluster'. Otherwise his math is meaningless. Given his 1999 copyright date: <META NAME="copyright" CONTENT="(C) 1999 Lasse Krogh Thygesen"> his "level of support statement" may not be accurate anymore (no mention of any O/S later than WinNT or Win98 is mentioned).
> A 32GB volume then needs about 1,024,000 entries of four bytes each. > or 4MBytes for the minimum size FAT. I can't get from there to > your 32 sectors.
From your "16MBytes of FAT" - 16MB / 512 => 32 sectors.
>> > I was thinking that, if the empty disk had all sectors filled >> > with 0x00, you might not have to write all the FAT sectors, >> > since 0x00000000 is the FAT marker for an unused cluster. >> >> That doesn't work on a couple of levels. The first FAT entry >> is supposed to include the media type byte, though I doubt >> many implementations pay any attention to it there. > > So, could you just write the first FAT entry and leave the > rest of the sectors as 0x00s?
Yes (assuming you meant that the remaining sectors are zeroed _and_ written out). The only caveat would be if you tested for and found bad sectors. Then you'd also need to mark those clusters containing bad sectors as bad (unavailable) - FFF7 (FAT16). Warren
Warren expounded in
news:Xns9E018EE612954WarrensBlatherings@85.214.73.210: 

> Mark Borgerson expounded in > news:MPG.270bb366405ce964989c70@news.eternal-september.org: > >> In article <Xns9E016F015CB2EWarrensBlatherings@85.214.73.210>, >> ve3wwg@gmail.com says... >>> Writing 32 sectors isn't huge (32k/512 bytes each). Comparing >>> it to a file write, if you use 8 sectors per cluster, it is only >>> two clusters worth of writing. >> >> I don't understand this. >> >> IIRC, a cluster can be no more than 32KB for Windows and FAT32. > > See: > > http://www.maverick-os.dk/FileSystemFormats/FAT16 > _FileSystem.html#SectorsPerCluster > > "Sectors Per Cluster: This is the number of sectors per cluster. The > allowed values are: 1, 2, 4, 8, 16, 32 or 128. But de-facto is that > most combinations of 'BytesPerCluster' * 'SectorsPerCluster' which > gives a total value over 32 Kb per cluster, are not supported on many > system[s]." > > Note: in the above, I believe the author meant 'BytesPerSector', > rather than 'BytesPerCluster'. Otherwise his math is meaningless. > > Given his 1999 copyright date: > > <META NAME="copyright" CONTENT="(C) 1999 Lasse Krogh Thygesen"> > > his "level of support statement" may not be accurate > anymore (no mention of any O/S later than WinNT or Win98 > is mentioned). > >> A 32GB volume then needs about 1,024,000 entries of four bytes each. >> or 4MBytes for the minimum size FAT. I can't get from there to >> your 32 sectors. > > From your "16MBytes of FAT" - > > 16MB / 512 => 32 sectors. > >>> > I was thinking that, if the empty disk had all sectors filled >>> > with 0x00, you might not have to write all the FAT sectors, >>> > since 0x00000000 is the FAT marker for an unused cluster. >>> >>> That doesn't work on a couple of levels. The first FAT entry >>> is supposed to include the media type byte, though I doubt >>> many implementations pay any attention to it there. >> >> So, could you just write the first FAT entry and leave the >> rest of the sectors as 0x00s? > > Yes (assuming you meant that the remaining sectors are zeroed > _and_ written out). > > The only caveat would be if you tested for and found > bad sectors. Then you'd also need to mark those clusters > containing bad sectors as bad (unavailable) - FFF7 (FAT16).
Actually, there was one more thing I forgot about: The last part of the FAT will likely need FAT entries indicating that the last n clusters are unavailable. This happens when your FAT table has more entries in it than, available clusters to manage. Otherwise, instead of running out of space, you'll get I/O errors when the FS attempts to use non-existing clusters (unusable space will be allocated from the FAT). Warren
In article <Xns9E018EE612954WarrensBlatherings@85.214.73.210>, 
ve3wwg@gmail.com says...
> Mark Borgerson expounded in > news:MPG.270bb366405ce964989c70@news.eternal-september.org: > > > In article <Xns9E016F015CB2EWarrensBlatherings@85.214.73.210>, > > ve3wwg@gmail.com says... > >> Writing 32 sectors isn't huge (32k/512 bytes each). Comparing > >> it to a file write, if you use 8 sectors per cluster, it is only > >> two clusters worth of writing. > > > > I don't understand this. > > > > IIRC, a cluster can be no more than 32KB for Windows and FAT32. > > See: > > http://www.maverick-os.dk/FileSystemFormats/FAT16 > _FileSystem.html#SectorsPerCluster > > "Sectors Per Cluster: This is the number of sectors per cluster. The > allowed values are: 1, 2, 4, 8, 16, 32 or 128. But de-facto is that most > combinations of 'BytesPerCluster' * 'SectorsPerCluster' which gives a > total value over 32 Kb per cluster, are not supported on many system[s]." > > Note: in the above, I believe the author meant 'BytesPerSector', > rather than 'BytesPerCluster'. Otherwise his math is meaningless.
I think the author is also mixing up bits and bytes. 32KB != 32Kb.
> > Given his 1999 copyright date: > > <META NAME="copyright" CONTENT="(C) 1999 Lasse Krogh Thygesen"> > > his "level of support statement" may not be accurate > anymore (no mention of any O/S later than WinNT or Win98 > is mentioned). > > > A 32GB volume then needs about 1,024,000 entries of four bytes each. > > or 4MBytes for the minimum size FAT. I can't get from there to > > your 32 sectors. > > From your "16MBytes of FAT" - > > 16MB / 512 => 32 sectors.
How do you divide (16 x 1024 x 1024) by 512 and get 32? When I do that division I get 32768 sectors.
> > >> > I was thinking that, if the empty disk had all sectors filled > >> > with 0x00, you might not have to write all the FAT sectors, > >> > since 0x00000000 is the FAT marker for an unused cluster. > >> > >> That doesn't work on a couple of levels. The first FAT entry > >> is supposed to include the media type byte, though I doubt > >> many implementations pay any attention to it there. > > > > So, could you just write the first FAT entry and leave the > > rest of the sectors as 0x00s? > > Yes (assuming you meant that the remaining sectors are zeroed > _and_ written out). > > The only caveat would be if you tested for and found > bad sectors. Then you'd also need to mark those clusters > containing bad sectors as bad (unavailable) - FFF7 (FAT16).
I don't think you even use FAT16 on a 32GB volume with a single partition. Mark Borgerson
Mark Borgerson expounded in
news:MPG.270c0da2b301cc94989c72@news.eternal-september.org: 

>> From your "16MBytes of FAT" - >> >> 16MB / 512 => 32 sectors. > > How do you divide (16 x 1024 x 1024) by 512 and get 32? > > When I do that division I get 32768 sectors.
My bad. I was thinking 32k. In any case, formatting a FAT is at least two orders of magnitude less than formatting the whole drive/partition. Look at the ratios involved (assuming FAT32): 128 cluster entries in one FAT sector, vs 8 sectors per cluster (for example). This is 1 sector vs 128 * 8 sectors, i.e. a ratio of 1 : 1024 ! It's actually worse than that because if you do the whole drive you do FAT + clusters: 1 : 1024 + 1 So formatting a FAT takes 1/1025th the time it takes to do the whole drive. Very significant, that. Even if you dumbed it down to 1 sector per cluster which nobody does since FAT12 floppies, you're looking at a ratio of 1 : 128+1.
>> The only caveat would be if you tested for and found >> bad sectors. Then you'd also need to mark those clusters >> containing bad sectors as bad (unavailable) - FFF7 (FAT16). > > I don't think you even use FAT16 on a 32GB volume with a single > partition. > > Mark Borgerson
The procedure is necessary and the same for both FAT16 and FAT32. http://support.microsoft.com/kb/310561 "Windows XP supports the creation of primary partitions and logical drives of up to 4 gigabytes (GB) using the FAT16 file system. The maximum cluster size is 64K." So you can see that the 32K limit was extended to 64K in XP. And yes, FAT16 has its limits, but so what? Use FAT32. MS says "FAT32 supports drives up to 2 terabytes in size.". FAT32 only changes a few things (from FAT16) and is a simple upgrade to support (it was trivial for my own software to support both). As far as long file names go, you don't have to support them in your AVR code, unless you really really want to. I don't bother. Warren