Thanks @mendenm -- at first glance this all looks very good. I will try to find some time soon to review in detail.

One quick note... we don't currently have a way to publish .mpy files with native code to mip, so we will need to solve that first. Also we will need a fallback implementation for devices that do not support loading native code.

As @jimmo mentioned we don't yet have support for @micropython.viper (or native or asm_thumb) in this repository, because the .py file is compiled to .mpy and that compilation must use a different architecture flag for different target machines, and hence we would need different .mpy files, one for each supported architecture.

So, to make progress with this PR I suggest:

• move the fast crc routines to example/util files which are not included in the manifest.py, and hence not included in the distributed package
• implement only the crc7 function and do it in pure Python
• still support passing in a function for CRC16 data checks, the user can then copy the fast crc16 routines if they want to use this feature

I did a massive squash of the git repo, to get rid of all the drafts. I think this should be very close to consistent with comments and request. One thing I did not do was make gb() in _gb(). It's not really that private. Future users may want to parse other fields out the the big status block to get more info about their sdcards.

Is there a reason this is still stuck in PR purgatory?

Some cursory checks suggest that:

1. It still works
2. It's slightly faster

I'd be happy to vendor these libs into one of our builds to sniff out potential issues if it helps.

@Gadgetoid I'd sure be glad to have more people stress-testing it. I think the code is robust, but it's always the case that more test cases are better. I personally have only tested it on my Pi Pico, but with a fairly wide variety of SD cards, from ancient (< 2 GB) to 32 GB flavors.

I have a question about the gb() naming and the spiff and the `blocks()as naming. I was under the impression that micropython actually pays a small time penalty for longer names, so I tried to keep most names fairly short. If this isn’t really an issue, I’ll be glad to make these changes

It's more about the memory use than speed. Shorter names take less flash/memory, are smaller in compiled .mpy files and faster to transmit/copy. I'm not sure it's faster to use shorter names, if it is it would only be a very tiny improvement due to a shorter memcmp().

For gb() I just feel that it's too cryptic for a public function. Maybe bits() would be better and still short?

For spiff(): this is purely a helper function and can be called anything, even _s() if you like. But maybe it's not even needed, because it's such a short function it may be better to just write it out inline wherever it's used. After all, in most cases the code has a w = self.spi.write local variable so spiff would be w(b'\xff').

If you want to measure the impact of a change to the Python code, you can run it through mpy-cross -O3 sdtest.py and see how big the output sdcard.mpy is. The smaller the better! (Because smaller means less bytecode (unless you also shorten names), means faster execution.)

I can't say for sure yet where the issue is, but this driver always errors out when I try to bring up an sd card:

Traceback (most recent call last):
 File "/lib/freedeej/hw.py", line 188, in sd_init
 File "sdcard/sdcard.py", line 85, in __init__
 File "sdcard/sdcard.py", line 121, in init_card
 File "sdcard/sdcard.py", line 209, in cmd
OSError: [Errno 5] EIO: CRC err on cmd: 00

What's weird is I swear this code used to work intermittently with the reader/card I'm using, but maybe it's possible this aliexpress reader just gave up the ghost.