Looks pretty good.
For multiple card support, you may want the card slot # passed as an
argument for each call.
sd_initialize()
For devices with power concerns, or hardware with issues you will likely
want to run at different speeds. Maybe a sd_set_speed()/sd_get_speed() or
the like.
For insert/remove notification I've used a callback before & liked that I
could send an event to myself vs. polling. But that can also add some
complexity if on an ISR.
Being able to enable/disable CRC checking is useful - especially in new
hardware bring-up.
If you don't want to write your own:
https://open-roadster.com/svn/public/crooner/trunk/library/memcard/src/crc.h
https://open-roadster.com/svn/public/crooner/trunk/library/memcard/src/crc.c
Having working SD out of the box is a huge time saver. People often expect
that it's easy to add that since it is everywhere, but it can be a huge
time sink.
Thanks!
Wes
On Tue, Nov 26, 2013 at 6:14 PM, Chuck McManis <chuck.mcma...@gmail.com>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
