General • Re: PIO IRQ latency

As a copy_to_ram build?
. . .

Yes.

. . . For the sort of application you described however (~300ns timing budget) I'd expect you to have enough margin not to need to account for every cycle.

Exactly. I'm interfacing with a Z80 running @ 3.125MHz (320ns T time). For the instruction fetch it is OK to have overrun, but for the IO access it is not. Anyway, we're talking about the mem access now which is indeed longer than 300ns (about 4-500ns should be ok).

Still, that doesn't get us any closer to explaining your problem - your setting of BUS_PRIORITY looks correct, and I argue that it shouldn't matter anyhow.

Correct

Have you measured with a scope to see what access time you are actually achieving (ie. from Z80 asserting read to transition on a data bus bit?).

Unfortunatelly I don't have any digital scope (just a logical analyzer). But.
The two modules I have (A2 based WaveShare and A4 based WeAct) has different routing in my test cards (as my design evolved...). So I rewrote in assembly the irq handler that takes care of memory reads/writes for A2. In the handler there about 30 cycles required till I reach the data out step (and about 25 ticks to get to sample the data lines). Adding the extra 12 clocks on Cortex-M33 for interrupts and a few more because of bus-fabric delays I would say it requires 45 ticks to put the data out to the D0-7 lines starting from the Z80's /MREQ falls. Having set the syclock to 200MHz on the RP2350 it is around 225ns, on 150MHz pi it is 300ns. Both of them beyond the limit.
I have a small memtest program on the Z80, and running the above mentioned IRQ handler the test sometimes fails (sometimes the computer crashes). Even a dead simple small BASIC program fails (poke, peek, if matches goto10)
Now. I have rewritten the same IRQ handler to have the datalines in accordance to my A4 card (the data lines instead of pin 23-30 are on pins 32-39 on the A4 board), and some other signalling lines also replaced. The clocks - as I count - are kind of the same: ~30..
The test program runs flawlessly for about 1 hour. On the A2, it fails within 2-3 mins.

In the meantime the other core is calculating the screen data and transfers (using DMA) every line to a PIO which puts the data on the screen, pixel-by-pixel. This will make this '80 computer a sprite-enabled computer. But only on MCUs have A4 stepping.
Why?
I know there is a lot of traffic ongoing on the busfabric, but the prorities are set. The IRQ handler must be the topmost prio as it has to respond to the Z80 CPU immediately. It works accordingly on A4.

I moved away from PIO initiated interrupts (to GPIO interrupts and a lot of if's in handler) because I was suspecting that the PIO traffic was blocked by the DMA. Sure I was wrong, but on A2 that didn't work either.
Some more features should be added to this project so I'm afraid I have to go to A4 and design my full board. The Waveshare was tempting because it has the USB D-/D+ lines also routed.
I don't know what LDO is used on WeAct (A4), but on WeShare, there is a 700mA, 3v3 LDO. That should be enough. Or its power block not as good as on WeAct? .. If that is the case I'm afraid I will also fail with my own design, probably. I'm not a professional PCB designer...

... achieving a stable 205ns access time

That is really imressive.

Statistics: Posted by dikdom — Sun Dec 14, 2025 1:46 pm

---