External Interrupt Latency

[Hans Dorn]

(If any because some old projects of mine could perhaps use an upgrade...)

Nice, I also have one of those sitting in the basement.


Cheers

[hpeteranvin]

Out of pure curiosity; any results on this?

[ESP_Sprite]

I think there has been a little bit of progress, although not specifically for this purpose: the GPIO drivers have been optimized a bit so if you use the ESP-IDF API, your interrupt latency should be a bit lower (but not as low as using the bare metal), and ESP-IDF now allows you to have high-prio assembly interrupt handlers without having to copy-paste the ESP-IDF vector/startup code integrally.

[hpeteranvin]

For what it is worth, I'm perfectly happy to write in assembly for this purpose

[berlinetta]

I think there has been a little bit of progress, although not specifically for this purpose: the GPIO drivers have been optimized a bit so if you use the ESP-IDF API, your interrupt latency should be a bit lower (but not as low as using the bare metal), and ESP-IDF now allows you to have high-prio assembly interrupt handlers without having to copy-paste the ESP-IDF vector/startup code integrally.

Hello! I am attempting to put together some bare metal code for use on the APP CPU. From what I am reading, I presume there is no good option for configuring a bare metal vector table which can be used to call my handlers directly... is that correct?

I am interested in learning how I should properly register my interrupt handlers to ensure they are executed in the most efficient manner.

Thanks in advance!
Mark

[cominss]

Just to clarify: I don't need to make the same cycle count, just the same wall time (so approx 36/54 cycles at 160/240 MHz).

To be specific, this application operates as a bus slave to an 8-bit legacy computer bus. The most time-critical handler operates as a RAM simulator: it gets an interrupt, reads address bits off 16 GPIs, looks up an internal 64K table, writes an 8-bit data values to GPIOs, and sets the GPIOs to output. That has to happen within the time frame I indicated in order to avoid a lot of additional external logic.

hi, Im looking to do something similar in interfacing an ESP32 S2 with a Z80 based computer's data bus running at 4mhz. It's primarily for I/O emulation but my concern is responding to the port read/write/control signals cycles fast enough and figured I would have to do address decoding and some sort of buffering in a CLPD.

May I ask if you managed to make the transition to ESP32, or otherwise found any further info on the subject you could share, please?

[hpeteranvin]

Eh... ended up going with the platinum solution of using an FPGA for the bus interface; this was in no small part due to teaming up with a board designer willing to do the physical layout side of it, and because it really increased what could be done (HDMI output!)

I'll post a couple of git links later

[hpeteranvin]

Hardware: https://git.sweproj.com/ABC80/max80.git
Firmware: https://git.abc80.org/abc80/max80/fw.git

This is a bit offtopic here, I think, but feel free to PM me (or at least open up a separate thread) and I'd be happy to chat about a bunch of the options that got investigated and considered.