IDE DMA access and FAT32 Table size question.

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

All,

Some of this isn't possible on the AVRs but as the group seems to be so diverse I thought I'd ask anyway. You never know.

I've just been thinking on how the transfer rate to and from an ATA harddrive could be increased. One way is to read the FAT TOC entries and cache the locations of the clusters for the particular file you want to read into memory therefore reducing the need to seek back to the TOC. I should imagine this will work quite well. (512bytes of RAM would allow 4Mbytes of file to be read in one go on 32k cluster) It could be taken one step further by caching the whole TOC into memory. Of course you'd need a processor with megabytes of RAM but hey! I am right in thinking that the size of the TOC is:

TOC size = Number of clusters * 4bytes + ancillary data.

Therefore

Number of clusters = Drive size / Cluster Size

So for a 40Gbyte drive with a 32Kbyte cluster size the rough size of the TOC would be:

40,000,028,672 / 32768 * 4 = 4,882,816 bytes?

The second question is: has anyone out there ever tried to transfer data from a HDD to memory using DMA transfer? Do you have any links on where to look? I've tried googling but the overwhelming volume of PC related trouble shooting and FAQs just gets in the way of engineering. Doh! ;-)

Take care and thanks,

Tim

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

Quote:
512bytes of RAM would allow 4Mbytes of file to be read in one go

Only if the file is not fragmented.
And also there is a max number of sectors that you can request from the drive wheter it be DMA or PIO.
In order to do DMA, the source or destination RAM must be isolated from the processor RAM, which means lots of hardware, and no ram access while reading or writing, unless you design some very fancy dual port ram hardware.
Phil

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

Why only if the file is not fragmented? 512/4bytes holds 128 32 bit cluster numbers of the file. Fragmentation is not an issue with caching the FAT addresses to reduced the need to scan the fat.

The file would still need to be transfered in the normal manner.

Tim

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

Quote:
Why only if the file is not fragmented?

Because that is the way the FAT works.
Consider a typical scenario.
There are 10 files, each occupies 10 clusters unfragmented.
Then you delete the 5th file (not move it to the recycle bin). This leaves a 10 cluster "hole".
Then you create a file of 5 clusters. This "fills" half the hole.
Then you create a 10 cluster file. This will fill the other 5 clusters, and then start using the cluster after the 10th file.
Hey pesto, a fragmented file.
Then consider appending multiple opened files.
Now consider what happens if your fat buffer is smaller than the "hole" or if you like if the file is bigger than what you fat buffer holds.
In fact the next cluster doesn't even have to be after the preceding cluster.
When reading files you can calculate what FAT sector to load into you FAT buffer, but when writing files, the only way is to scan the FAT, looking for a free cluster.
This takes time, whether you are using DMA or not.
Phil

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

Phil,

I think you're missing the point. He's not storing the FAT table, but the FAT chain for the file in question.

Been there, done that. It works !

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.