Has anyone used FullFAT instead of FatFS?

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

So I'm having some problems with FatFS, mostly because I'm doing wonky stuff with it (trying to pipe a disk read to USB out via DMA). It works great when I'm not trying to use it in odd ways, but it's too slow for my application.

In doing some research I came across FullFAT ( http://www.fullfat-fs.co.uk/ ) and I'm curious if anyone has used this in their projects before? It seems worthwhile checking out, I just haven't had a chance to look at it yet, I might give it a shot tonight/tomorrow though.

One "caveat" for some people, it is GPLv3, specifically because it's viral and infects your project. If you're going for hobbyist/open source then I think you're fine, but commercial products might want to avoid with a very long stick. I'm sure more knowledgeable forum members can weigh in on the GPL issue though.

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

Nope, does its come with AVR sample code?

Thanks

Regards

DJ

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

djoshi wrote:
Nope, does its come with AVR sample code?

I didn't see any, but I did see a claim that it works with AVR, though they didn't say if that was AVR8, UC3, or ARM products. That does leave a bit of a barrier to entry over FatFS I suppose. Still curious if anyone's looked at it and what they may have to say about it.

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

There is an alternate to FatFs which has an AVR port (in fact I think it was only written for AVR):

http://www.roland-riegel.de/sd-r...

But search for threads here as I think there have been problems and I think it's interesting for two reasons to see the top entry of the modification history on that page. Most recent change was 23rd April 2011. That's good news as it maybe suggests this is still being maintained (well at least in the last year). However the entry itself is "Fix FAT access for cluster numbers beyond 2^15" - to me that sounds like a pretty fundamental kind of an error which maybe says something about the quality of code to expect?

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

The reason I'm curious about alternatives to FatFS is that I'm having some trouble understanding exactly what's going on in FatFS, and vanilla FatFS isn't cutting it for my application.

I'm trying to use FatFS (or other) to find the sectors on disk that I want to read, and then I'm trying to use the UC3A3's DMA to pipe from the disk to USB. I have it...sort of working, I'm actually seeing some correct data return, but it's not quite right, and I'm not sure if that's a problem in my disk_read implementation or a more fundamental issue in how FatFS works, which brings me back to why I'm curious about alternatives that may be a little easier to modify.

Some research done this morning shows I might be able to just write my own "f_dma_read" function that does exactly what I want, but I've been trying to avoid that so far since it's not the cleanest solution.

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

Quote:

understanding exactly what's going on in FatFS,

At what level? Do you mean the structure of FAT12/16/32 or at the lower level in how it does sector reads/writes?

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

clawson wrote:
Quote:

understanding exactly what's going on in FatFS,

At what level? Do you mean the structure of FAT12/16/32 or at the lower level in how it does sector reads/writes?

The structure of FAT, and I'm using an SDHC card so I think specifically FAT32. I've gotten the low level disk_read working, that's actually pretty easy. The problem I have is that I'm not actually processing any of the read data on my UC3A3, I'm trying to pipe it as fast as possible to a USB endpoint, to let a host computer actually deal with the data. Quick example:

Doing a raw read of the SD Card, there's two important functions that are called, dma_mci_2_ram (read sd card to RAM) and udi_msc_trans_block (write RAM to USB).

while (nb_sector--) {
    // (re)load first stage.
    dma_mci_2_ram((0==(buffer_id++^MOD^2))?§or_buf_0:§or_buf_1, SD_MMC_SECTOR_SIZE);

    // (re)load second stage.
    if( !b_first_step ) {
      if (!udi_msc_trans_block(true, (0==(buffer_id^MOD^2))?sector_buf_0:sector_buf_1, SD_MMC_SECTOR_SIZE, NULL)) {
    	    return false;
      }

    }
    b_first_step = false;
    // Wait completion of DMACA stage.
    while( !is_dma_mci_2_ram_complete() );
  }

Those two functions are piped, as soon as the first DMA transfer starts, a second is started to send the data to USB. It's pretty quick, about 13 MB/s.

FatFS expects the disk read to complete before any other action is taken. It also appears to be doing some sort of caching, but that's the part I'm having a bit of trouble figuring out. If I use f_read and then udi_msc_trans_block I get about 3.4 MB/s throughput. Don't get me wrong, that's great (compared to AVR8 devices), but if it can be a lot faster, then I want it to be a lot faster!