[Tfug] Media cards

[Bexley Hall]

Hi, Tom,

--- On Sun, 1/4/09, Tom Rini <trini at kernel.crashing.org> wrote:

> > Yes.  And, for most applications (besides PDAs), I suspect
> > data crosses the interface very infrequently (e.g., in a
> > camera, you push the images into the card and they pretty
> > much sit there; in an MP3 player, you pull them off the
> > card as you are playing, etc.).
> 
> Well, in a camera, each new snap is a set of writes.  In a
> nav system, you've got infrequent write data (maps) and more
> frequent write data ("home", frequent places, etc, etc).  In a
> MID/NetBook, it depends on how often media gets swapped out.

Yes.  But, you can decide "where" you want to store each of
these data.  E.g., you can opt to store "Favorites" and
configuration information in BBSRAM or an internal flash, etc.
(i.e., doesn't have to be stored on the same medium as the
"maps", e.g.)

> > I don't want to have "redundant" components in the design.
> > E.g., in a PDA, you load applications off the card into
> > "RAM" where you can execute them "at CPU speed".  Or, you
> > have to run an interpreter/VM in the application such that
> > the slower "data stream" from the card is still fast enough
> > to implement the application.
> > 
> > The problem with "loading" an application in either of these
> > ways is it means something *else* limits the practical size
> > of your application (e.g., the RAM in the device).
> > 
> > I'd prefer an XIP approach -- if an application grows, just
> > use a bigger card to store the application (i.e., the application
> > implicitly carries its baggage with it).
> 
> Well, it really really depends on what the device
> you're designing is actually going to be doing, what 
> the price point is, and so on.  The

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

> devel boards we work with have a lot of choices for where
> various forms of storage can be attached and size/formfactor.
> The end devices we work on usually have two or three, 
> depending on what's really going on and
> what the end user is allowed to do.  Two common (NAND for
> on-board, some form of SD for cards and often there's host 
> mode USB for that too.  Of

Understood.

> course we're pretty much a Linux-only shop and usually
> XIP for the apps
> has been considered and then decided against as it's
> easy enough to get enough RAM and still be within the 
> price point.

You no doubt aren't fighting the power/size issues  :-(

Thanks!
--don