small numbers of µS delays

[wevets]

I need to be able to insert delays of a few µS into some code to manage hardware delays in GPIO reads. I see the API ets_delay_us() in the esp-idf includes at .../esp32/rom/ets_sys.h, and in .../components/esp_rom/esp32/ld/esp32.rom.ld, which appears to be a table of addresses of routines in the rom.
Is this correct?
Does ets_delay_us() actually provide delays of a small number of µS? I don't need great accuracy. I can work with large errors. If I call ets_delay_us(2), anything between 2 and 8 µS, or even more, is OK.

Can you tell me if this API actually works, and if so what kinds of errors I can expect and what influences those errors. For instance, if I call ets_delay_us() between calls to portDISABLE_INTERRUPTS() and portENABLE_INTERRUPTS() (where much else is going on but only for a total of less than 200 µS or so) will the ets_delay_us() calls be reasonably accurate?
Thanks.

[PeterR]

Hi,
The thing with uS delays under software control is you need to clearly understanding you're tolerances. Low uS delays will not be easy in software because another task/ISR might cut across you.
You say "2 and 8 µS, or even more, is OK." but is Is 2mS ok?
You're upper accetable helps better frame the answer.

I would be tempted to think about using hardware capture e.g. the RMT module. You could then sample using hardware timing. If you need extended samples then maybe a serial periperal e.g. SPI? You would tie up more pins but you could generate a bit stream using DMA happily at high MHz...
100KHz - 500 KHz is what hardware sampling was designed for!

The answer does depend on; how precise your timing, the maximum gap between readings and the number of readings you want to sample. Also stuff like aliasing & beats which is again about regularity.
My immediate thoughts are that when you say 2 uS then I think hardware sampling (or dedicate a core) but mostly hardware sampling.

Could you explain you're application & why you want to sample at 2uS?

[wevets]

PeterR, thanks for your reply.

I'm bit-banging an external ADC to read out a series of bits. I need to be able to do this both on one of the cores and in the ULP, to I'm running the GPIOs as RTC GPIOs. When I send out a clock pulse on one pin, I need to wait until the data is ready on the other pin, and I do this in a loop until all the data is read. I don't want to waste any time here, as to get an average read, I read 128 samples, which takes some time, adding them as I go along, then shift the final sum right by 7 bits to divide by 128. I do each individual read of the 128 with interrupts disabled as a delay of greater than 60 µS will cause the ADC to power-down. The 2 mS you mention is unacceptable.

Before I posted the question I tried a calibrated "do-nothing" loop, but it seems the compiler is too smart for me. It seems to optimize "do-nothing" code by eliminating it, which is a great optimization, but not very helpful for what I need. I don't know how to turn off that optimization, especially for a short stretch of code. Maybe with a pragma????

After I posted my OP, I thought of hardware sampling too, which should be quite repeatable, especially since I have interrupts disabled during an ADC read cycle, and I should be able to hit my tolerances fairly easily. I hit the tech reference and I see that several counters are available, but I haven't decided which one would be best and which would be easiest to sample. I was thinking doing a calculation on diff on reading a clock counter knowing the clock speed, that is, just reading the counter until the difference between current and initial reads was what I wanted, or maybe doing a calibration another way. I'll look into the RMT module. Do you have any other suggestions on this?

Then again, if the ets_delay_us() API actually works, everything above is moot. I'd like to hear from the company gang who monitor this board.

[Sprite]

Company gang here. ets_delay_us works by actively polling a timer until that timer value is larger than a given value. This means it should always wait the given amount of uS. Normally, it will wait for exactly that amount of time before it returns, but as Peter already indicated, you're running on a multitasking system so you may have your task switched or an ISR kicking in, causing the call to return a fair bit later. Statistically, this should be more of an exception than a rule though, given you only wait for a few uS.

[PeterR]

A counter would do it as well along with something driving the ADC clock. Without knowing the ADC that's about as far as I can go.
I think we are both on the same page, hardware would be better and lets you (deterministically) sleep at night - but software could do it provided you're interrupts are disabled.
Don't forget to locate your loop & code in IRAM though!

One word of warning. I had a weird I2C issue the other day where it appears the I2C driver was cut across by another ISR (2mS or so) and that resulted in corrupted I2C data. The jury is out on if this was an ESP or external device issue. I moved the I2C to another core which only had one other ISR which I know has a maximum duration of 150uS. Personally I would go with the hardware solution as generally that plays nicer with everyone.

[wevets]

Thanks for your replies.

ESP_Sprite, to me, "the company gang" is a term of respect. You guys have always been the source of the "straight skinny" on what's going on in the idf and the ESP32. I especially appreciate your explanation of esp_delay_us(), as the underlying code is impossible to get at short of reverse engineering the ROM, which is pretty much impossible given my resources. Given that I call esp_delay_us() between calls to portDISABLE_INTERRUPTS() and portENABLE_INTERRUPTS (calls I use sparingly and only for short times), I'm pretty sure I'm getting reasonably accurate delays, and I'm glad such a mechanism exists. Thanks.

PeterR, thanks also for your replies. You've helped me understand the underlying issues and risks.

[Sprite]

ESP_Sprite, to me, "the company gang" is a term of respect.

No worries, I didn't interpret it negatively to begin with