Embeddable FAT filesystem

Can you recommend an embeddable FAT filesystem library that meet these criteria:

Must Support:

1) FAT16, FAT32 2) Removable Media (CompactFlash) 3) Disk Format functionality 4) Check Disk functionality 5) Flush FAT capability

Should support:

1) FAT12, Long file name 2) SetFileSize capability 3) Thread-safety (through RTOS adaptation layer) 4) CompactFlash IO through common memory (rather than IO window) 5) Multiple sector writes 6) Write buffering

We are currently using a commercial, expensive, filesystem library, that is an optional component of a very well known RTOS, but are extremely disappointed with it. Removable media is not handle well at all (numerous structures are not un-initialised on disk removal, which causes problems when another disk is inserted), the format function is extremely unreliable and can actually cause in invalid FAT, there is no API to verify that the FAT is valid and the size of a file can not be set except by writing data (to minimise chance of FAT corruption on sudden power loss or device removal). Although we have the sources and have already fixed a dozen or so bugs, it would be preferable to switch to a widely endorsed good quality alternative.

Any recommendations for and/or against particular libraries would be greatly appreciated.

Best regards

Tim Clacy

Reply to
Tim Clacy
Loading thread data ...

What is the name/company name of the filessystem you are using?

I am currently using ERTFS(older version) from EBSnet inc and find it quite good. We are considering upgrading to a newer version.

Dave.

Reply to
David Williams

Dave,

Hi. ERTFS is one of the systems I am looking at as an alternative; how well is removable media handled (e.g. removing a FAT16 disk and inserting a FAT32 disk)? Can you set/allocate file size before writing any data (e.g. using an API like SetFilePointer or SetFileSize)? Can you flush the FAT out to disk on demand?

I''l let you know, privately, the Vendor of the filesystem that we are currently using, but if I were to publish that in this public newsgroup it might incurr the wrath of libel lawyers (since I have absolutley nothing good to say about that particular stinking pile of horse manure),

Regards

Tim

Reply to
Tim Clacy
[snip]

Mmm. Let's play to a variant of Woodward's game, then. I'll say a name. If you don't answer in, say, 2 days, I'll asume it's the correct name. The name has to do with air and water ;-)

-- Ignacio G.T.

Reply to
Ignacio G.T.

It looks really bad.

I will give you some words, but you can ignore if they are not usefull for you.

We tried to use a FAT file system, not as bad as you described, but because the data that we save there is absolutely essensial to our customers, and because, in our environment, the power can go alway any time, we decide to move from fat to transacional file system, that it is much more reliable than the other, so reliable that a check disk utility is not necessary. Before move from fat we looked at check disk utilities, I could find a source code at freedos, but it is really big and can not fix all the problems that can happen. The same company that has the transactional file system has the flash interface, that we use, to keep moving the new data in the flash to new sectors, so the flash will not expire ealy.

Reply to
Jose Luis Marchetti

USFiles?

BTW, if you are describing problems you've encountered, there is no possibility that a lawyer can hurt you unless you signed some specific NDA that says you can't talk about anything to do with the product.

Reply to
Lewin A.R.W. Edwards

Jose,

Hi. We will be offering one or more transacted file system. However, FAT is so widely supported it would be commercial suicide not support it. With a good library, it should be possible to make even a FAT system pretty robust (e.g. flushing FAT, seting file size).

Tim

Reply to
Tim Clacy

Lewin,

You know what these U.S. corporations can be like (oops, I should have said it was a US corporation)

Reply to
Tim Clacy

Hmm, the name is not specific to any particular type of molecule...

Reply to
Tim Clacy

Check out uC/FS at

formatting link
I believe it does all you want.

Scott

Reply to
Not Really Me

I think if he's unwilling to help us steer clear of this pile of poo, then perhaps he should be directed to Miss Information.

Reply to
FLY135

I might be wrong, but so far I was under the impression that CompactFlash cards - if operated in what's called memory mapped mode - still do IO just like in all other modes. The only difference from true IDE or IO mode is that in memory mapped mode the CF can be teached to ignore all other address lines (if A10 is set high) thus alowing a CPU to use block move operations. This is more a trick than what the name would imply since the data register is located at address '0'.

I'm using memory mapped mode in a product of mine and I never found anything else in the docs. Hence, please, if somebody can proof me wrong go ahead and do so.... !

With regard to multple sector writes, I'm not too sure here and honestly too lazy to look it up, but I thought that implementing this feature is not mandatory for CF manufacturers. I also fail to see the big performance gain in the context of CompactFlash. I figure though you need this when interfacing to other media right?

Markus

Reply to
Markus Zingg

... snip ...

Truth is an absolute defence against any libel charges. Without both lies and malicious intent you are dead safe. Just the facts, ma'am.

--
"Churchill and Bush can both be considered wartime leaders, just
 as Secretariat and Mr Ed were both horses." -     James Rhodes.
 Click to see the full signature
Reply to
CBFalconer

Any file system available that also checks (checksum or whatever)

- boot sector(s) integrity

- fat sector(s) integrity

- directory sector(s) integrity

before using data in them or even executing code out of them?

Best regards, Juergen

Reply to
Juergen Marquardt

Juergen,

Precisely. Interestingly, not even Windows XP does a decent check before mounting a FAT disk. In fact, even Windows XP's CheckDisk tool doesn't find faults that Windows 9x's 'chksk' does!

Reply to
Tim Clacy

Scott,

That looks just the job; thanks. So far, I'm up to three:

1) EBSnet - ERTFS 2) Micrium - µC/FS 3) SanDisk - Host Developer's Kit
Reply to
Tim Clacy

Markus,

Hi. The PCMCIA bus, on which CompactFlash is based, has three address spaces; IO, Memory and Attribute. Read and write cycles in the memory window are faster than in the IO window. For example, PIO mode 2 has a write cycle time of 240ns in IO window and 200ns in the memory window; that means that PIO using the IO window eats-up 20% more of the system bus bandwidth (when the PCMCIA bus shares the system bus, as in PXA255). Now if the system bus is 32 bit bus running at 100Mhz, as could be the case with PXA255, we gain 80MB/s of usable bandwidth just by doing PIO through the memory window. I can't see any good reason for doing PIO through IO space... unless you're stuck with an old x86 based system.

I can't remember whether Read/WriteMultiple is mandatory or not. In fact even if it is, some cards only support a maximum multiple of 1 anyway. However, if it is supported (as reported in the IDE device identification data), then it should be used since you can write up to 128KB in a single command (and in IO mode, generating only a single interrupt compared with up to 256).

Reply to
Tim Clacy

Uhmm - CF cards do have their own specs. Acording to these there are three modes

True IDE, IO and Memory Mapped.

As previousely mentioned, the memory mapped mode is more sort of a trick. I never worked with PCMCIA yet but I can imagine that they use this trick to fool PCMCIA in some ways. All I can tell is that memory mapped mode is NOT faster than true IDE or IO mode except for the posible gain when useing block move operations by the "host" accessing the card's address and databus.

I was only talking about the CF card's side of the interface. In general I was not at all refering to PC kind of hardware as this is not typcial in an embedded system. We were aparently not speaking about the same thing here.

Yet again, this might be true if you look at it from some sort of IO controller point of view. If you operate the CF directly hooked up to some embedded controller things look very different and then there really is not much difference except for the aditional time needed to issue the sector io command sequence multiple times.

Markus

Reply to
Markus Zingg

We are evaluating:

1) emFile from Segger Microcontroller Systeme GmbH,
formatting link
2) EFFS from HCC-Embedded,
formatting link
Also sold by CMX Systems as CMX-FFS

Anyone have any experiences with either?

John

Reply to
John Starr

Markus. Sorry I misunderstood you. To clarify:

1) Bus layer The PCMICA bus (which is the bus used by CompactFlash devices) has three address spaces; Attribute, IO and Memory.

2) Device layer CompactFlash devices can operate in true IDE mode, or CompactFlash mode (more address lines, some pin re-assignments, no x86 DMA support).

Agreed, there's no great benefit in using MultipleSector transfers. Interestingly, Lexar's 'Write Acceleration Technology' is nothing more than multiple sector writes, from what I can see; they're pushing it as something new and wonderful and yet it's been in the ATA command set for eons.

Reply to
Tim Clacy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.