前段时间在用ESP32开发一个简单的物联网门铃项目时,踩了一个超级郁闷的坑:GPIO中断配置后,系统响应居然延迟了上百毫秒!原本以为是硬件问题,折腾了整整两天,最后才发现是软件配置的锅,将来龙去脉和解决方案分享给大家,希望能帮到同样在用ESP32的兄弟们避坑。
用ESP32的GPIO2作为门铃按键输入,配置为中断触发(下降沿),一旦按下就通过WiFi发送通知到手机APP。开发环境是ESP-IDF v5.0,代码用C语言写。一开始,一切正常:我用gpio_install_isr_service(0)注册中断服务,然后gpio_isr_handler_add(GPIO_NUM_2, button_isr_handler, NULL)添加处理函数。测试时,按下按钮,中断能触发,LED灯能点亮,看起来没毛病。
但接入WiFi模块后,问题来了!按按钮的响应时间从原来的<10ms飙升到100-200ms,甚至偶尔卡顿到500ms。APP收到通知时,人早就走远了。调试过程如下:
先怀疑硬件:换了几个GPIO引脚(试了GPIO0、GPIO4),问题依旧;测了波形,信号干净无噪。
然后查WiFi:禁用WiFi模块,中断恢复正常。恩,指向网络栈干扰。
用示波器抓中断,确认中断本身没丢,但ISR handler执行时间变长了。从日志看,handler里加了个简单延时测试,都卡了。
最后,用FreeRTOS任务分析工具esp-idf的monitor,发现:中断优先级默认是高,但WiFi任务(默认优先级20)在抢占CPU,导致ISR被延迟调度。花了我两天时间,差点延误项目 deadline。最“开心”的是,官网文档里明明有提“WiFi and interrupts interaction”,但我当时只扫了一眼,没深挖。