According to what I'm seeing in the Makefile, neither modtime.c nor extmod/utime_mphal.x are used in the CircuitPython version. Like @tannewt alluded to in Discord, a lot of the time.xxx functions in utime are not CPython compatible...which goes against one of the goals of CircuitPython.

I do think we'll need to figure something out though. With attempting to bring pulseio functions to the ESP8266 port (Issue #716), we'll most likely need some microsecond counting mechanism. Milliseconds just won't cut it...

So, I should have looked before, but I was pretty confident there are some timers available...

delay_us is available from microcontroller. There are some additional delay/tick functions available at the C level in esp_mphal...

@sommersoft, thanks for the feedback.

I see that microcontroller.delay_us is available, but it doesn't seem to work. That is, I would expect microcontroller.delay_us(1000000) to delay for 1 second, but it returns immediately. It's defined in terms of os_delay_us(), which I can't find anywhere.

I have the utime module working now; the necessary changes are here. I would be happy to submit this as a pull-request if it's the sort of thing people would like, but I'm not sure what CP thinks about the u* modules in general...

We're discussing in issue #519 about how and where to add more time functionality. @tannewt has suggested adding a precise_time module for functionality above and beyond time.

We are moving away from the u* modules in favor of more descriptive ones with a more consistent API. We either provide a subset of or the same functionality provided by a CPython module, or we come up with a new module that has its own API, not necessarily derivative in terms of naming

I wouldn't be surprised if os_delay_us had a maximum time it will wait. Precise microsecond timing is whole different beast to timing out a second. Microsecond timing can only be done reliably with interrupts off while second level timing can leave them on.

Even if we did provide a way to measure 10 microseconds, the actual delay would be longer due to the speed of the VM. It does given you a minimum delay though.

@tannewt while I understand your comments about timing accuracy, I will note that with the sleep_us function available, CircuitPython has no problem driving the TM1637 display.

Either the accuracy is "good enough" or the TM1637 is really lenient.

We won't be adding any extra functions to time that aren't in CPython. #519 covers CircuitPython specific options so closing this issue.