CF Performance settings

Hi all,

Is anybody knows how to configure CompactFlash for best performance. What register ? May be FEATURE_REG in ATA's ?

My design reaches about 150Ko/s which is far from CF spec.

Thank you all, Habib.

Reply to
habib bouaziz-viallet
Loading thread data ...

Throughput is defined by many factors. Are you acessing it with 16 bit's or 8, is DMA used or not? The low level IO routines (transfering sector data) is written in assembly ? Just by writing the low level routines in assembly I once could increase the throughput by the factor of 5.. Ok, this very much dends on the quailty of the compiler in use but there it made a huge difference.

Memory mapped mode (wich btw. is quite a misleading term in the context of CF) can have an advantage if the host CPU you are using is supporting IO instructions or other kinds of fast external memory transfers. In this mode, the CF simply ignores the address lines during data transfer hence block move operations that the CPU may supports can be used where as otherwise you must feed every single byte (or word in 16 bit mode) through the date register. If your CPU does not support memory block move operations there is not much advantage (performance wise) in useing memory mapped mode over true IDE or IO mode.

HTH

Markus

Reply to
Markus Zingg

Le Fri, 18 Feb 2005 22:59:57 +0100, Markus Zingg a écrit :

Hi Markus,

Hardware : Atmega64 driving CF ATA_media with no DMA, no IT, so CF is driven in memory mapped mode. All transferts CF AVR are 8 bits width.

In order to increase Read/Write perfs, trying to deal with asm provided by gcc is on the go. But i read that CF ATAmedia enters Sleep mode after a programmable delay if no activity. How to configure that delays (Sleep to Write, Sleep to Read) after carrefully reading Sandisk and ATA_CF specs no further infos is clearly done. Have you ever dealing with ?

Many thanks, Habib

Reply to
habib bouaziz-viallet

I don't know the ATmegas good enough to know if they support memory block move operation on asm level. If so, then this is the way to go since it will be the best you can do to transfer sector data.

IMHO the sleep mode is completely transparent and out of my experience can't really be the reason for the low transferrate you experience. I'm of course asuming you are not waiting seconds between individual sector transfers :-) Just implement the low level code in assembly (again, using the a10 pin high feature i.e. blocktransfer) and I'm very sure you will achive the maximum trhoughput possible with your controller. The CF by itself (unless it's a really old one) should be much faster than what your ATmega can move around.

I haven't used this feature, but so far I found the CF specs to be well written. You may have to read it a couple of times though.

Markus

Reply to
Markus Zingg

Le Sat, 19 Feb 2005 14:26:04 +0100, Markus Zingg a écrit :

After re-implement Read and Write sectors functions (mostly in asm), speed-rate is now about 230 Ko/s with ATmega running at 7,37MHz. Yet another proof that hand-coding assembly is sometimes far better than anyother compiler, even gcc. PS : Sleep to read/write delays may be configured through IDLE command (Cf. CF datasheet)

Thank you, Habib

Reply to
habib bouaziz-viallet

Habib,

Hi. It's all about how fast you can transfer blocks of bytes between your CPU and the CF device. There are ATA commands that enable write buffering and multi-sector transfer modes, but I wouldn't worry about those for now. Just concentrate on writing a highly optimised function for transfering a block of 512 bytes (one sector) between the CPU and the CF device; this is where most of the performance gain will come from. Move as much data from memory into the CPU registers as you can, then transfer those as fast as you can and repeat this in as tight a loop as possible. Of course, you shouldn't transfer faster than the card can handle; there is a field in the CIS (Card Information Structure) that reports the supported speed. However, you're unlikely to get close to the imit of the card with your CPU.

Tim

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.