Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Subject: Re: MMC/SD support on LPC2000

2006-01-17 by Steve Franks

Message: 19
  Date: Tue, 17 Jan 2006 21:27:41 -0000
  From: Carsten Grøn <cgroen@...>
Subject: Re: MMC/SD support on LPC2000

Sean,
the reason (for me) would be that it would be simpler on the LPC
board, no need for FAT etc (I'm actually also looking into prllc's FAT
implementation with SD support at $139,- which I think is very
reasonable). Also I'm a little worried that the card will be "killed"
by problems with write-endurance (if using FAT, the FAT tables are
written very often), and if used as a circular buffer, each sector
will be written (relatively) seldom.

Regards,
Carsten

Guess I'll add my $0.02:

I'm doing the same approx thing with some ADC's.  When you fire up the LPC,
if basically formats the card, so no one on the windows end can pre-muck it
up.  It writes a FAT which makes the rest of the card one big file, so it
can later be read by windows.  Then we overwrite the sectors in that file
willy-nilly as we see fit.  The only drawback is that if you put a 1GB card
in a USB 1.0 reader, prepare to wait.  Of course, fast ADC's fill up 1GB in
a hurry, so you usually want to copy most of that 1GB of data anyways, the
unused space doesn't add much overhead, except in testing/debug, for which a
complicated setup like dd on windows is acceptable, since the end-users
don't have to do it.

FYI: the prllc implementation doesn't play very nice with GCC, and has lots
of AVR-specific hardware code in it, although it is definately evolving
nicely to thier credit.  As people have mentioned, there is Tom's
implementation, and the efsl project as alternatives more plug-n-play to GCC
& LPC.

Steve


[Non-text portions of this message have been removed]

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.