General • Re: Squeezing PIO

Some great ideas here! Thanks!

For context, let me take a step back and explain the problem I'm trying to solve.

The is the response of an SD card to an ACMD41:(See SD Specifications, Part 1, Physical Layer, Simplified Specification, Version 9.10, December 1, 2023.)

I'm trying to make this library work for eMMC as well as SD Memory Cards. Here is the response of an eMMC to a CMD1:(See JEDEC STANDARD, Embedded Multi-Media Card (e•MMC) Electrical Standard (5.0), JESD84-B50, SEPTEMBER 2013.) (The logic analyzer is misinterpreting the R3 response as R1.)

Notice that for SD Card, SDIO CMD goes low with the falling SDIO CLK edge preceding the response. The PIO code works fine with that. However, for eMMC, CMD goes low with the rising edge of the first CLK of the response. The PIO code misses the first bit of the eMMC response. You can see that the logic analyzer parses the "Argument" as 0xc07f8000, which is what I am looking for, but I'm getting 0x80FF0000.My theory is that is seeing CMD as 1 even though it is switching to 0, and if I could delay the jmp PIN by one PIO clock (1/4 of a SDIO CLK cycle, or 1/2 of D1) it would see that it is now 0.

...
Another way would be to use a clock generator, and synchronize with it, though not so easy on RP2040.

I'm going to look at what it would take to use something like a PWM as a clock generator. I imagine I'd have to do the trick that's already in .program sdio_data_tx (and similar in .program sdio_data_rx) in .program sdio_cmd_clk as well. I'd have to make sure that the PIO clock is exactly 4 times the PWM clock frequency.

Code:

mov OSR, NULL       side 1 [D1]    ; Make sure OSR is full of zeros to prevent autopull

I don't know enough about this, but...I use PIO for communicating with an SPI display. And I use autopull as well. But I don't clear the OSR before transmitting. So I have to ask if that is really necessary? Or am I not understanding this?

I thought the same thing, so I commented it out, and tests always fail that way (with an SD Card, which should work). I didn't delve into it, but I guess it normally has something left over in the OSR.

Just guessing: Maybe if the 4th state machine is not used yet, it could be used for the clock (2 instructions). The 2 nop and all side could then probably be eliminated. Then use .side_set opt instead of set pins or set pindirs to free some slots.

I think that could be a good alternative.

...
That seems to consist of three State Machine programs. 18, 5 and 9 bytes respectively.

That will use all 32 bytes of instruction memory for a single PIO, but do they all need to run on the same PIO ?

It would be nice to have it all fit into one PIO block. This is library code, so I try not to use too many system resources. The other thing is that the library is currently capable of running two SD Cards (on separate SDIO buses) in parallel (if you don't mind dedicating 12 pins and two PIO blocks and lots of other resources to it). (The same code is used in FreeRTOS-FAT-CLI-for-RPi-Pico, where it is easy run thing in parallel.)

Looks like the same SM is used for the last two (tx/rx) programs, and the SM is reintiialized based on which is being used) - seems like you could use the same instruction memory for both (you could load the larger one at the start and manually switch the program instructions out yourself)

That looks like it could work. I think I've seen an example of something similar somewhere. Any idea where that might have been?

Statistics: Posted by carlk3 — Wed Apr 23, 2025 6:30 pm

---