STM32 SDMMC & SDIO - why max 1 SD card only? - Page 1
Forum section: electronics / general

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: February 08, 2019, 08:55:36 am
content: I'm writing an SDMMC driver for my C++ RTOS for microcontrollers -http://distortos.org/- and there is one thing which really puzzles me, making it hard to decide about class hierarchy. In the Reference Manual for STM32F7 (but the same is true for other chips, both for SDMMC and SDIO peripherals) you can read the following at the very beginning:QuoteWhere does this limitation come from? As far as I understand SD cards (which is hard given the "quality" of the SD documentation) using one card should look exactly the same as using ten - from the point of view of SDMMC peripheral this is just sending commands, receiving responses and transferring data blocks. To use more than 1 card you just need to make sure to "select" the proper one with CMD7 before talking to the selected card and that's it. But this selection process is done completely in software, in the higher layer than SDMMC driver.I've found some clue in the mentioned SD documentation:QuoteBut this (according to my understanding) affects high-speed mode only, you can stick to default-speed mode, which is (surprisingly (; ) the default mode after card power-up.The reason why I'm asking this questions is because I cannot decide whether I should model the class hierarchy with assumption that the SDMMC peripheral IS the memory card, or maybe that SDMMC peripheral should be represented by dedicated "SD/MMC host" class, which may be associated later with a memory card object. The second model is much closer to the situation possible while using memory cards in SPI mode, where you can have as many as you like connected to the same SPI bus.Thanks in advance for any information (;

author: capt bullshot
author_rank: Super Contributor
timestamp: February 08, 2019, 09:59:32 am
content: Can't help with your architectural decision, just my 2 cents:I've rarely seen the need to use more than one SD card in an embedded system running on a typical uC, so why bother with more than one card?From the HW side, these high speed modes will be difficult to layout if more than one SD socket is involved. I'd prefer a simple point-to-point layout over a bus structure in HW, so if your RTOS supports one card per controller, I'd be fine.From the SW side, I'd prefer the most simple model, not the most sophisticated.

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: February 08, 2019, 10:29:18 am
content: While I generally agree, I have this deep urge to just know "why" (; But seriously - I'd really love to make decisions based on facts (which I'll hopefully learn) instead of just guesses and assumptions.However it is true that a setup with more than 1 memory card socket would be hard to use, because you don't have a way to say "communicate with the card in this slot" (as in SPI by using "slave select" line) - from my understanding you would have to detect the cards in the ascending order of their CID and after inserting a new card you have to reset all the other cards and rediscover them again. which would then change RCA number each card has.

author: amyk
author_rank: Super Contributor
timestamp: February 08, 2019, 12:37:32 pm
content: Quote from: capt bullshot on February 08, 2019, 09:59:32 amThis can't be emphasised enough. There's been enough discussions here of bloated vendor abstraction libraries to read through already.

author: Rerouter
author_rank: Super Contributor
timestamp: February 08, 2019, 12:51:25 pm
content: Its likely the common process of manufacturer library code, get it to a state where people can plug and play your product if there application lines up exactly with the spec sheet they gave the programmers on the day, an no further because that costs money.To write software that can fully realise every function a microcontroller peripheral can do without bloating is hard. so my guess is they focused on 1 card, and stopped there, throw it on a dev board, tried it with a few cards they had lying around and called it done.

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: February 08, 2019, 06:18:33 pm
content: Quote from: Rerouter on February 08, 2019, 12:51:25 pmBut the Reference Manual - from which the quoted limitation comes - is for the hardware only. There's no mention about vendor library code anywhere in the documentation for the hardware. These are two completely separate entities.Even though the first page of the chapter about SDMMC peripheral says only 1 SD card can be used, this is what you can read further:39.4.4 Card identification process...QuoteSo SDMMC supports only one card, yet they describe how to detect many... I really don't know what to think...

author: amyk
author_rank: Super Contributor
timestamp: February 09, 2019, 01:08:17 am
content: That might just be copy-pasted from either the SD spec or another doc where the peripheral does support multiple cards.

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: February 09, 2019, 07:09:07 am
content: Quote from: amyk on February 09, 2019, 01:08:17 amThis is another interesting thing - I've browsed other STM32 families, and each reference manual says the same thing - 1 peripheral == 1 SD card. This actually brought me to another question, whether this limitation is something STM32-specific, or maybe it's just the same everywhere, because somehow no one supports more than 1 card?

author: obiwanjacobi
author_rank: Super Contributor
timestamp: February 09, 2019, 07:21:52 am
content: Quote from: Freddie Chopin on February 08, 2019, 08:55:36 amUse templates to flip the hierarchy around by deriving from a template parameter.Any peripheral can be represented by 3 main layers:- driver: pin interfacing- protocol: what do the bits mean/ how to interpret them- usage: what you do with itAny of these layers can be split further as the need arises.Code:template <class T>class Usage : public T{// calls T::protocolFns}template <class T>class Protocol : public T{// calls T::driverFns}class Driver{// calls regs etc.}Using this in a program would look something like:Code:typedef Usage<Protocol<Driver>> MyUseOfX;MyUseOfX myX;myX.usageFn();+ Every layer can be extended or replaced+ No virtuals / no overhead+/- (depends) Memory usage over code sizeSo the idea is that you don't bake in a class hierarchy but leave that to the user/dev.Browse my ATL library for examples.

author: Freddie Chopin
author_rank: Regular Contributor
timestamp: February 09, 2019, 07:39:35 am
content: Interesting approach, but this would mean at least double the work and that a lot of code would have to be in the headers, which I don't really like (;

author: capt bullshot
author_rank: Super Contributor
timestamp: February 09, 2019, 11:31:01 am
content: Quote from: Freddie Chopin on February 09, 2019, 07:09:07 amThat might be true. Most more complex peripherals like USB, Ethernet MAC and SDMMC are IP blocks that get re-used over many chips, and might not have been designed by STM themselves, but bought from some IP supplier. That IP supplier might have sold the same IP to other MCU manufacturers. Often these IP have hard configuration options, so one MCU manufacturer might support more than one SD card, the other one not.