Unreliable GPIO

[PeterR]

I do appreciate the difference in cost; the value/risk assessement is an individual choice. As a home hobby I would go cheap but for product (& a few $100) I would go with time too market.

Guess I am not fully tuned into the issue. I thought that you had 3uS gaps (which is an issue to you) but you have it now

successfully running

Great that you are up n running!

[jeeves]

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.

[jeeves]

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 still massive.

Wifi disconnected:
min 40 ns, avg 75.05 ns, max 360 ns

Wifi connected but not transferring:
min 40 ns, avg 75.09 ns, max 400 ns

Wifi + data:
min 40 ns, avg 76.70 ns, max 880 ns

The cause for big spikes, at least my current guess, is memw waiting for the other core's flash cache miss.

[jeeves]

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.

[PeterR]

It may benefit to recap your problem & results. It is then easier to review/support.
I think that you state; (1) that you are running a tight loop collecting GPIO readings, (2) you sample on a single core running in IRAM but yet you see close to 1uS 'wobble' in the readings (depending on which other functions you enable).
I would like to understand more about your signal source & why you believe that the source is faithful.
I am also quite interested in your observation that adding other ESP functions affects the 'wobble' and especially the causes e.g. software or hardware.
To understand if software then it would be best to see some code (method does matter) but do appreciate that the MVE takes time. If hardware then I can imagine that; (a) various ESP components might share a bus, (b) that transaction sizes might be relatively 'large' and so that one might see latency effects when enabling other ESP components. Not looked at the ESP bus details.*
I also see latency effects but I only care when >100uS. My issues may not be yours but yours might be mine (if that makes sense)?
* EDIT: But maybe both cores end up using the same bus? Certainly if two cores try to use the same SPI channel but maybe also other stuff? Going have to RTFM.

[jeeves]

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.

I stumbled upon this link:
https://github.com/MacLeod-D/ESp32-Fast-external-IRQs
He has also posted here, but didn't have a good reception on the coopos things, not sure if he's still on this forum. His data suggests that he does not see latency spikes this high. He runs in a pinned task with interrupts disabled and watchdog compile-time disabled, perhaps there is some difference in config.