[Tfug] Media cards

[John Gruenenfelder]

On Sun, Jan 04, 2009 at 02:12:50PM -0800, Bexley Hall wrote:
>Price is an issue; but, more important is battery life.
>I'm targeting 10-12+ hours on a single battery charge
>(and that would only be "acceptable" performance  :<  )
>So, anything that uses power is subject to scrutiny.
>
>So far, my best approach is something like an SD or SM card
>(avoid MS as it has features -- and "taxes" -- that are
>not necessary) and do some smart paging so I can power the
>card down between accesses without taking a big performance
>hit (e.g., arrange for context switching to occur coincident
>with the need to fault a new set of pages *in* -- and hide
>the power_up-page_in-power_down sequence behind the context
>switch so it doesn't "cost as much"  :-/  )  Of course, this
>is a lot more complexity that I'd prefer to just avoid with
>an architecture that eliminates the need for "secondary
>storage"...

Both times I've worked on this stuff at this level, the devices were bound for
space so power efficiency was a big concern.

The first was a tiny control board for a small satellite (Cubesat).  We used
an FRAM (ferromagnetic RAM) chip connected over an I2C bus.  The FRAM was
picked, I believe, because of low power usage and radiation resistance.  The
I2C sequence was enough to give it power, read/write data, and power off.  The
downside is that it was really slow (but then the whole board was pretty
slow).

The other was a camera/navigation board.  There we used some basic NAND chips
and talked to them from the ARM CPU via an FPGA controller.  Low power was
still key, but this setup was considerably faster.  Now, the board was custom
and the chips were stuck right to it.  If cost had been a larger concern, it
would not have been a major issue to remove the chips and replace them with
something like an SD card/reader.  Some changes to the wiring and the FPGA
control logic.

In the latter case we did XIP only for the first part of the bootloader.
After that, parts were copied into RAM and executed there for increased
speed.  But that all depends on application.  If we didn't need the additional
speed, we could have executed most of the code from flash, but then the ARM
CPU would have been idle a lot.

This CPU, an ARM7TDMI, had no MMU and no cache, and the code I wrote had no
need for multitasking, so I never needed to worry about hiding the cost of
flash access.  In general, flash access was only needed, after boot, for
saving new code or permanent data, so the access time was just lumped into the
"cost" of those operations which needed flash.

I would guess that CF should get you the best performance while SD/SDHC should
get you the lowest cost.  And if your processor isn't that fast, then you
probably don't need CF or SDHC and can go with the slower SD.


-- 
--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for PalmOS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max