Hi,
I wrote this SDIO driver for the F103 for my own project. Feel free to use
it if you find it helpful:
https://github.com/openstenoproject/stenosaurus/blob/master/firmware/sdio.c
Hesky
On Sat Mar 15 2014 at 4:25:17 AM, Марко Краљевић <krasnaya.zve...@gmail.com>
wrote:
> Do you have this code in a repo somewhere? How is the progress?
>
> I've just had a F103 board fabbed that has a microSD slot connected to the
> SDIO interface, so I'd like to play around with it. :-)
>
>
>
>
> On 27 November 2013 15:50, Chuck McManis <chuck.mcma...@gmail.com> wrote:
>
>> On Wed, Nov 27, 2013 at 12:03 PM, Donald E Haselwood <
>> dhaselw...@verizon.net> wrote:
>>
>>> 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.
>>
>>
>> Yup, I think to bullet proof it I'm going to have to scrounge as many
>> cards as I can. Weston commented that it should probably support multiple
>> cards, which I questioned since there is only one SDIO peripheral, except
>> of course as you and others have pointed out each SPI port it potentially
>> another card. I was reading the old BSD NET2 code the other day and liked
>> their separation of the network interface and the network stack, which
>> presumably you could do here as well with a "physical" layer and then a
>> protocol layer on top of that. What I don't want is so many layers that its
>> stupidly layered, in the ST example code they have code in the
>> initialization section that calls a function (which is called only once by
>> this one function) which checks a bit by using another function which does
>> this: if (register & mask) != 0) return 1; else return 0;. The entire stack
>> of functions could be replaced with "#define error_check(register, flag)
>> (register & flag) != 0)"
>>
>>
>>
>>> 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.
>>>
>>
>> There are a number of cryptic notes in the SD physical layer spec about
>> "you might have to do this 3 times to be sure" kinds of things. Speaks to a
>> poor to non-existent test suite. Also adding of features to a pre-existing
>> standard.
>>
>>
>>>
>>> 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>)
>>>
>>
>> True, and many people (and probably me at some point :-)) just say
>> "Tested to work with these cards, <list> other cards
>> may work or may not." :-)
>>
>> --Chuck
>>
>>
>>>
>>> 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
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
> ------------------------------------------------------------
> ------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech______________________________
> _________________
> libopencm3-devel mailing list
> libopencm3-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
libopencm3-devel mailing list
libopencm3-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
