Prev: pseudo random number between X and Y?
Next: NIOS and ftoa()
From: SweetCraspy on 17 Nov 2009 11:16
As mentioned here:

http://www.embeddedrelated.com/usenet/embedded/show/112275-1.php

I'm working on converting a hard-drive-based datalogger to work with
compact flash.

I'm using the flash cards as if they were IDE drives receiving PIO
transfers. The general flow of the logger's operation is:

Fill buffer to 3/4 (to leave room to log while flushing)
Turn on and initialize CF card
Perform a series of WRITE SECTOR transfers
Shut down CF card
Update buffer status
Repeat

My issue has been the number of sectors I can transfer with each WRITE
SECTOR command. The original hard drive configuration of the logger could
transfer 128 sectors at a time with out any trouble.

My attempts to match this (to minimize command processing overhead) have
failed in the same manner with three different vendors and two speed grades
of CF. Lexar 300x, and Transcend and Kingston 133x cards are all capable
of transfers up to 32 sectors-per-operation and will fail on me if I try 64
sectors-per-operation. Furthermore, to get any size to work, the
operation's starting sector must be a multiple of this value.

(i.e. a 16 sector-per-operation setup will work fine if the system starts
writing at sector # 15 or 31 or 47, counting from 0. It will fail if
writing starts at sector #s 16-30.)

The symptom of the failure that I see in the attempted recordings is
skipped data points. It seems that the CF card is missing a few of the IDE
Data Register writes in these failure cases. The card expects more data
while the logger thinks that it has finished transmitting and the system
hangs until it times out.

I suspect that this might have to do with the extra processing that the
flash does to erase sectors before writes and to wear-level the card, but
I'm not sure if this is a hard limit on the card's performance. Attempts
to play with the CFA ERASE SECTORS and CFA WRITE SECTORS WITHOUT ERASE
commands did not yield fruit.

Does anyone have any insight into why these CF cards do not behave like a
hard drive when they receive large WRITE SECTOR commands?

Thanks much!

---------------------------------------
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com
From: Vladimir Vassilevsky on 17 Nov 2009 11:34


SweetCraspy wrote:

> As mentioned here:
>
> http://www.embeddedrelated.com/usenet/embedded/show/112275-1.php
>
> I'm working on converting a hard-drive-based datalogger to work with
> compact flash.
>
> I'm using the flash cards as if they were IDE drives receiving PIO
> transfers. The general flow of the logger's operation is:
>
> Fill buffer to 3/4 (to leave room to log while flushing)
> Turn on and initialize CF card
> Perform a series of WRITE SECTOR transfers
> Shut down CF card
> Update buffer status
> Repeat
>
> My issue has been the number of sectors I can transfer with each WRITE
> SECTOR command. The original hard drive configuration of the logger could
> transfer 128 sectors at a time with out any trouble.
>
> My attempts to match this (to minimize command processing overhead) have
> failed in the same manner with three different vendors and two speed grades
> of CF. Lexar 300x, and Transcend and Kingston 133x cards are all capable
> of transfers up to 32 sectors-per-operation and will fail on me if I try 64
> sectors-per-operation. Furthermore, to get any size to work, the
> operation's starting sector must be a multiple of this value.
>
> (i.e. a 16 sector-per-operation setup will work fine if the system starts
> writing at sector # 15 or 31 or 47, counting from 0. It will fail if
> writing starts at sector #s 16-30.)
>
> The symptom of the failure that I see in the attempted recordings is
> skipped data points. It seems that the CF card is missing a few of the IDE
> Data Register writes in these failure cases. The card expects more data
> while the logger thinks that it has finished transmitting and the system
> hangs until it times out.
>
> I suspect that this might have to do with the extra processing that the
> flash does to erase sectors before writes and to wear-level the card, but
> I'm not sure if this is a hard limit on the card's performance. Attempts
> to play with the CFA ERASE SECTORS and CFA WRITE SECTORS WITHOUT ERASE
> commands did not yield fruit.
>
> Does anyone have any insight into why these CF cards do not behave like a
> hard drive when they receive large WRITE SECTOR commands?

Do you use "write sectors" or "write multiple" command? Not too many
cards support for "write multiple". You have to check if "write
multiple" is supported and how many sectors is allowed per operation.

I have no problem writing up to 256 sectors regardless of alignment with
different CF brands; I am using PIO mode with interrupt driven operation
and "write sectors" command. Only once I had a problem with CF card
which generated interrupts incorrectly, but that was a different story.



Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com









From: SweetCraspy on 17 Nov 2009 12:02
>Do you use "write sectors" or "write multiple" command? Not too many
>cards support for "write multiple". You have to check if "write
>multiple" is supported and how many sectors is allowed per operation.
>
>I have no problem writing up to 256 sectors regardless of alignment with
>different CF brands; I am using PIO mode with interrupt driven operation
>and "write sectors" command. Only once I had a problem with CF card
>which generated interrupts incorrectly, but that was a different story.
>
>
>
>Vladimir Vassilevsky
>DSP and Mixed Signal Design Consultant
>http://www.abvolt.com

Thanks for the quick response! I'm definitely using WRITE SECTORS. I
looked into WRITE MULTIPLE and was actually got it working with one of my
cards, but it only supported a block size of 1 in the first place so there
was no savings in overhead, I think.

In any event, it good to know that what I want to do is possible. One
thing that this system does not use is the IDE interrupts, so I'll look
into that for a more handshake based based protocol, rather than each
system just assuming that the other is keeping up.

---------------------------------------
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com
 | 
Pages: 1
Prev: pseudo random number between X and Y?
Next: NIOS and ftoa()