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
