Logging to SD-card
Logging happens in (space-and-time-saving) binary format, via the SPI protocol. Most MMC cards do not support SPI protocol. All SD-cards should support SPI (according to the standard specification), but we found that some (eg. some Maxwell) actually does not support it. It is safe to try, does no damage.
See http://www.vems.hu/download/SD/v3SDcard.htm for usage.
Where can interface card be purchased? It is not on the WebShop.
- Gunni - Yes it is in the webshop
http://shop.vems.hu/catalog/v3sdcard-p-131.html
...
GenBoard/VerThree supports logging to SD-card plugged to the "ISPI header". which was designed for this. (the same header is available since v3.0).
SD-Card is normally NOT removable (different cardholder-daughterboard and blind endplate is used), but installed permanently inside the case. Overview data can be downloaded very quickly via RS232 port. Selected files (each startup of the engine is logged to different file) or selected parts can be downloaded (appr 1 min download time / 10 min log).
Some installers sometimes choose removable SD-card (with appropriate endplate)
Advantage: can be swapped with another (erased to full-00 earlier). This is not recomnmended, as viewing the data from a card removed from the controller (especially when cardreader is connected to windows PC) currently requires more steps (data can be read to binary file with dd command and formatted to csv by VemsTune). Probably only useful when logged data to download at a time exceeds 200 logged minutes.
- naturally the SD-card can be inserted in same or different controller (with same firmware) and easily read via RS232 by VemsTune
GPS logging
- V3 can log GPS data to the internal SD card from revision 1.1.89
- GPS unit can connect to the main ( or secondary, if available) serial port.
- For details see: http://www.vems.hu/manual/vemstune/help2/htmls/v3/v3_ecu_logger.html Help page
Logging happens in binary format, via the SPI protocol.
See http://www.vems.hu/download/SD/v3SDcard.htm for usage.
- According to the standard, all SD cards support SPI.
- However, we found a type of maxell card that did not seem to support SPI mode.
- Therefore we provide card with each [SD card reader] (1Gbyte at the time of this writing) that was tested to work. Current log consumption is about 20 minutes per MByte (= 20 thousand minutes = 333 hours per GByte, that is about two oil changes)
Old thoughts:
For onboard logging (GenBoard/VerThree) we considered the SPI atmel flashes that appear MMC SPI-mode compatible:
- most MMC cards support the SPI protocol (possibly all, according to [this useful page] )
- [ 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