Lpc2000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

seangra wrote:
> --- In lpc2000@yahoogroups.com, Bertrik Sikken <bertrik@z...> wrote:
> 
>> I did some experiments to get a feel for the write speed.
>>
>> I measured the time it took to read and write 4MB of contiguous
>> raw data directly onto the disk (without a file system). Writing
>> was done both with the WRITE_BLOCK command and the
>> WRITE_MULTIPLE_BLOCK.  The WRITE_MULTIPLE_BLOCK command was
>> configured to write 256 sectors of 512 bytes (128 kB). I measured
>> the time by looking at my wristwatch.  My hardware is a LPC2148
>> quickstart board from embedded artists, configured to run at 60
>> MHz PCLK and 7.5 MHz SPI clock (highest possible for SPI0).
> 
> Thanks for the test, this is good information.  However
> unfortunately I don't think that this is an accurate representation
> of the speed of the card itself.  Keep in mind that you have several
> limiting factors:
> - 7.5MHz SPI clock (max is 25MHz, so you're 1/3rd the throughput
> there), I haven't worked with this chip yet, but why is the max
> speed 7.5MHz?

I'm using the SPI0 peripheral. The clock speed of this peripheral
is the PCLK (60 MHz) divided by some divider which has a minimum
value of 8.

> - Using SPI mode instead of SD mode.

I think SD modes are too complicated and even less documentation
is available for them than for SPI mode.

> - Optimization and organization of code

The basic loop for running the test is really simple.
The processor spends most of its time waiting for the card to
respond. I don't think that optimisation will help a lot.

> SPI mode *maximum* (for either SD or MMC) has 125KB/sec/MHz, so at
> 7.5MHz your theoretical max is only 930KB/sec.
> 
> 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'm also not sure if this is true, but it may also be that since
> your card is 1.5MB/sec (I assume in SPI mode and not SD 4-bit mode)
> then your card speed may be only 60KB/sec/Mhz (if it is SD) or
> 75KB/sec/MHz (if it is MMC).  This translates to 450KB/sec or
> 560KB/sec for SD/MMC respectively.
> 
> You're seeing about 320KB/sec. I'd guess that the code that you are
> using is not optimized (?), so it's not surprising that you're
> getting only 30% or 60% of the max speed.
> 
> Would you be able to run another test, however perhaps with the
> following modifications?
> 
> a) figure out if I'm right about the speed limit, try to benchmark
> the card speed on your computer with a USB2.0 card reader (if you
> have one).

I did that test, the speed with an USB2.0 card reader on a USB2.0
card is disappointing too. The card reader has a NEODIO ND3260 chip.
It took windows XP about 55 secs to copy 36 MB worth of music files,
i.e. 650 about kB/s. I think my SD card is just slow.

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

I don't know how to do this yet.
My aim was to just get a rough idea about the speed.

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

My code is based on the stable version of the efsl library (v0.2.5)
In my test, I wasn't even using any filesystem, just writing dummy
data at contiguous sector addresses.

> It would be interesting to see what those tests show.
> 
>> My results are:
>>
>> read 13s; write single 14s; write multiple 13s
>>
>> I find it surprising that the write speed is not significantly
>> slower than the read speed.
> 
> Keep in mind the speed that you're operating at vs the maximum
> speed.  Let's say that on your card (at 7.5MHz) the write operation
> can occur at 400KB/sec, and the read operation at 800KB/sec. 
> Because your throughput is only 320KB/sec they will both appear to
> take the same amount of time.

Ok, let me think about that.

Bertrik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDiQcEETD6mlrWxPURAm0SAJ0auVhi8nv9R8FBFXjWPuBOnv/MogCcCOcg
xxdGnFbm5LrePxKQqPFN3h4=
=+aUB
-----END PGP SIGNATURE-----