Lpc2000

seangra wrote:

> SPI mode *maximum* (for either SD or MMC) has 125KB/sec/MHz, so at
> 7.5MHz your theoretical max is only 930KB/sec.

So this means theoretical minimum time == 0.137 seconds for 128 kBytes.
This is no where near the measures 13 to 14 seconds (factor 100). If 
these figures were fairly equal (e.g. factor 2~3) I would agree.

And SD or SPI mode makes no difference in read/write speed (not al long 
as we're still 100 times slower than the abs. maximum)

> I'm not sure of how accurate the speeds reported for the cards are,
> but this may be like how my HD has a "max speed of 60MB/sec! {small
> text: burst mode from cache}", and even though it's on a bus that
> has 100MB/sec max, I only see 30MB/sec on average.

I do not believe these values anymore. Sandisk specifies for their 
Extreme III cards (see 
http://www.sandisk.com/Products/Catalog(1049)-SanDisk_Extreme_III_SD_Cards.aspx):

    * Min 20MB/second** sequential read and write
(The note on that same page states that 1 MB = 1 megabyte  = 1 million 
bytes)

This would mean 20 * 8 == 160 Mbits/second and that gives a 80 MHz clock.
That same Sandisk company also states that the max. SD clock == 25 MHz.

I have a Sandisk Ultra II card (10 MB/s read, 9 MB/s write) - still 
gives a 40 MHz clock.
I tried this card on the LPC3000 with different SD clocks (20, 26, 34 
and 52 MHz - these are easy to reach clocks ...). Can still read at 52 
MHz but not write anymore and do defenitely not reach the max. that 
Sandisk states.

> Would you be able to run another test, however perhaps with the
> following modifications?


> b) use a timer algorithm in the LPC2148 to time
> - 1) the amount of time spent waiting per call to the chip
> - 2) the total amount of time the read/write operation took. 

As Bertrik states he does not (yet) know how to do this.
I wrote a fairly simple web page on how to do this: 
http://www.myvoice.nl/electronics/timing-programs.php
Did many of these tests before and can do this for Bertrik's code also 
(Bertrik, if you post your code or drop me an e-mail I can help you out 
on this one).

> c) see if there are any simple optimizations that can be done to the
> code, or post it here and see if anyone has any ideas on how to make
> it more efficient.

Optimizations ...
I was a bit confused (maybe still not fully awake) but it reads 
kilobytes, not megabytes in Bertrik's mail. With 10 kilobytes per 
seconds I am not talking about optimizations anymore.
This is more like a structural design problem ...

Tom's version of RDCF2 has 100 kBytes / second (512K file in 5 seconds)  
and slowest card measures 19 kBytes/second (512K file in 27 seconds).
Still I think this is slow compared to what I would expect.

Rob