There are several watchdog registers I can't find documented anywhere, in the headers or the technical manual. For example Requesting docs for these.

Your summary is correct. The other end is an old "hard realtime" style microcontroller. By this I mean it has direct access to GPIOs and cycle counting instructions on it is accurate, both unlike the ESPs. ESP accesses GPIO over a bus, and executes instructions pipelined and partially out of order. ...

Nope, not memw. I removed the memw from the w1tc write, and the timings were identical. Then I forced the write again via DPORT instead of AHB, and timings didn't change. So it looks like a busy bus, and likely not workable around.

Managed to get the higher sample rates working. The default format and a few others used too much cpu, but dumping to binary worked fine for high rates. The 1 MHz was indeed far too inaccurate. I tested pin 21's variance, how long it stayed high, at 25 MHz. While not quite 3 us, the variance is stil...

p 117, section 6.3.1 of the technical manual

The DMA Engine accesses SRAM over the AHB BUS.

not what I hoped for. If it was DPORT and AHB was free, and AHB did not need memw, that would allow GPIO writes over AHB to proceed unhindered. But DPORT requires memw.

https://esp32.com/viewtopic.php?p=35711#p35711 In the event of a cache miss, the cache line is automatically filled via a read from the flash chip. The cache line size is 32 bytes. With Quad SPI (QIO mode) this requires something like 75 clocks to fill the cache (8 clocks for the command plus 64 clo...

Second core code is successfully running, GPIO parts have delays So the entire project isn't successful yet. That just meant "core 1 starts and stays up, entirely on my code, no freertos", which nobody has publicly achieved.

@p-rimes I use sigrok's latest stable (sigrok-cli 0.7.1, libsigrok 0.5.2/5:1:1), and I tried with three channels at most rates. I opened this bug https://sigrok.org/bugzilla/show_bug.cgi?id=1565 . Poor quality USB is a possibility, I use the USB B cable that came with the unit. However it's looking ...

https://sigrok.org/wiki/Mcupro_Logic16_clone

Not sure if I mentioned it anywhere, but core 1 code is fully in IRAM. So flash delays not possible either.

Saleae16 clone arrived, but sigrok is having issues on keeping it dumping more than a couple sec. Anyway, I found some random lag spikes of up to ~720 cycles (~3us), which shouldn't be possible - in the memw thread, ESP_Sprite says memw should take at most a hundred cycles, and the GPIO.out_w1* writ...