2023 12 29
OK, SPI is looking pretty good; actual bit times are identical to what-they-should-be, so I'm not even going to note them down (whereas UART out of the PI has some drift, probably strange BAUD fractional maths).
SPI Waveform Integrity
So, there's just the question of waveform integrity, and (probably) the ability of the RP2040 to keep up, and there's the actually-delineating-and-echoing-etc test.
I'd like to look at some scope traces first, but I should probably do it in context (i.e. actually driving a pin, not free air), so I'll setup my little test rig...
CH1 (yellow) is Chip Select
CH2 (blue) is the Clock
CH3 (magenta) is Data Dout
| Mbit/s | Traces |
|---|---|
| 1 |  |
| 2.5 |  |
| 5 |  |
| 10 |  |
| 15 |  |
| 20 |  |
| 25 |  |
| 50 |  |
So the waveform basically looks like it survives all square-waved up to 5Mbit, then starts rounding off towards 10Mbit, and is probably serviceable between there and 25Mbit, where things are looking quite dicey indeed - as far as my relatively untrained eye can tell. By 100Mbit, all hope is lost.
I suspect that "the move" here will be two-fold: (1) to do decent EE and line these traces with via-punched GND noise capture (to prevent the crosstalk we are seeing), and then to instrument each packet with some kind of CRC.
I want to point out another benefit of the SPI route, which is that (if you look at the trace from 2.5Mbit) there is an inter-packet time of only 6 microseconds, so in our python sketch: