SD flash card filesystem

I know of people that have used this with success:

although it is apparently a little bloated (?).

Regards, Richard.

• formatting link

• formatting link
  for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC

This one is nice and simple to implement and free too.

uC/FS from Micrium offers FAT and non-FAT alternatives.

Scott

"Tom Lucas" wrote in message news: snipped-for-privacy@iris.uk.clara.net...

I tried that first, too, but had a few issues. It's a reasonable choice is you're very resource constrained. Note that it does the FAT filesystem side of things rather than the SD Card driving (which isn't too bad). Segger

have a commercial offering called emFile. But I didn't use that either. I ended up using FatFs from (on an ARM), modifying it to handle long file names, which we are talking to M$ about the licensing issues (round $0.25 per).

Peter

I've implemented the Flash File System from Priio

on an AT91Sam7S256. It seems dependable and the memory footprint is not too large (under 16K, IIRC). It took a bit of work to convert the code to the IAR compiler that I use.

You get the full source code for a one-time fee of $299US. No license fees after that. The code is well commented, but uses a TON of #ifdef and #if statements to select amongst all the options for read/write, read-only, debug output, multiple open files, etc. All the options can make the source a bit difficult to sort through unless you are as good at remembering the #define values and ignoring unused code as is the compiler. I would have preferred separate file sets for two or three of the most popular options that had the code cleaned up by a bit of pre-processing of the optional code.

The above is a minor quibble, though. I haven't had to look at the code in a month or more. The files it writes out can be read without problems on a PC. I use the FAT16 format, as I'm using some 1GB Sandisk SD cards.

I did find some very significantly different write times for different brands of SD cards. Some cards took 5 to 8 times longer per sector write than the SanDisk cards I have settled on. I suspect that the difference has to do with subtle timing differences in the response to the card initialization or some other setup commands. It is the subtle issues of timing and response that convinced me that I didn't want to do all SPI code myself.

When judged in terms of interface simplicity, cost per megabyte, and reliability (wear leveling, etc), the SD card is really the best way to add significant data storage to an embedded project. An earlier project with an Atmel 8MB serial data flash probably cost about

30 times as much per megabyte of storage.

Mark Borgerson

Segger

offer the same product emFile. Micrium are I believe only a reseller.

Not Really Me wrote:

You are correct, it is a Segger product distributed by Micrium. I believe the price is the same from both. If you are located in the US/Canada then Micrium can probably offer more direct support. In Europe then Segger.

Interesting problem. I remember when I was working with Occam that there was an editor called Origami. It had the ability to "fold" the source file and hide sections of code. I believe it did this using markings in comment strings that told the editor where the folds were. It seems like this would be useful to add to an editor the ability to hide sections of code that were inside #ifdef statements that were not enabled. Has anyone done this? I know that Codewright has many facilities including syntax highlighting that would be similar, but I don't think I have ever seen folding implemented other than in Origami.

Language sensitive folding should make the problem of viewing a file containing a lot of #ifdefs a lot easier to read.

Check out

I don't think it will fold just the conditional compilation, there is a fold all, unfold all (includes other constructs), or you can manually fold individual constructs.

I think there are some command line utilities that will also parse the code and show you the result minus the conditional compilation.

Regards, Richard.

• formatting link

• formatting link
  for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430 Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC

There is an old program called "scpp" which is a standard C pre-processor, but with the ability to list exactly which #defines should be expanded. Any #ifdefs that wind up with constant (foldable) values get processed too (removed), which is exactly what you're asking for.

If you can't find it, I have source here. It needs yacc and lex to build and IIRC needs changes for flex and bison. It has a 1985 Tektronix copyright with a non-commercial use license.

Clifford Heath.

I just tried setting up the IAR compiler to save the preprocessed file (filesys.i). Looking at that file, it seems that ifdefs have all been evaluated and the resulting code looks like it should be easily edited to make a clean and compilable C file. It will take some editing of the results of all the include files in the original, but the IAR compiler has an option to preserve comment lines and it kept the output nicely indented.

The downside of this approach is that all the defined numerical constants are now just numbers in the source code.

I will probably not bother with much editing, and will just keep the intermediate file around for those times when I want to figure out some function in the code. For that usage, it's probably handier to have the actual numbers rather than the defined constant names anyway.

Mark Borgerson