This page is for developers about logging to MMC
it takes complex and CPU-eating software to talk the native MMC protocol (bidirectional data line, CRC ...).
- However most MMC cards support the SPI protocol (possibly all, according to [this useful page] )
- SD is not simpler than MMC, but all SD cards support SPI!
Since we also use SPI for the knock-chip and MCP3208, it was an excellent choice to provide HW support SPI-based MMC on GenBoard/VerThree.
Old thoughts:
For onboard logging (GenBoard/VerThree) we considered the SPI atmel flashes that appear MMC SPI-mode compatible:
- [ http://www.atmel.com/dyn/products/product_card.asp?family_id=616&family_name=DataFlash%AE&part_id=2471 At45DB161B 16Mbit]
- [At45DB321B 32Mbit]
- [At45DB642 is dual interface, big]
- [At45DB1282 is 128Mb version of the above.]
- [related AVR appnote for dataflash usage]
Real MMC is basically the same electrical interface and protocol, but more available and can be removed if a socket is used.
Links
Working system with MMC and ATmega161:
- http://www.myplace.nu/mp3/ under hardware - yampp-7
- http://butterflymp3.sourceforge.net/sw.html AVR plays MP3 from FAT16 stored on MMC
- everything we need for logging to MMC. look at sources/fat...c and mmc...c
- minor cosmetics needed to use non-busy (but interrupt based) reading of SPI data
- http://www.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/USB/en/USB_MS_RD.htm MMC, SD and compact-flash (CF is nor reasonable because of high pincount connector)
- https://www.mysilabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/mcu_applications_appnotes.htm also zigbee and Ethernet and other stuff
- http://www.ece.ucdavis.edu/vcl/asap/asap_dev_board.html has links to some USB implementations (but all manufacturers with USB capable processors has that anyway...)
Flashfile C library for MMC/SD FAThttp://www.avrfreaks.net/index.php?module=FreaksTools&func=viewItem&item_type=tool&item_id=516
Procyon AVRlib with MMC, FAT, IP, graphic lcd support and lots more http://hubbard.engr.scu.edu/embedded/avr/avrlib/
Basic tech info about hw & sw interface system
Hitachi 16MB MMC-DataSheet as Sample
- http://www.squirrelpf.com/msavr/files/Hitachi16.pdf
- [SPI codee]
- [http://www.vems.hu/files/mmc/mmcsys-version_3-1.pdf
libraries:
- http://www.squirrelpf.com/msavr/files/mmc_eagle_lib_20040112.zip
- http://www.squirrelpf.com/msavr/files/MMCSocket20040111.zip
- http://www.squirrelpf.com/msavr/files/mmpack.zip
Tech sheets
- http://www.conwin.com.tw/multi.htm
- http://homepage.ntlworld.com/seanellis/mmcserial.htm
- http://www.singatron.com/MCC.asp
MMC and SD sources
Can someone check these Toshiba SD flash and comment on them? The question is if we can talk to it via SPI.
- SD-M3203B3
- SD-M6404B3 (1.5 *price of SD-M3203B3)
We would host in WebShop if suitable. Other type is OK, but we want to make sure to be fully compatible with our firmware and HW.
That aside, they are drivable through SPI (sure?)
Official doco appears to need licensed, but there's some limited info here - http://www.sandisk.com/oem/sd.asp
MMC sockets
also digikey has some sockets from HRC
hr845ct-nd $3.80
hr846ct-nd $3.80
Note that the MMC and SD have 7 pins with standard 2.54mm centerline so any card-edge connector should work. Your old 286 ISA motherboard comes to mind with a hammer in the background :-)
Steps to make it work in SPI mode
- from Linux, dd some known data (preferrably huge unzipped textfile, like the bible) on an MMC / SD card
- starting from an old floppy cable, solder wires to the card
- check some alien sourcecode that uses SPI
- check our SPI code for knock and MCP3208
- make a comm mode, that relays all data received via serial to the card (via SPI)
- and transmits all data received from the card (via SPI) through serial
- start to experiment on PC, easy, since everything can be printed and examined
- drive to SPI mode: CMD0 is 0x40 0x00 0x00 0x00 0x00 0x95 (last byte is CRC, constant in this case)
- note that CS is activated in any case, by the relay. Maybe CS must be activated after the first (0x40) byte transmitted, but before the last byte - not sure about this
- turn off CRC (CMD59 IIRC?)
- try to read a block from a certain address
- take note of the address and verify if the right part of the bible is printed
- try to write block (and read back)
AVR side
- repeat stuff that already works on PC
- initialization
- block read
- block write
- make a counter to know which byte is next
- the same bytes can be sent, as to MegaTune (49..51 bytes)
- note that start a new SendRTvar() sequence at the end of each block: 5 sequence fits, and a few bytes left for custom marker. The marker can be used by the user to mark runs. Eg. with a simply command like mkk53 he sets the marker to 0x53, so he'll know it means Friday eve testrun (when examining the log).
- save the counter to EEPROM, so we know where to continue
- alternatively make a binary search (after boot) to find first blank (all-FF?) block to write to
- command to erase blocks
- and set pointer to continue writing there
PC app
- to read from AVR
- and save data to csv file
- there are many apps for LogAnalysis, not part of this subproject.
Future options
- separate area for special data (config, tables ? not really needed in AVR since EEPROM is huge. Maybe needed in ARM though)
See also