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 (https://github.com/pycom/pycom-micropython/blob/master/drivers/sdcard/sdcard.py). 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?
-
@paulm Ignore recent post; I fixed this myself: https://forum.pycom.io/topic/4000/fixed-broken-sdcard-py-library-previously-impossible-to-have-external-spi-usd-card-with-pycom-boards
-
@eric24 Any chance you could share your corrected SPI SD Card interface code? It is INSANE that I've been having as much trouble as I have with interfacing an SD card to a GPy and it now seems I've found the issue: not my fault, but Pycom's, for ostensibly failing to fix the SPI issue. I had to make all the ridiculous manual corrections to sdcard.py (nobody in that thread actually posted a final corrected working version).
Once I did that, including adding the "write=" parameter to the spi.read() calls, I now have the SD card correctly being read from once, and then permanently corrupted whenever I try to write. I have to reformat the card every time - inoperable. I think your post reveals the reason why.
How in particular do we solve the ignored write= parameter in SPI.read(), which I assume is what's preventing me from using the SD card?
I really cannot believe this isn't talked about more. Not everyone is going to use a Pycom board in one of those power-hungry shields. I use my GPy just as an LTE modem that my main MCU turns on/off to upload. My GPy needs to store packets on an external SD Card over SPI.
Thanks for helping!
-
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.
