time.ticks_cpu() weird overflow on esp32

[0wwafa]

Port, board and/or hardware

esp32

MicroPython version

MicroPython v1.24.1 on 2024-11-29; Generic ESP32 module with ESP32

Reproduction

def test(x,freq):
   machine.freq(freq*1000000)
   s=time.ticks_cpu()
   time.sleep(x)
   d=time.ticks_diff(time.ticks_cpu(),s)
   if d<0: d+=1073741824 #ticks overflow at 2^30
   print(d/(freq*1000000))

Expected behaviour

it seems that time.ticks_cpu() is 30 bit signed.

it overflows at 1073741824 (2^30)

Observed behaviour

shouldn't it be 2^31 or just a 32 bit INT?

is there a reason for that?

because of this the maximum elapsed ticks measurable are:

53.6870912 seconds @ 20 Mhz
26.8435456 seconds @ 40 Mhz
13.4217728 seconds @ 80 Mhz
6.7108864 seconds @ 160 Mhz
4.47392426 seconds @ 240 Mhz

please if possible, express ticks as a 32 bit integer

Additional Information

No, I've provided everything above.

Code of Conduct

Yes, I agree

[mendenm]

the 30-bit format is required for the micropython 'small integer' that can be passed around without creating an object. That's why the ticks_diff() function exists, to automatically unwrap small overflows. You do have to be careful to call it with small enough differences that there is only one overflow.

[0wwafa]

That's why the ticks_diff()

as you can see in the code above, I used ticks_diff()... but still the overflow happens at 2^30.
since the cpu uses 32 bit integers, I don't understand the reason for this limitation... but ok.
IMHO, it should wrap at 0xFFFFFFFF.

[mendenm]

micropython stores small integers directly where ordinarily the pointer to an object would go, thus saving allocating a full object when an integer is of a suitable size. This makes handling 30 bit integers, which covers the most common cases, very fast. These are flagged by the high 2 bits being zero. It's an optimization.

I saw you used the ticks_diff. The reason I commented on it is that this abstracts away the funny wraparound. Incidentally, never try to use a regular integer with ticks_diff, other than the values pretty much directly returned by the ticks() functions. If you hand it a regular integer, which may have been created by other math, it could well be an object. In this case ticks_diff() will end up subtracting the pointer. The same is true for ticks_add(). These functions are intended to be fast, and waste no time checking the high bits. I got burned by this a year or two ago.