This feels like a bad solution. At least the STM32H7 line has SPI slave functionality in hardware, no need for PIO. The h7a3 can do full-duplex at 45 MHz in the datasheet. I've been able to overclock the SPI master, so 45 is likely conservative. So that's 3x faster reads. Writes up to 100 MHz, almost 5x faster. And then no PIO programming. I guess you'd have to do a bit of work with software to get DMA going during the dummy cycles, so maybe the read command wouldn't work, but that seems like a worthwhile tradeoff for such a bit performance improvement. It also looks like this library fully utilizes a core to meet latency needs? That's a bit much.
The cheapest STM32H7 costs about 4x more than RP2040 and runs at 5x the clock, so the fact that it would be 5x faster doesn’t imply a defect in this library.
STM32H7 is just an example. Most (all?) STM32 with has hardware SPI slave support. For example the STM32F030C8T6 is on JLCPCB as a basic part (no per-part cost for assembly) at $0.82 while the RP2040 is $1.11.
While the RP2040 and RP2350 has a much nicer to use SDK and for certain applications like USB it is much easier to set up, the STM32 is much more versatile and is just a much more mature product (don't get me started about the RP2350 having broken pull-downs on GPIO pins).
I'm wondering if there is any practical use for this.
Before I came across this tool, one use case I’d conceived for a tool like this is to help in debugging and reverse engineering. One could hook this up to a microcontroller under test/analysis and essentially monitor its “disk I/O” or supply it with arbitrary data.