Looking for a file system for ATmega2560

Log in or register to post comments
Go To Last Post
13 posts / 0 new
Author
Message
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
#1
Posted by TheCryptoman: Fri. Oct 5, 2012 - 01:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am looking for a file system in C that I can take and use directly on my ATmega2560. I just need to create files on SD card or DataFlash, access and transfer them over FTP etc.

I have looked at Atmel application notes and there something called "Atmel File System" as described in AVR114 application note here: http://www.atmel.com/images/doc7...

However, the Atmel FS seems to be compatible with AT32UC3x, AT90USBx and ATmega32U4 only. I wonder if I can use this file system on ATmega2560 without a problem?

If this is not possible, can anyone recommend a file system I could use please?

Thanks & Regards...

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, ATmega2560, ATmega32, ATmega32U4
Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39582 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Oct 5, 2012 - 01:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most here will recommend you take a look at "fatfs" from "elmchan". Try a Forum search with those terms for discussions and links.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
Posted by TheCryptoman: Fri. Oct 5, 2012 - 02:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the pointer teusch. I noticed that besides the FatFS there is an alternative with a smaller footprint on elm-chan.org called "Petite File System", which is perfect for my application.

Regards...

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39582 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Oct 5, 2012 - 02:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Petit may well be suited for a simple app. But you have one of the big AVR models, so if you can spare the SRAM space for a sector buffer, I'd lean that way. The "standard" version is still configurable so you only "pay for what you use". In a real app it may end up to be useful to have e.g. full directory support.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97629 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Oct 5, 2012 - 03:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But you have one of the big AVR models, so if you can spare the SRAM space for a sector buffer

If he thinks Petit is a better option in a 2560 my money is on him writing an SD bootloader ;-)

(this has been done before by the way and a search will find previous projects).

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39582 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Oct 5, 2012 - 03:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

writing an SD bootloader

I read the OP as a "writing" app--perhaps logging.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
Posted by TheCryptoman: Fri. Oct 5, 2012 - 03:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since my project is already an ambitious one, I would not want to take more work on board.

If FatFS makes life easier in ATmega2560 (and it seems to be the case according to what you say), I am happy to use that one. especially, if I pay only for what I use with that one, that is a fair balance to accept.

Thanks for valuable suggestions.

Regards...

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39582 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Oct 5, 2012 - 03:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

...if I pay only for what I use ...

Note that by "pay for" I meant in terms of flash space. One of the attractions of the ElmChan over others is no restrictions on using in non-open-source apps.

The "cost" in flash space is reasonable. Probably speed as well.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
Posted by TheCryptoman: Fri. Oct 5, 2012 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yep, I got that theusch. It was useful that you pointed that out though :)

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
Posted by TheCryptoman: Wed. Dec 12, 2012 - 04:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a quick update on a bit of progress...

I managed to integrate the FatFS into my project and performed file reads and writes with it. It seems to work rather reliably even with the following crude micro SD Card implementation of mine shown in the link below.

http://www.flickr.com/photos/115...@N00/8267600044/in/photostream

I must note one thing here for those who do not already know this. If you f_sync() frequently (say after each f_write() ), your write to the SD Card becomes really slow. My observations indicate if you call f_sync() after each block of 20 byte writes, the write latency increases by about 5 to 6 times.

I will keep you posted if I make further interesting observations.

Regards...

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97629 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Dec 12, 2012 - 05:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But surely that's the whole point about f_sync()? Either you call it regularly but accept that RAM caching is effectively "dead" or you elect fro RAM caching (by not calling f_sync()) but accept there's a potential for one 512byte sector on the card not to be up to date in the event of unexpected power failure, card removal or whatever. I guess it comes down to a question of "how secure do you want the data?". If you want it really secure you pay the performance cost.

(the same is true on PCs only there you can be talking about megabytes or potentially even gigabytes of unsaved data in the RAM cache that is lost when the power cut happens!).

Top
TheCryptoman
TheCryptoman's picture
Level: Wannabe
Joined: Thu. Aug 16, 2012
Posts: 68 View posts
Posted by TheCryptoman: Wed. Dec 12, 2012 - 07:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with you clawson. The trade off is exactly as you have described. I was just amazed how much difference f_sync() makes in terms of access speed.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 97629 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Dec 12, 2012 - 07:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try doing it in a PC program and it has an equal kind of impact. This program:

#include 

FILE * fout;

int main(void) {
        fout = fopen("data", "wb");
        for (int i=0; i < (100 * 1024 * 1024); i++) {
                fputc(i, fout);
                fflush(fout);
        }
        fclose(fout);
}

writes a 100MB file in 3 seconds without the fflush(). With that present it takes 2.5 minutes!

Top