micros() & delayMicroseconds() not good enough

[rosimildo]

Calling micros() twice is in a row, takes nearly 50uS.

Something line:

uint32_t t0 = micros();
uint32_t t1 = micros();
uint32_t delta_t = t1 - t0;
printf( "Delta = %u\n", delta_t ); // this prints around 51 on my system.

Looking at the implementation of micros() and delayMicroseconds(), it is clear they have too much overhead.

The code is trying to deal with "overflow" and entering critical sections, which is totally unneeded.

When you are dealing with "unsigned numbers", there is no such a thing like "overflow". It is a thing of signed numbers. Unsigned numbers rolls over, and that is it.

So you could implement these functions as:

inline uint32_t IRAM_ATTR micros()
{
uint32_t ccount;
asm volatile ( "rsr %0, ccount" : "=a" (ccount) );
return ccount;
}

void IRAM_ATTR delayMicroseconds(uint32_t us)
{
if(us){
uint32_t m = micros();
while( (micros() - m ) < us ){
NOP();
}
}
}

Even better, if "micros()" as inline in a header.

Rosimildo

[igrr]

The overflow being dealt with here is the overflow which happens when cycle count reaches UINT32_MAX. At 240MHz, this happens after 17 minutes of run time. So you suddenly get micros return something close to zero instead of something close to UINT32_MAX / 240.

[rosimildo]

Yes, I understand. But micros() is just a counter that rolls over. All arduinos implementation rolls over, eventually.

[igrr]

It does roll over, but it is supposed to do so after UINT32_MAX microseconds. There is a lot of code in Arduino which looks like this:

uint32_t start = micros();
while(!condition && micros() - start < timeout) {
  // do stuff
}

Note that this code pattern handles microseconds rollover (at UINT32_MAX) perfectly well. However it doesn't work correctly if microseconds will start rolling over at a smaller value (such as UINT32_MAX/240).

We had this early rollover issue in the ESP8266 Arduino core at some point, and I know that a fair number of libraries and sketches were broken because of this issue. Well, they only got broken after 53 minutes (80 MHz clock frequency), but that was an issue nevertheless.

I get the point that micros shouldn't take that much. In my previous tests, entering a critical section would take around 310 cycles (so slightly more than 1 microsecond).
If we add a constraint that all code which uses micros can only run on one CPU core, we can reduce the cost of critical section by a fair amount. If we don't add such a constraint, we have an optimization in ESP-IDF pipeline which reduces critical section cost to around 130 cycles.

[rosimildo]

Ok, I see. My code would work if each tick was a microsecond each. Maybe some timer should be set for that.

[me-no-dev]

@rosimildo I tested the current micros() and it came up to take 800ns per call. I made 1000 calls and measured the time.

[me-no-dev]

@rosimildo in your code above you actually measure cpu clock count and not microseconds. So 50 there means 50/F_CPU_MHZ microseconds

[me-no-dev]

I'm actually closing this because it's invalid ;) the actual code that runs micros() and delayMicroseconds() currently is fine and accounts for overflow and all.

[forthlightning]

How does the above code measure cpu clock count? It looks like it should be measuring micros?

I have not seen this constant before F_CPU_MHZ

[me-no-dev]

uint32_t ccount;
asm volatile ( "rsr %0, ccount" : "=a" (ccount) );
return ccount;

ccount -> Cycle Count ;) not micros

Defining the local statics lccount and overflow as arrays [NUM_CORES or XMP_MAX_CORES neither of which are currently included, but are both set to 4] = {0}; and using int core = xPortGetCoreID(); for the array access does improve performance once the critical section calls are removed. Not by much though, I see a constant 2 returned from the example in the opening post, and 1 or 2 with this change.

It's up to each core to record overflow though. But I'm keeping this change in my personal library, unless I've missed something important, which I'm sure someone will let me know about (I see loop fixes the overflow for one core only now, but there is 17 minutes available on the other core for that "fix" to not be required [and, besides, this is outside Arduino territory]).

[unixway]

Why you all think that you have 17 minutes till overflow when actually it is 17 seconds?

[comperem]

I get Delta streaming out 0's and 1's for microsecond times. OP must have had something else going on.

[peufeu2]

On ESP32, micros() takes about 150 cycles. delayMicroseconds() calls it at least twice. For example delayMicroseconds(2) takes 330 cycles, corresponding to a delay of more than 4µs, or double what was requested, when running at 80MHz to save power. To say it works is really stretching it.