SD over "shared" SPI bus

  • Why does the built-in SD class use a separate SPI bus (1?) rather than "share" bus(0) as accessed through the built-in SPI class? Is it possible to combine them? What would be the downside of doing this? As I see the upside, it allows me to add an SD card by using just one additional GPIO (CS for the SD card), rather than requiring three GPIOs dedicated to the SD card.

    PS - There exists an SD over SPI driver ( Is this what's used for the built-in SD class, just selecting SPI(1), even though the SPI class says only SPI(0) is supported?

  • After two solid says of trying to debug the modified SD over SPI driver, it turns out that there is a bug in the SPI class (see this post). After rewriting the driver to use only the write_readinto function, along with a dummy buffer filled with 0xFF, all of my test SD cards worked perfectly. What probably delayed me discovering this low-level issue is that a few of my test SD cards did work, but many did not, with a wide variety of failure modes. Clearly, sending 0xFF is a requirement, but apparently there are some SD cards that are tolerant of getting other values (like 0x55 in this case).

    The resulting code is fairly ugly right now. I'm hoping that the SPI class issue can be resolved quickly, at which point, I'll go back and test that version of the code.

    By the way, the original SD over SPI driver uses this syntax for SPI read functions: read(1, 0xff). This results in an error (extra positional arguments given); the documentation says to use: read(1, write=0xff). This is accepted, but the 'write' argument is ignored.

  • @Eric24
    Yes, when finished put it somewhere :)

  • In case anyone is wondering, it is indeed possible to interface an SD card over SPI bus 0, shared with other SPI peripherals. The SD over SPI driver that I referenced doesn't work "as is", but I was able to get it working by making a few modifications. I am still having trouble with at least one microSD card. I'm not sure at this point if it's a driver issue or a card issue--I've ordered an assortment of different cards (sizes, types, brands) for additional testing and am in the process of making some additional changes to further enhance the driver. If anyone's interested, I'll post the final code when I'm done.

Log in to reply

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.