FAT16/32 codebase for AVR

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

I thought I'd post a note here that I am working on a FAT16/32 driver for AVR.

I know there are some commercial ones available, but I'm working on a GPL project, so that really didn't fit. YAMPP's FAT routines appear to be read routines, and fatdriveravr (which is an excellent project, BTW) has some limitations for my purposes.

My requirements include:

    Ability to read and write files
    FAT16 and FAT32 support
    long file name support
    support for master and slave devices
    very low RAM requirements (600 bytes or so)
    no external interface required
    support for drives >137GB
    no external library requirements

Obviously, not all of the requirements are met yet, but I've only been writing code for a few days. I have partition read, rootdir read, subdir read, and file read routines working. 3 ports are all that is needed to interface (as in many other projects). FAT16 8.3 and LFN dir support is working, and FAT32 is coded, though I need to test it. sector chaining appears to work. master and slave device support is working. reads can be done with just a 512 byte buffer and some longs and such, with an additional user supplied buffer for names when doing dir reads (can be small as 8+3+2, or 256 bytes. I am still tracking down docs on 48 bit addressing mode for drives >137GB, but I think I know how to do it, and it's not the biggest priority. It looks like writes can be done with a single 512 byte buffer, but that code is not done yet Multiple open file support is in place, though there are limits given memory requirements. The fd structure is about 40 bytes, so you can have a handful of files open in 1024 bytes. Current codebase with ATA, FAT16/32 read routines is about 4200 bytes, so I am hopeful write will add no more than a couple more k. Code is in C, and should be portable to any processor.

However, if someone knows of an already completed codebase that supports the above requirements, I'm all ears. Still, even if I end up using another library, the experience of doing the IDE and FAT routines has been very educational.

I'm not quite ready to dump code into the wild, but if if there aren't other libraries that support these features and people are interested, I'll package it up and place it somewhere.

Jim

Jim Brain

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

I for one would love to see what you've got so far. I've been looking at other project and investigating the protocol before jumping into doing something similar (though less complicated) myself. Have you thought about putting it in the Academy? Would be nice to have a jumping off point for other projects...

-john

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

The FAT 16/32 code by these two guys is pretty good. Angelo Bannack, Giordano Bruno Wolaniuk
It does not support long names though.

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

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

Here's the project on SourceForge:
http://sourceforge.net/projects/...

Wouldn't it be better to start off with this, and just add the capabilities you want? Don't reinvent the wheel....

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

Don’t be ashamed to reinvent a wheel but it’s a shame to invent nothing!

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

jesper wrote:
The FAT 16/32 code by these two guys is pretty good. Angelo Bannack, Giordano Bruno Wolaniuk
It does not support long names though.

Which is the FAT Driver AVR code I noted. It's a great piece of code, but it does not support long file names (pretty easy to add), is pretty big at 15kB (wasn't sure how to reduce that by half or so), only allows one open file (tough to add support for multiple files), and requires 2 512 byte buffers for operation on a single file (I wanted to support an open file in a 1KB part)

EW wrote:
Here's the project on SourceForge:
http://sourceforge.net/projects/...

Wouldn't it be better to start off with this, and just add the capabilities you want? Don't reinvent the wheel....

I looked at that codebase before I started, but could not figure out how add the "lightness" I needed without destroying the elegance of their work. Bannack/Wolaniuk support many APIs that use internal variables and buffers to hold drive information. ataGetSize() and fatOpen(), for example. Their direntry is laid out according to the FAT spec. Mine uses a more logical layout. Finally, my codebase has no cache. It uses the data buffer as a temp holding spot for any internal operations that need to be performed to read or write data. Arguably, FAT Driver AVR will be faster, as I have to fetch the FAT sector for every cluster.

My codebase allows infinite open files (memory permitting, of course), by pushing all the memory requirements to the user:

FAT_open_fs(Partition p, FAT_fs* fs, unsigned char buf[512]);
and
FAT_open_file(FAT_fs fs, FAT_fd* fd, FAT_dir_entry entry, unsigned char buf[512]);

The structures are pretty small 22-40 bytes each, but the developer is responsible for passing all the data in to the calls.

However, I will look again at the code to see if it is possible for me to add to it.

Jim

Jim Brain

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

I looked at FAT Driver AVR again, and I think I can implement all their higher level apis on top of my FAT code. Most problematic in extending their code to work with my project are the FAT and ATA internal static structures they use.

I also noticed they support CHS mode. Is there still a need for CHS support? Isn't any disk larger than 540MB LBA by default? CHS support is pretty easy, just extra code.

In any case, I debugged FAT32 read support last night, so read and dir routines are all there. However, I've never placed anything in the Academy, so I'll have to go read up on that.

Jim

Jim Brain

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

Just a hint for JBrain.

If you are writing fat code,, you are not dealing with CHS at any time of the day.
CHS is a different layer :)

MY MICROCONTROLLER CAN BEAT THE HELL OUT OF YOUR MICROCONTROLLER /ATMEL

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

I am attempting to use the code for the FAT 16/32 File System Driver for ATMEL AVR created by Angelo Bannack and Giordano Bruno, but am having problems when trying to write a file. We know the program is not getting hung up in any while loops, but these items are not working correctly :

ATA read sector, it doesn't recongnize the format, and it says the drive is full. For some reason it doesn't seem to be getting information from the disk.
If anyone has any ideas to why this is occuring or could think of any pitfalls, we would greatly appreciate it. We are working on a school project and have been stumped for awhile.

Thanks, Ben

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

@jbrain:
I would be interested in looking at your code for LFN support, if you're willing to publish.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
bigbosu wrote:
I am attempting to use the code for the FAT 16/32 File System Driver for ATMEL AVR created by Angelo Bannack and Giordano Bruno, but am having problems when trying to write a file. We know the program is not getting hung up in any while loops, but these items are not working correctly :

ATA read sector, it doesn't recongnize the format, and it says the drive is full. For some reason it doesn't seem to be getting information from the disk.
If anyone has any ideas to why this is occuring or could think of any pitfalls, we would greatly appreciate it. We are working on a school project and have been stumped for awhile.

Thanks, Ben

I'm not quite sure anybody ever tried the code with FAT16 media. Particularly root directory doesn't seem to be handled correctly.

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

Just to poke this thread (I know it is old), hobby time has returned and I am finishing up the codebase. It has the following features:

    Handles mutiple drives with multiple partitions each
    Low memory footprint (1K and change on writes, 512 bytes + a bit for reads, directories, etc.)
    FAT16 and FAT32 support
    LFN support (what a bear!)

    Since I was last focused on this, I see others have created a multi-platform FAT driver (FATFS), so I have downloaded their code to see if I can add my LFN and multiple partition support into that code base).

    I am not ready to publish, but will open my SVN repo to anyone who PMs me.

    I know, it's been a long time, but it's been fun to learn FAT.

    Jim

Jim Brain

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

I decided, instead of re-inventing all of the wheel, I took the good parts of my LFN code and added them to FatFs. All routines are now LFN-aware.

I have another thread describing this in more detail, so I'll close this one out.

Jim Brain

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

Hi EW,

 

            I gone through the fat driver avr which you posted in the earlier post, but i got some errors while compiling the code. I met the requirements to use that code. I installed the winAVR latest version tool for AVR studio 5. the ERRORS are " cbi and sbi definitions are missing " in the function definitions of ATA read and write in ATA.C file. I included a header file "avr/sfr_defs.h" but errors are remains. I selected "ATmega128" device for this code. Please give some suggestions to solve my problem. Thanks in Advance.   

-Thanks & Regards

Satish Kumar Bh

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

satish.drm wrote:

Hi EW,

 

You do realise that you are trying to talk to someone from nearly 7 years ago? Do you think you will be around in 7 years when someone else asks if you solved your problem? I doubt it...

 

Ross McKenzie ValuSoft Melbourne Australia

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

the ERRORS are " cbi and sbi definitions are missing "

They moved (a long time ago!) to:

#include <compat/deprecated.h>

but if you are looking at code that used them I'd seriously think about whether you want to use it! It is years (almost a decade!) out of date.

 

if your goal here (from the thread title) is FAT16/32 on AVR then the "modern" solution we all use is here:

 

http://elm-chan.org/fsw/ff/00ind...

Last Edited: Mon. Nov 24, 2014 - 01:04 PM