Chuck, We did a SD card routine recently (spi only). You might want to check out a "handful" of various types of SD cards, e.g. 1 MB or less, 2 MB (which is a special case), and larger ones, and from different manufacturers. About the time we thought we had it all sorted out and working we would encounter a different SD card that wouldn't initialize. Once past the initialization it is all rather straightforward.
My friend who did most of the work on this recent SD routine is one who likes to take the original specifications and study them until he understands them, then writes the program based on that. SD and USB seems to be cases where someone comes up with a new twist, maybe trying to get around patents, and some additions get tacked onto the spec, making it rather messy to write code to handle all the cases. (<end of almost rant>) Don On Tue, 2013-11-26 at 18:14 -0800, Chuck McManis wrote: > for myself (and others) using libopencm3. I've got code now that does > the initial SD card handshake and figures out (for SD cards) what they > are. The api is evolving but I thought I would share with the list my > thoughts and folks could ignore them, comment on them, or suggest > alternatives. > > > sd_gpio_init(uint8_t width) > Initialize GPIOs for SD use, either 1 bit, 4 bit, or 8 bit > wide transfers. Since the GPIOs are fixed for most chips that > offer up an SDIO peripheral (TI and ST Micro) it seems like a > reasonable idea. I recognize that GPIO configuration is not > really in scope for the library on a general basis. > > sd_initialize() > resets the SDIO module, sets the clock up for card discovery. > This I have gone around and around on. So initially you set > the clock bus for 400Khz, 1 bit so that you can talk to > anything, once you know more about the card you can "upgrade" > the bus width and clock to something more palatable. If > systems have on SD card interface on them (typical) then just > bringing it up to what ever the card can do seems reasonable, > but if you have multiple card slots then perhaps less so. > > > sd_card_present() > Returns state of the card present signal. I've also been > hooking an interrupt in for state change on the CARD present > GPIO (which ever is set up to be it) so that if someone pops > the card out the driver can invalidate the card info. > > > sd_card_valid() > Returns true if the card has been identified. Generally this > reflects the drivers idea that it knows what card is in the > socket. If the card changes or if the card is not present it > returns false. One could always call this prior to doing any > SD command, thus avoiding problems in the event of the card > going wonky but that can slow things down on a fast card. > > > sd_send_command(cmd, flags, argument) > Send command to the SD card. The SD Card spec has a number of > commands, this function sends one to the card and collects the > SDIO result (OK, Timeout, CCRC Fail, or No Response)., Another > call (sd_get_response() copies out the response from the > response registers.) > > > sd_send_ap_command(acmd, flags, arguments) > Send an application specific command to the card. Things that > SD cards do like command 41 (send OCR register) which require > a prefix command to be sent first. > > > sd_send_data(block, buf, len); > > Write data to the card. Basic write call where 'block' is a > uint32_t identifying the sector, so up to 2TB of card storage. > Length is in blocks. > > > sd_send_data_async(block, buf, len, callback) > Asynchronous version of write, call back when done so it uses > the DMA engine to do the write and calls the callback when > that completes. > > > sd_recv_data(block, buf, len) > Read data from the card passing it a block number (again a 2TB > address space of 4G 512 byte sectors). Length is also in > blocks. > > > sd_recv_data_async(block, buf, len, callback) > Asynchronous version of reading data from the card call back > when done (uses DMA), with a callback to be called when the > read completes. Same as write *((void) callback(void)). > > > SD_CARD *sd_card_details() > Return details about the current card in the slot, null if > there is no card. Basic things about the card such as > manufacturer, serial #, size, speed, etc. > > > SD_STATUS *sd_get_status() > Read the status page for the SD card. I've gone back and forth > on this one too. I wrote it so that I can look at the status > of the whole card but not sure if it is actually useful > outside of debugging one's SD driver code. > > > Anyway, of note there is a pretty egregious typo in the sdio.h file > where the SDIO_CLKR constants are called POWER constants in the > comment. The flag definitions though are fine. My code currently uses > interrupts to collect the status and polls a volatile copy of the > status register in memory to identify completion. I'm not sure I like > that but its not really all that easy to do a sleep/wake type > architecture in an embedded system. > > > Thoughts? > --Chuck > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk > _______________________________________________ > libopencm3-devel mailing list > libopencm3-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libopencm3-devel ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ libopencm3-devel mailing list libopencm3-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
