Nice, I also have one of those sitting in the basement.ESP_Sprite wrote:(If any because some old projects of mine could perhaps use an upgrade...)
Cheers
Nice, I also have one of those sitting in the basement.ESP_Sprite wrote:(If any because some old projects of mine could perhaps use an upgrade...)
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?ESP_Sprite wrote: ↑Wed Apr 03, 2019 3:55 amI 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.
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.hpeteranvin wrote: ↑Tue Feb 28, 2017 11:51 pmJust 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.
Users browsing this forum: No registered users and 95 guests