Interleaved Read/Write to Compact Flash Card
in [Embedded]
|
Prev: What is Bit Spread?
Next: DAS recomendataion
From: Guy Eschemann on 16 Apr 2010 17:05 That's why CF cards don't specify minimum write speeds, right? What about SDHC cards? Do they exhibit similar random delays? If not, is there any technology (be it a harddisk drive) that will allow me to write these 10 GB of data without unpredictable interruptions? Many thanks, Guy. On Apr 16, 10:48 pm, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote: > Guy Eschemann wrote: > > Vladimir, > > > I forgot an important piece of information: there is no file system. > > I'm writing the card in "raw" mode using an FPGA. I'm writing only the > > data bytes, starting at sector 0, until the 10 GB file is complete. > > There is nothing else on the card. > > You can expect a huge delay (~100ms) at the very beginning of the > process, and random delays (~10..100ms) while in the operation. This is > a typical behavior of CF card. Although the average sustained transfer > rate can be 20-30MB/s or even higher. > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com
From: hamilton on 16 Apr 2010 17:36 On 4/16/2010 3:05 PM, Guy Eschemann wrote: > That's why CF cards don't specify minimum write speeds, right? > What about SDHC cards? Do they exhibit similar random delays? > If not, is there any technology (be it a harddisk drive) that will > allow me to write these 10 GB of data without unpredictable > interruptions? Even a harddrive will recal the heads every so often. If your using an FPGA, why not use a RAM stick ? You said you are not using a file system, so Windows/Linux compatibility is not an issue. ( How did you intend to get that data out of the CF card ? ) RAM would be cheaper anyway. Why add the overhead ? hamilton
From: Didi on 16 Apr 2010 18:27 On Apr 17, 12:05 am, Guy Eschemann <guy.eschem...(a)gmail.com> wrote: > That's why CF cards don't specify minimum write speeds, right? > What about SDHC cards? Do they exhibit similar random delays? > If not, is there any technology (be it a harddisk drive) that will > allow me to write these 10 GB of data without unpredictable > interruptions? On a hard drive with some luck, yes. If you verify the areas you will write to in advance to be fast writable (i.e. continuous, the drive has not reassigned any sectors) you can be pretty sure things will work for some time. But you will not know when you will run out of luck, of course... For 100% uninterrupted write I vaguely remember a discussion on the T13 reflector perhaps 10 years ago when some new "streaming" features were being introduced or were about to be introduced. I have never needed them so I don't know what happened and if they are any good for your purpose (I believe they were just error tolerant, drive would not bother retrying a write if it failed) since my memories on that are very vague, but it may be worth a glance, probably they are in the ATA standards. But as Vladimir suggested, just buffering for 100+ mS and using normal command sets may be the simplest and sanest way to go. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/7d791631385a4cbf?dmode=source
From: Guy Eschemann on 17 Apr 2010 03:41 Hamilton, the system is connected to a PC via a gigabit ethernet interface. Ideally, the data will be transmitted in real-time to the PC and logged to the card for backup. In case something goes wrong with the network or the PC during the data acquisition, the data (which can be worth tens of thousands of dollars) will still be readable from the card (via ethernet) after the acquisition has completed. As you said, I could also use a few DIMM modules to store the whole file, but flash gives me additional immunity against power interruptions. Also, since this is for an embedded application that will be built for the next 10 years, I'm looking for solutions that will be available a bit longer than the few years these DIMM modules typically have. Thanks, Guy. On Apr 16, 11:36 pm, hamilton <hamil...(a)nothere.com> wrote: > On 4/16/2010 3:05 PM, Guy Eschemann wrote: > > > That's why CF cards don't specify minimum write speeds, right? > > What about SDHC cards? Do they exhibit similar random delays? > > If not, is there any technology (be it a harddisk drive) that will > > allow me to write these 10 GB of data without unpredictable > > interruptions? > > Even a harddrive will recal the heads every so often. > > If your using an FPGA, why not use a RAM stick ? > > You said you are not using a file system, so Windows/Linux compatibility > is not an issue. > > ( How did you intend to get that data out of the CF card ? ) > > RAM would be cheaper anyway. > > Why add the overhead ? > > hamilton
From: Guy Eschemann on 17 Apr 2010 07:02
Are these random delays of up to 100 ms specified somewhere? To design a large-enough buffer, I need to know at least the maximum duration of these pauses, and the minimum interval between two consecutive pauses. Cheers, Guy On Apr 17, 12:27 am, Didi <d...(a)tgi-sci.com> wrote: > On Apr 17, 12:05 am, Guy Eschemann <guy.eschem...(a)gmail.com> wrote: > > > That's why CF cards don't specify minimum write speeds, right? > > What about SDHC cards? Do they exhibit similar random delays? > > If not, is there any technology (be it a harddisk drive) that will > > allow me to write these 10 GB of data without unpredictable > > interruptions? > > On a hard drive with some luck, yes. If you verify the areas you > will write to in advance to be fast writable (i.e. continuous, the > drive has not reassigned any sectors) you can be pretty sure > things will work for some time. But you will not know when > you will run out of luck, of course... > > For 100% uninterrupted write I vaguely remember a discussion on > the T13 reflector perhaps 10 years ago when some new "streaming" > features were being introduced or were about to be introduced. > I have never needed them so I don't know what happened and if they > are any good for your purpose (I believe they were just error > tolerant, > drive would not bother retrying a write if it failed) since my > memories on that are very vague, but it may be worth a glance, > probably they are in the ATA standards. > > But as Vladimir suggested, just buffering for 100+ mS and using > normal command sets may be the simplest and sanest way to go. > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ > > Original message:http://groups.google.com/group/comp.arch.embedded/msg/7d791631385a4cb... |