[Tfug] Media cards

Bexley Hall bexley401 at yahoo.com
Sun Jan 4 13:02:20 MST 2009


Hi, Tom,

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

> > There seem to be more d*mn media card standards than there
> > are media card manufacturers!
> > 
> > SD, SDHC, CF, MS, SM, each of the preceding with "high speed"
> > option, etc.  (yes, there are several others, as well :<  )
> > 
> > I'm trying to figure out which to use in a new design.
> > I think all except CF are intended as "secondary storage"
> > as they all have serial interfaces.  I.e., you can't do XIP
> > using them (well, not unless you keep faulting in pages!)
> > 
> > But, CF is big, bulky, more prone to damage, etc.
> > 
> > Any thoughts on this?
> 
> All of the removable ones are designed for, well, being
> swapped in and

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

> out.  If you want primary the question is, will the data be

<frown>  Perhaps something ^^^^ missing here?  :-/

> modified a lot or not?  The big big flash chips (the name of 

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

> which escape me) have a smaller number of writes before you 
> start seeing bad blocks.

You can use wear-leveling techniques to help alleviate that.

> But the filesystems for them are designed with this in mind.
> For not-so-big, regular old NAND is probably your best bet.

Thanks!
--don


      




More information about the tfug mailing list