MMC timings and write speed

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

Thanks Kasper!

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?

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.

Nice site, thanks.

Aldo

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

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

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:

I h> Hi all!

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?

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

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.