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 tomip, 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 themanifest.py, and hence not included in the distributed package
• implement only thecrc7 function and do it in pure Python
• still support passing in a function for CRC16 data checks, the user can then copy the fastcrc16 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 thegb() naming and thespiff 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 shortermemcmp().

Forgb() I just feel that it's too cryptic for a public function. Maybebits() would be better and still short?

Forspiff(): 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 aw = self.spi.write local variable sospiff would bew(b'\xff').

If you want to measure the impact of a change to the Python code, you can run it throughmpy-cross -O3 sdtest.py and see how big the outputsdcard.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 (mostrecentcalllast):File"/lib/freedeej/hw.py",line188,insd_initFile"sdcard/sdcard.py",line85,in__init__File"sdcard/sdcard.py",line121,ininit_cardFile"sdcard/sdcard.py",line209,incmdOSError: [Errno5]EIO:CRCerroncmd:00

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