Lo Ae wrote:
> Where should i change things to improve the writespeed? Is it actually
> possible to write faster?

That may be as fast as the card will permit. I am using a commercial
filesystem and have seen cards perform as badly as 32 Kb/s! The best
cards I have found achieve around 700Kb/s Segger (the vendor) publish
data indicating a maximum of around 1Mb/s. 300Kb/s sounds about average.

Chan's own benchmarks (http://elm-chan.org/fsw/ff/img/rwtest.png) show
results comparable with yours.

Note also that if the driver uses SPI mode, it has a 1 bit wide data
path. If you have tested the card on say a PC it will be using SDIO,
which is a 4 bit path, and this may or may not increase performance - it
is likely that the data path is not the bottleneck however. Note that
you can use SD or MMC cards.

Why you might get errors for blocks larger than 512 bytes I don't know.
The API returns FR_RW_ERROR for a large number of reasons, but you have
the source so you should be able to determine where it is failing and
why.

Clifford Slocombe wrote:
> Note also that if the driver uses SPI mode, it has a 1 bit wide data
> path. If you have tested the card on say a PC it will be using SDIO,
> which is a 4 bit path, and this may or may not increase performance - it
> is likely that the data path is not the bottleneck however. Note that
> you can use SD or MMC cards.

But I use the 4bit modus. The modern digital cameras can also write up
to 15MB/s why can't I achieve even 1MB/s?
What do they different? (DSP, no FS, higher Frequency)

Lo Ae wrote:
> Hi,
>
> i downloaded the 'ChaN's FAT-Module and LPC23xx/24xx MCI' from
> http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/efsl_arm/index.html

First of all: this code is very experimental. So far I have not used an
LPC23xx/24xx in a real project the presented code is just a result of
some preliminary tests.

> but on a Extrem III SD-Card the Writespeed is only 300 KB/s.
There is a small txt-file in the archive with a log of one of my
test-sessions with some "write rates".

> I tried
> different things, i tried it with ChaN's FAT Module 0.06 and with the
> Tiny FAT Library but the write speed is almost the same.
I don't think the FAT-code itself will change much. I have just made
some code for an AT91SAM7SE512 and updated with current code from Chan.
I could not measure a significant difference but I also can not remember
the number of the old version.

> I write 10'000 times 512 Bytes from the External RAM onto the Card. If i
> try to write more than 512 Bytes i have FR_RW_ERRORs.
My disk_write implementation is far from being finished, also the
additional code for state changes might be wrong and maybe even not
needed. Search examples from IAR and Keil, they have publishded some
low-level MCI-code which you can port and combine with Chan's fat-module
(take care of the licenses).

> The MCIClk Speed is 18 MHz.
Do you use DMA? Is code setup-up correctly (MAM, FCLK?) For external RAM
maybe Wait-states. As you can see in the my write-routine there is a
block-copy in it. This is bad and eats performance.

> I use the EA LPC2468 Development Board.
>
> Where should i change things to improve the writespeed? Is it actually
> possible to write faster?
At least my tests showed faster rates (using LPC2368, older SanDisk
Card). It should be possible to increase the speed.

Clifford Slocombe wrote:
> Lo Ae wrote:
>> Where should i change things to improve the writespeed? Is it actually
>> possible to write faster?
>
> That may be as fast as the card will permit. I am using a commercial
> filesystem and have seen cards perform as badly as 32 Kb/s! The best
> cards I have found achieve around 700Kb/s Segger (the vendor) publish
> data indicating a maximum of around 1Mb/s. 300Kb/s sounds about average.
Very preliminary test with Extremmemory "Performace" 1GB SD-Card,
AT91SAM7SE@48MHz, SPI@24MHz, DMA/PDC, source from SDRAM:
18:09:55.785> (1) File-append test
18:09:55.785> (2) SDRAM test
18:09:55.785> (3) load content of file SDIMGI.BIN into SDRAM
18:09:55.785> (4) save complete SDRAM content to file SDIMGO.BIN
18:09:55.785> (5) Directory
18:09:55.785> (0) Show this again
18:10:01.726> Choice: 4
18:10:01.726> start 20000000 len 33554432 Bytes target /SDIMGO.BIN
18:10:21.172> all written
18:10:21.172> ram2file returned with 0

> Chan's own benchmarks (http://elm-chan.org/fsw/ff/img/rwtest.png) show
> results comparable with yours.
I think this picture is rather old modern SD-Cards might be faster. Also
take into account that the tests have been done with an AVR@9MHz so the
max. SPI-clock is ca. 4MHz. I exepect for fast cards this is not the
ideal controller to test maximum performace.

> Note also that if the driver uses SPI mode, it has a 1 bit wide data
> path. If you have tested the card on say a PC it will be using SDIO,
> which is a 4 bit path, and this may or may not increase performance - it
> is likely that the data path is not the bottleneck however. Note that
> you can use SD or MMC cards.
>
> Why you might get errors for blocks larger than 512 bytes I don't know.
> The API returns FR_RW_ERROR for a large number of reasons, but you have
> the source so you should be able to determine where it is failing and
> why.
Again. My code is very preliminary. I should not have published it but I
have not seen any other free code for FAT and MCI so a though it would
be at least a start for others.

Lo Ae wrote:
> Clifford Slocombe wrote:
>> Note also that if the driver uses SPI mode, it has a 1 bit wide data
>> path. If you have tested the card on say a PC it will be using SDIO,
>> which is a 4 bit path, and this may or may not increase performance - it
>> is likely that the data path is not the bottleneck however. Note that
>> you can use SD or MMC cards.
>
> But I use the 4bit modus. The modern digital cameras can also write up
> to 15MB/s why can't I achieve even 1MB/s?
> What do they different? (DSP, no FS, higher Frequency)
I expect "modern cameras" use the 4bit bus, the bus-frequency is limited
anyway. I doubt that the given speed can be achived with any card.

Lo Ae wrote:
> But I use the 4bit modus.
Really!?. The code you referenced use SPI.

> The modern digital cameras can also write up
> to 15MB/s why can't I achieve even 1MB/s?
> What do they different? (DSP, no FS, higher Frequency)
They can if provided with a fast card perhaps. Since you probably have
no way of testing that, you have only the manufacturers word for that in
any case. They will quote the maximum transfer rate the camera will
support, not the rate achievable in practice with any particular card.
Most often you will get somewhat lower performance. NAND Flash is
fundamentally slow. And they almost certainly use SDIO. The maximum
transfer rate in SPI is specified as 25Mbit/s (3.125 Mbyte/s) using a
25MHz maximum clock rate (ref:
http://en.wikipedia.org/wiki/MultiMediaCard).

See http://en.wikipedia.org/wiki/SD_card, and note that a 'basic' card
is typically rated at a maximum 0.9 Mb/s. Also the rates quoted are
'maximum', they may not be sustainable, they are almost certainly for a
clean formatted card with no file system fragmentation or bad blocks.

At 18MHz the 'wire' data rate maximum is 18M bits / sec (that 2.25M
bytes per second), then there is software overhead while bytes are
loaded into the SPI shift register, this may be significant since one
byte period is only 0.5 microseconds. Also an SD card may take between 0
and 8 byte periods to respond to individual command packets adding
further overhead(an MMC 1 to 8), then there is all the protocol and
handshaking between blocks, and accessing the file system (which
requires a number of block reads even when writing).

I would suggest that at 18MHz about 1Mb/s is about maximum for some
particular cards. Most manufacturers are very reluctant to indicate
speeds, since there are so many variables beyond their control, and in
the cheap commodity card market, they probably change their suppliers
based on cost not speed so they may vary even from the same 'labelled'
manufacturer. This is the price you pay for $10 4Gb cards I guess.

Also I suppose that it is possible that even a high speed card would not
perform well in SPI mode. Since SPI is typically only used on low-end
commercial devices because it is cheap to implement, and by hobbyists
for the same reason and because it is simple, then it may be that
manufacturers do not bother to optimise performance in that mode.

For Segger's emFile, they quote on theri site 1Mb/s write for MMC on a
AT91SAM7S running at 48 MHz for an MMC card using SPI at 24MHz. My
experience is that typically beyond 12MHz the card becomes the speed
determinant. Note that while that is what Segger quote, when I first
used it and got only 32Kb/s they sent me their complete test data, and
like the camera manufacturers they quited their best observed
performance, they had one card that worked at only 20Kb/s!

You can demonstrate that the performance is limited by the card and
nothing else by reducing the SPI clock speed. You will probably find
that you can clock it right down to below 6MHz before the transfer rate
is affected.

To measure the inter-byte gap caused by the overhead of reloading the
SPI shift register you will need to use an oscilloscope on the SPI line.


Clifford

thanks for your responses.

I implemented the Multiblock Transfermode (CMD25) and now i have a
datarate up to 3000 kB/s.

Lo Ae wrote:
> thanks for your responses.
>
> I implemented the Multiblock Transfermode (CMD25) and now i have a
> datarate up to 3000 kB/s.

That's impressive, and perhaps shows how poor the commercial code we are
using may be. Will you be making this code available to others by any
chance?

Clifford

Clifford Slocombe wrote:
> Lo Ae wrote:
>> thanks for your responses.
>>
>> I implemented the Multiblock Transfermode (CMD25) and now i have a
>> datarate up to 3000 kB/s.
>
> That's impressive, and perhaps shows how poor the commercial code we are
> using may be. Will you be making this code available to others by any
> chance?
>
> Clifford

The commercial Code is with SPI bus and i use as a mentioned before the
4bit modus. Its the code from mthomas with addition by me (CMD25).

In the zip-File are the three important files. I hope that is enough. No
warranty that its working stable.

Lo Ae wrote:
> Clifford Slocombe wrote:

>
> The commercial Code is with SPI bus and i use as a mentioned before the
> 4bit modus.
Sorry I was specifically referring to the code I am using from Segger.
To be fair to them it is only using SPI.

Thanks.

Clifford