[Tfug] Media cards

[Bexley Hall]

Hi, John,

--- On Mon, 1/5/09, John Gruenenfelder <johng at as.arizona.edu> wrote:

> 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.

Ah!  And, no doubt, *size* as well!  (though I suspect *money*
was *not*  :> )

> 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.

Yes ------------------^^^^^^^^^^^^

> The I2C sequence was enough to give it power, read/write data,
> and power off.  The

Since FRAM is totally nonvolatile, you are able to get by
with a "zero" power budget.  And, presumably, your accesses
to it were very structured -- i.e., you didn't just read or
write it willy-nilly; rather, you read/wrote as much stuff 
as you needed in one "batch" so you didn't have to keep
cycling power "one byte at a time"

> 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 

Do you mean "NAND flash"?

> 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.

Yes.  It acted as your "boot ROM".

[aside:  I onced designed a system where the bootstrap
was "fetched" over an EIA232 port.  :>  Just a hack I
implemented to make the development cycle more flexible...]

> 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.

I.e., wait-stated?

> 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.

Understood.

> I would guess that CF should get you the best performance
> while SD/SDHC should get you the lowest cost.

Assuming the power analysis supports this approach, the other
big concern I have with XIP is handling the removal of the
device *while* code is executing out of it!  E.g., if I
go the SD/SM/MS/etc. route (i.e., something with which I
can't directly XIP), then fetching "stuff" from the device
has to be done programmatically.  So, as part of that process,
I can examine the data and check its integrity *before*
letting the processor chew on it.  So, if the medium is
removed *while* I am accessing it, I have a greater chance
of detecting this and *not* letting the processor go south...

> And if your processor isn't that fast, then you
> probably don't need CF or SDHC and can go with the
> slower SD.

--don