MMC timings and write speed

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all!
I'm just beginning a new project which involves a PIC microcontroller
and a MultiMedia Card.

I was wondering which are the timings for these cards for a sustained
write. I need to store a data stream at 150KBytes/sec on the card, but I
can't figure out what the minimum write speed are for such MMCs and if
such a bandwidth is compatible with these cards.


I found some values, but often they happen to be:
- timings for communicating with the interface controller of MMC
- average speeds (nor minimum, nor maximum)
- burst transfer speed (which, I suppose, can't be sustained)

Well, thanks in advance, any comment, idea or suggestion would be
greatly appreciated,
Aldo

Re: MMC timings and write speed

Quoted text here. Click to load it

Hey

The speed can be different from manufactor to manufactor, but i think i can
remember there is a register you can read out to check this...

at the moment i am running one with 12.5Mhz SPI clock which gives
approximately 1.2 Mbyte.. so 200kByte will proberly not be any problem

i can recoment microsyl.com for some nice C code for mmc

Kasper



Re: MMC timings and write speed
Thanks Kasper!

Quoted text here. Click to load it

Do you mean the field R2W_FACTOR in the CSD register that you multiply
by the read access time (that is calculated with other parameters of the
  CSD)? I agree with you, but no manufacturer publishes this values :-(

Any idea on how to extract these values from a MMC card? Or whether
Windows or Linux software could do that?




Quoted text here. Click to load it

So, you use it in SPI mode, and get a write transfer speed of
1.2MByte/sec? Sounds good....
But do you perform continuous writes or just "burst" writes?

AFAIK, MMC have a buffer memory, and if you write data just some every
now and then, data gets buffered and then the MMC on-card controller
will download it to the flash memory in background, but if you fill the
buffer you just have to wait for the flash programming time.


Quoted text here. Click to load it

Nice site, thanks.

Aldo

Re: MMC timings and write speed
Quoted text here. Click to load it

have not done this, i usd trial and error...

Quoted text here. Click to load it

Hey.. that is in the theory....

my HC12 uC can not handle 1.2Mbyte :(  but u have had speed at arroud
100kbyte in continuous data.... long from the 1Mbyte by tthink my 25Mhz uC
with lan sets the limit

Kasper



Re: MMC timings and write speed
Hello Aldo

It is quite difficult -if not impossible- to get information about the
real -sustained- writting performance of a MMC or SD card.
I think that it is basically impossible just because you are talking to
a front processor and not directly to the flash. NAND flash used in
this kind of card is not 100% reliable and needs error correction or
even sector replacement. In my opinion, this can take -huge- time
(some 100ms worst-case) to have the datasector (512Bytes) really
written in, it if a defect is present. I have doubt that a PIC can have
enough memory to temporary store the bit stream in its ram if this
happens.
Also keep in mind that if you have a file system you will probably
have to divide the published speed by a factor 2 (writing data + table)
The sad think is that you can not test one card manufacturer and assume
the performance will remain the same over year, just because they
just contineously improve their process to remain price competitive.
If you want an idea of what is possible just buy a USB2 commercial
SD/MMC reader and copy a huge file to it and measure the time it takes.
Also having some guarantee of data retention (over years) seems
almost impossible... If someone knows about a manufacturer that
gives that kind of guarantee let me know.
To have an idea of possible performance you can check that datasheet:
http://www.kingmaxdigi.com/product/MMC.pdf

I hope it helps

Haldo wrote:

Quoted text here. Click to load it


Re: MMC timings and write speed


 > It is quite difficult -if not impossible- to get information about the
 > real -sustained- writting performance of a MMC or SD card.
 > I think that it is basically impossible just because you are talking to
 > a front processor and not directly to the flash. NAND flash used in
 > this kind of card is not 100% reliable and needs error correction or
 > even sector replacement. In my opinion, this can take -huge- time
 > (some 100ms worst-case) to have the datasector (512Bytes) really
 > written in, it if a defect is present. I have doubt that a PIC can have
 > enough memory to temporary store the bit stream in its ram if this
 > happens.

Yes, That's what I found out. Seems also that the frontend "virtually"
remap sectors when bad ones are found.
But I have no idea of the best case.

I was thinking of migrating to CompactFlash, they seem faster, although
they need more pins. What about this?



 > Also having some guarantee of data retention (over years) seems
 > almost impossible... If someone knows about a manufacturer that
 > gives that kind of guarantee let me know.
 > To have an idea of possible performance you can check that datasheet:
 > http://www.kingmaxdigi.com/product/MMC.pdf


Yes, very helpful. It states something about transfer rates, sequential
and random read and write. Random writes at about 800KB/sec, sounds good
(*but it doesn't say if it is in burst mode or!* :(  )

Bye,tnx, Aldo

Re: MMC timings and write speed
Quoted text here. Click to load it

Maybe the access is faster but there is also a kind of frontend, else you
would
have to code ECC as that were the case with smartmedia.
Maybe CF is faster but, driving them from a PIC is somehow overkilled.

If speed is a premium the best solution is probably to use a SD card were it
seems
possible to work faster. But as long as a front processor is present ... the
only way
would be to do its job too in the PIC and using some kind of NAND flash. Then
you
have total control of what  you do.

If not huge capacity (~ 8MByte) is necessary a dataflash from Atmel would be a

better choice for predictible performance.

Quoted text here. Click to load it


Site Timeline