Lpc2000

Bertrik Sikken wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>donhamilton2002 wrote:
>  
>
>>I will leave the discussion about the legalities alone.
>>
>>I would like to know, those whom have used this code.
>>
>>What is the speed of writing a file to the media?
>>
>>Whether using an AVR or an ARM chip.
>>
>>Just how fast can I (we) write to the media?
>>
>>There is a lot of code here to run through, latency is my interest.
>>    
>>
>
>I'm wondering about this too.
>
>Tom, do you have a general idea about how long the card
>responds with a busy condition after issuing the WRITE_BLOCK
>command?
>  
>
No, it is not a consideration.  I am doing a commercial product and the 
processor running the SD/MMC drive has few time critical constraints, so 
a write could take 1ms or 1 second and it wouldn't affect me that much 
at all.

I'm happy that I finally have file streams working with an MMC drive for 
my project!

>And have you tried the WRITE_MULTIPLE_BLOCK command?
>- From what I've read in some of the sandisk documents,
>their flash products internally use blocks much larger
>than a single 512-byte sector, so using the WRITE_MULTIPLE_BLOCK
>command may help to write more efficiently (faster, smoothly) and
>probably also reduce wear of the flash medium.
>
>  
>
The program is not structure for Multiple Sector operations.  However, 
using Multiple Sectors is problematic at best.  To effectively write 
data in chunks larger than 512bytes, you would have to configure the 
BLOCK_SIZE (CMD51) so that both reads and writes would use the larger 
block.  This becomes a huge problem of now that you have to deblock down 
to a smaller size to utilize 512byte sectors within the RDCF2.

Doing Multiple Writes of a BLOCK_SIZE of 512bytes gains you nothing.  
Each BLOCK_SIZE of data is treated by the SD/MMC as a unit which must be 
programmed, regardless of the physical blocking on the device.

Why not take the RDCF2 code and try some of this out?

>I'm looking into this for my hobby project, a digital bat
>detector. It records ultrasonic bat audio at around 250 kS/s
>and writes it directly onto a flash disk. This recording can
>then be slowed by 16 times to make it audible to humans or be
>read in on a PC for frequency analysis.
>Since the data is coming in at a steady rate and there's not a lot
>of RAM to buffer incoming samples, I think I have to be careful
>to avoid delays when writing to the flash.
>  
>
So, treat the MMC device as a block mapped device rather than a file 
structured device.  You won't have a filesystem on it, but you'll have 
your data.   You can use dd to extract your data.  If you are are under 
cygwin the dd command should be there.  Under windows itself you would 
have to write some software to do what un*x gives you for free.

>I expect to receive the hardware (LPC2148) this week, so I hope
>I can help to answer some of these questions myself in a few weeks.
>
>  
>
-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------