ESP32 S2上MicroPython的sleep_us(1)为何实际延时远超1微秒？

你的操作没问题，这个结果偏差是MicroPython在ESP32平台上的正常现象，核心原因和说明如下：

为什么延时远大于1μs？ #

• sleep_us的底层精度限制：MicroPython在ESP32上依赖RTOS（实时操作系统）调度，sleep_us()的最小延时受系统时间片和硬件调度开销限制，根本做不到严格的1μs精度。ESP32的RTOS任务切换、唤醒本身就需要几十μs的时间，所以哪怕你传1μs参数，实际休眠时间也会远大于这个值。
• 代码额外开销占比大：你当前代码里的print(t)是串口输出操作，这是非常耗时的——哪怕用115200波特率，输出一个数字也需要几十μs，再加上循环判断、变量赋值的执行时间，这些都会被计入t的差值里。你测出来的105-120μs其实是sleep_us(1)+循环逻辑+串口打印的总耗时，并非sleep_us本身的休眠时间。
• 运行频率的影响：如果ESP32 S2没有运行在最高频率（比如默认80MHz，最高支持240MHz），代码执行速度会更慢，额外开销的占比会进一步放大，导致延时偏差更明显。

sleep_us并非毫无用处 #

它适合不需要严格微秒级精度，但需要短延时的场景：比如简单的硬件时序控制（只要误差在可接受范围内），或者用来降低频繁轮询的CPU占用率。如果确实需要严格的微秒级精度，得直接操作ESP32的硬件定时器或寄存器，MicroPython的高层API做不到这么细的粒度。

更准确测试sleep_us延时的方法 #

要排除串口打印的干扰，可以先批量记录延时数据，循环结束后再一次性输出：

from time import ticks_us, sleep_us
times = []
for i in range(100):
    t2 = ticks_us()
    sleep_us(1)
    t = ticks_us() - t2
    times.append(t)
print(f"最小延时: {min(times)}μs, 最大延时: {max(times)}μs")

这样测出来的结果会更接近sleep_us本身的实际延时，但依然达不到1μs，这是平台底层的固有限制。

内容的提问来源于stack exchange，提问作者aleXela