Reply by matt...@avisaro.com December 16, 20042004-12-16
Hi,

why bother with the doing it by yourself. The company I work for is
doing modules which provide access to Compact Flash cards through a
serial interface (RS232).

By using simple "AT" commands, you can read and write files. The file
system used by the module is FAT, so you can process them directly on a
PC. There are commands to check the presents of a card, read out the
capacity, ...

Check out: www.avisaro.com

Matthias

Reply by Tim Clacy September 21, 20042004-09-21
John Starr wrote:
> Tim, > > One more for the list: Fusion Flash File System from Unicoi Systems. > www.unicoi.com. > > John
John, Cheers, but that looks like it's specifically for flash devices rather than IDE/ATA devices. Tim
Reply by John Starr September 18, 20042004-09-18
Tim,

One more for the list: Fusion Flash File System from Unicoi Systems.
www.unicoi.com.

John



Reply by Not Really Me September 17, 20042004-09-17
Tim Clacy wrote:
> John Starr wrote: >> "Tim Clacy" <nospamtcl@nospamphaseone.nospamdk> wrote in message >> news:4145b871$0$222$edfadb0f@dread16.news.tele.dk... >>> Can you recommend an embeddable FAT filesystem library that meet >>> these criteria: >>> >> <snip> >> >> We are evaluating: >> >> 1) emFile from Segger Microcontroller Systeme GmbH, www.segger.com >> >> 2) EFFS from HCC-Embedded, www.hcc-embedded.com. Also sold by CMX >> Systems as CMX-FFS >> >> Anyone have any experiences with either? >> >> John > > John, > > Many thanks; that's 5 options now: > > 1) EBSnet - ERTFS > 2) Micrium - &#4294967295;C/FS > 3) SanDisk - Host Developer's Kit > 4) Segger - emFile > 5) HCC Embedded - EFFS-FAT > > Regards > > Tim
Just for clarity 2) Micrium - &#4294967295;C/FS and 4) Segger - emFile are the same product. Segger wrote the original code, Micrium resells in the US. Scott
Reply by Tim Clacy September 16, 20042004-09-16
John Starr wrote:
> "Tim Clacy" <nospamtcl@nospamphaseone.nospamdk> wrote in message > news:4145b871$0$222$edfadb0f@dread16.news.tele.dk... >> Can you recommend an embeddable FAT filesystem library that meet >> these criteria: >> > <snip> > > We are evaluating: > > 1) emFile from Segger Microcontroller Systeme GmbH, www.segger.com > > 2) EFFS from HCC-Embedded, www.hcc-embedded.com. Also sold by CMX > Systems as CMX-FFS > > Anyone have any experiences with either? > > John
John, Many thanks; that's 5 options now: 1) EBSnet - ERTFS 2) Micrium - &#4294967295;C/FS 3) SanDisk - Host Developer's Kit 4) Segger - emFile 5) HCC Embedded - EFFS-FAT Regards Tim
Reply by Tim Clacy September 16, 20042004-09-16
Markus Zingg wrote:
>> Hi. The PCMCIA bus, on which CompactFlash is based, has three address >> spaces; > > Uhmm - CF cards do have their own specs. Acording to these there are > three modes > > True IDE, IO and Memory Mapped.
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).
> 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. > >> 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 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. > >>>> 5) Multiple sector writes >>> >>> 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? >> >> 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). > > 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.
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 by John Starr September 16, 20042004-09-16
"Tim Clacy" <nospamtcl@nospamphaseone.nospamdk> wrote in message
news:4145b871$0$222$edfadb0f@dread16.news.tele.dk...
> Can you recommend an embeddable FAT filesystem library that meet these > criteria: >
<snip> We are evaluating: 1) emFile from Segger Microcontroller Systeme GmbH, www.segger.com 2) EFFS from HCC-Embedded, www.hcc-embedded.com. Also sold by CMX Systems as CMX-FFS Anyone have any experiences with either? John
Reply by Markus Zingg September 16, 20042004-09-16
>Hi. The PCMCIA bus, on which CompactFlash is based, has three address >spaces;
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.
>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 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.
>>> 5) Multiple sector writes >> >> 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? > >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).
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 by Tim Clacy September 16, 20042004-09-16
Markus Zingg wrote:
>> Should support: >> 4) CompactFlash IO through common memory (rather than IO window) > > 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.... !
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.
>> 5) Multiple sector writes > > 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?
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 by Tim Clacy September 16, 20042004-09-16
Not Really Me wrote:
> Tim Clacy wrote: >> 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 > > Check out uC/FS at www.micrium.com. I believe it does all you want.
Scott, That looks just the job; thanks. So far, I'm up to three: 1) EBSnet - ERTFS 2) Micrium - &#4294967295;C/FS 3) SanDisk - Host Developer's Kit