| Age | Commit message (Collapse) | Author |
|---|
|
So this driver works on faster MCUs (that run this loop fast) with older,
slower SD cards.
Fixes issue #7129.
Signed-off-by: Damien George <damien@micropython.org>
|
|
This is run with uncrustify 0.70.1, and black 19.10b0.
|
|
Otherwise the code can get stuck in an infinite loop if the SD card fails
to respond to a read.
|
|
|
|
pyb.umount(None, mountpoint) no longer works.
|
|
It seems that some cards do not tolerate releasing the card (by setting CS
high) after issuing CMD17 (and 18) and raising it again before reading
data. Somehow this causes the 0xfe data start marker not being read and
SDCard.readinto() is spinning forever (or until this byte is in the data).
This seems to fix weird behviour of SDCard.readblocks() returning different
data, also solved hanging os.mount() for my case with a 16GB Infineon card.
This stackexchange answer gives more context:
https://electronics.stackexchange.com/questions/307214/sd-card-spi-interface-issue-read-operation-returns-0x3f-0xff-instead-of-0x7f-0#307268
|
|
This was a typo from the very first commit of this file.
|
|
|
|
|
|
machine.SPI(0) results in ValueError on ESP8266. SPI(1) is the user
hardware SPI port (or use SPI(-1) for software SPI).
|
|
This commit fixes two things:
1. Do not allocate on the heap in readblocks() - unless the block size
is bigger than 512 bytes.
2. Raise an error instead of returning 1 to indicate an error: the FAT
block device layer does not check the return value. And other
backends (e.g. esp32 blockdev) also raise an error instead of
returning non-zero.
|
|
|
|
There were several different spellings of MicroPython present in comments,
when there should be only one.
|
|
|
|
respones -> response
succeses -> successes
|
|
Following best-practice use of the const feature, to make it compatible
with Python.
|
|
With backwards compatibility for pyboard.
|
|
|
|
Apparently some cards need more than 2 retries. See issue #1482.
|
|
|
