ESP32实战：从传感器到计分引擎，打造保龄球计分系统

很多做嵌入式开发的朋友问过我一个类似的问题ESP32 除了点灯、读温湿度、做个小车还能不能做一个“真正有点完整度”的项目其实这是一个被低估的误区。ESP32 从来不只是入门板它拥有双核 CPU、WiFi 蓝牙、丰富的外设和可扩展的 GPIO完全有能力承载一个包含实时检测、规则计算、无线上报和多状态切换的完整应用系统。保龄球计分系统就是一个非常典型的例子它看起来像“玩具项目”但真正做起来会把 GPIO 中断、信号去抖、任务调度、通信协议、计分状态机全部串在一起踩坑价值远超一个普通传感器 demo。这篇文章不是给你一份简单的“传感器接上去、串口打印数据”的教程而是完整讲清楚一个 ESP32 Bowling System 从硬件选型到计分引擎、再到无线展示的落地思路。读完你可以得到三样东西一套可复用的 ESP32 多任务项目结构一套带 Strike、Spare、第十格特殊规则的保龄球计分引擎实现以及一套从信号采集到远程展示的完整通信链路。如果你正准备做 ESP32 相关项目尤其是涉及“多个传感器 实时计分 手机/网页展示”这类组合这篇文章可以直接作为设计参考。1. 这篇文章真正要解决的问题保龄球计分系统听起来简单实际上存在三个非常现实的开发痛点这也是很多类似项目做一半就烂尾的原因。第一个痛点是传感器误触发。保龄球运动的特点是球速快、冲击大无论是红外对射检测球经过还是振动模块检测球瓶被击中信号都是毫秒级跳变而且伴随抖动和噪声。如果直接用 GPIO 读到高电平就去累加计数一次实际撞击可能被记录成两三次最终分数完全不可信。这个问题在真实球道和桌面迷你保龄球场景中都存在只是程度不同。第二个痛点是计分规则远比想象中复杂。保龄球不是“倒了几个瓶就加几分”这么简单。一局有 10 个计分格每一格最多可以投两次球如果第一球全中Strike该格得 10 分并追加后续两球的分数如果补中Spare该格得 10 分并追加后续一球的分数第 10 格如果出现 Strike 或 Spare 还要额外补投。这些规则叠在一起用一堆零散的 if 判断去写很容易在边界场景翻车。第三个痛点是嵌入式项目缺乏清晰分层。很多新手把传感器读取、去抖逻辑、业务计分、网络上报全部塞进一个loop()里导致改一个功能就要动全局。而 ESP32 的特性恰恰适合用“传感器层 - 业务层 - 通信层”的分层结构来解决这也是本文想传达的核心设计判断嵌入式项目复杂到一定程度状态机和分层比“代码能跑”更重要。所以这篇文章适合的人群很明确已经能独立点亮 ESP32、跑通过基础 Arduino 或 PlatformIO 程序但还没有完整做过一个“多传感器 规则引擎 无线交互”项目的开发者。如果你还在学习 ESP32 环境搭建也可以先从第 4 章开始跟跑。2. ESP32 Bowling System 的系统架构与核心原理在展开代码之前先明确这套系统的整体架构。一个保龄球计分系统按功能可以拆成四个层次。第一层是物理检测层。通常需要两类传感器一类负责检测“球已经出手通过起点”常用红外对射模块另一类负责检测“球瓶被击中”常用振动传感器、压电传感器或倾角开关。前者给计分流程一个明确的开始信号后者决定最终得分。如果要做更真实的桌面版本也可以在每个球瓶底部加独立传感器但那样 GPIO 开销会大很多第一版不建议。第二层是事件处理层。ESP32 的 GPIO 中断负责捕获边沿跳变去抖逻辑负责把有效事件和噪声区分开。这里要特别注意的是中断服务函数ISR里绝不能做耗时操作正确做法是“ISR 只置标志位主循环或专用任务负责处理”。这是嵌入式开发最基本的素养也是保龄球这类高速事件最容易犯错的地方。第三层是业务计分层。这一层维护一个完整的比赛状态机内部记录当前是第几格、这一格是第几次投球、是否已经 Strike 或 Spare、总分是多少。它对外只暴露一个简单的接口比如recordFall(count)内部自己处理所有规则。这样设计的好处是计分引擎可以被单独测试甚至可以在电脑上先用普通 C 验证再放进 ESP32极大减少调试痛苦。第四层是展示与上报层。ESP32 相比传统单片机的最大优势就在这里它自带 WiFi 和蓝牙可以通过 WebSocket 把实时比分推送到浏览器也可以通过 BLE 通知手机 App。本机还可以接一块 OLED 或 LCD 显示屏保证没有手机时也能看到分数。搜索关键词里频繁出现“蓝牙 app 控制 esp32”和“esp32 怎么在局域网内通讯”说明这是大家在真实项目里最关心的一环本文第 5 章会给出两种实现。再看选型对比。为什么是 ESP32而不是 Arduino Uno 或 STM32下表可以说明问题对比维度Arduino UnoSTM32 系列ESP32无线能力需要外接模块通常需要外接模块内置 WiFi BLE处理速度16MHz适合简单传感器较高双核 240MHz足够跑规则引擎开发门槛低较高需要熟悉 HAL/标准库低Arduino 与 ESP-IDF 都支持多任务能力弱中等原生 FreeRTOS社区资料与成本多但偏入门中等非常丰富开发板价格低从材料看这个项目选择 ESP32 的核心原因有三个一是保龄球系统天然需要“比分实时同步到手机或网页”ESP32 内置 WiFi/BLE 能省去大量外接模块工作二是双核架构可以把网络任务和传感器任务分开避免数据上报阻塞检测三是开发生态成熟寻找现成库和排查问题的成本都更低。3. 硬件选型与传感器方案这套系统用到的核心硬件可以分成四块主控、触发传感器、球瓶检测传感器、展示模块。下面给出一个参考方案具体型号可以根据手头物料灵活替换。主控选择 ESP32-WROOM-32 开发板即可这类板子引脚多、Flash 容量足够、价格实惠社区资料最丰富。如果你手头是 ESP32-S3也可以替换代码层面兼容性很好只需调整引脚配置和 Board 选项。触发传感器推荐红外对射模块。安装位置在球道起点两侧球体经过时切断红外光路模块输出一个低电平脉冲。相比超声波测距红外对射的响应速度更快不容易被球速影响。安装时要注意两个问题一是对射两端要尽量对齐二是环境光太强时会干扰接收端建议给接收管加遮光罩。球瓶检测传感器这是整个系统里最容易误触发的部分。常见方案有两种振动传感器贴在球瓶区下方球击中球瓶时产生振动模块输出高电平。优点是安装简单、成本低缺点是周围如果有其他振动源比如球滚过地板也会触发需要配合去抖和连续触发时间过滤。压电传感器利用压电陶瓷在受力时产生电压变化的特性灵敏度高、响应快。适合做桌面迷你保龄球能区分不同强度的冲击。第一版建议从振动传感器开始先跑通整个业务链路再根据误触发情况升级压电或其他方案。这里有个很重要的原则先让全流程转起来再追求检测精度。展示模块本机展示可以用 0.96 寸 OLEDSSD1306或 1.3 寸 LCD远程展示用手机或电脑浏览器即可ESP32 侧只需要提供 Web 页面和 WebSocket 接口。下面这张引脚分配表是我建议的第一版方案注意避开 ESP32 的输入专用引脚和 Flash 占用引脚功能推荐引脚说明红外对射输出GPIO 14球出手时产生下降沿振动传感器输出GPIO 27球瓶倒下时产生上升沿OLED SCLGPIO 22I2C 时钟线OLED SDAGPIO 21I2C 数据线系统 LEDGPIO 2状态指示特别提醒ESP32 的 GPIO 6、7、8、9、10、11 连接板载 Flash不能当普通 IO 使用。很多新手第一次画引脚分配表时踩这个坑程序烧录进去后行为完全不可控。另外所有传感器和主控之间建议共地否则信号电平会漂移导致中断频繁误触发。4. 开发环境搭建与基础工程结构开发 ESP32 有两种主流方式Arduino IDE 和 PlatformIO。如果你的项目只涉及简单的传感器读取Arduino IDE 足够但像本文这种包含多任务、库依赖和版本管理的项目我更推荐 PlatformIO。原因有三依赖清晰、编译配置可写进工程文件、换电脑后不需要重新配置一堆 Board 选项。4.1 使用 Arduino IDE 搭建 ESP32 环境Arduino IDE 搭建 ESP32 环境的通用做法是打开“文件 - 首选项 - 附加开发板管理器网址”填入 ESP32 官方维护的 JSON 地址然后在“开发板管理器”中搜索 ESP32 并安装。具体 JSON 地址建议以官方仓库最新文档为准。安装完成后在“工具 - 开发板”中选择你的板卡型号例如ESP32 Dev Module波特率选择 115200就可以编译烧录了。如果下载开发板包时经常失败可以找一个包含 ESP32 离线包的镜像资源手动放置到 Arduino15 目录下或者直接切换到 PlatformIO后者在依赖下载上通常更稳定。4.2 使用 PlatformIO 创建工程PlatformIO 更适合本文的工程化写法。创建工程后在项目根目录打开platformio.ini写入如下配置[env:esp32dev] platform espressif32 board esp32dev framework arduino monitor_speed 115200 build_flags -D CORE_DEBUG_LEVEL3 lib_deps bblanchon/ArduinoJson ^6.21.3 me-no-dev/ESP Async WebServer ^1.2.4 me-no-dev/AsyncTCP adafruit/Adafruit SSD1306 ^2.5.7 adafruit/Adafruit GFX Library ^1.11.5这份配置里包含三个关键点board esp32dev对应常见的 ESP32-WROOM-32 开发板lib_deps自动拉取 WebSocket/Async WebServer 和 OLED 驱动依赖CORE_DEBUG_LEVEL3开启详细调试日志方便排查问题。如果你用的是 ESP32-S3把board改成esp32-s3-devkitc-1即可。工程目录结构建议按职责拆分bowling-system/ ├── platformio.ini ├── include/ │ └── config.h // 引脚、WiFi、传感器参数 ├── src/ │ ├── main.cpp // 入口负责初始化和任务创建 │ ├── SensorEvents.cpp │ ├── ScoringEngine.cpp │ └── WebServer.cpp └── lib/ └── ...这种结构的价值在于Pin 配置集中在一个头文件里换板子只需要改一处传感器事件、计分引擎、Web 服务各管各的模块任何一个模块都能单独修改和测试。5. 核心代码实现从传感器到比分的完整链路这一章是全文的核心。我会按事件采集、计分引擎、远程上报三个模块逐个拆解。这三个模块分别解决“如何可靠地感知”“如何正确地算分”“如何实时地展示”串联起来就是完整的最小可用系统。5.1 传感器事件采集中断与去抖先看传感器采集层。设计目标很明确球经过红外对射时产生一次下降沿触发球瓶被击中时产生一次上升沿触发两次触发之间必须满足去抖时间才能被当作有效事件。下面代码展示了如何用 ESP32 的 GPIO 中断 去抖计时实现可靠的传感器事件采集。// 文件路径src/SensorEvents.cpp #include Arduino.h #include config.h static volatile bool ballPassed false; static volatile bool pinsFallen false; static unsigned long lastBallEvent 0; static unsigned long lastPinEvent 0; // 红外对射触发球经过起点记录“本回合已经开始” void IRAM_ATTR onBallPass() { unsigned long now millis(); if (now - lastBallEvent 300) { // 300ms 去抖 ballPassed true; lastBallEvent now; } } // 振动传感器触发球瓶被击中记录“有球瓶倒下” void IRAM_ATTR onPinImpact() { unsigned long now millis(); if (now - lastPinEvent 500) { // 500ms 去抖过滤连续抖动 pinsFallen true; lastPinEvent now; } } void SensorEvents_begin() { pinMode(PIN_BALL_TRIGGER, INPUT_PULLUP); pinMode(PIN_PIN_SENSOR, INPUT_PULLUP); attachInterrupt(digitalPinToInterrupt(PIN_BALL_TRIGGER), onBallPass, FALLING); attachInterrupt(digitalPinToInterrupt(PIN_PIN_SENSOR), onPinImpact, RISING); } bool SensorEvents_consumeBallPass() { bool v ballPassed; ballPassed false; return v; } bool SensorEvents_consumePinImpact() { bool v pinsFallen; pinsFallen false; return v; }这段代码里有两个关键设计。第一个是IRAM_ATTR修饰符这是 ESP32 中断服务函数的硬性要求。ESP32 的默认代码运行在 Flash 上而 Flash 读取在中断上下文中有不可控延迟必须把 ISR 放在内部 RAM 中才能保证响应速度。如果不加这个修饰符程序可能在中断触发瞬间崩溃或复位。第二个是“消费模式”。ISR 里只设置标志位主流程通过consumeBallPass()和consumePinImpact()读取并清除标志位。这种生产者-消费者模式可以避免中断和主循环共享复杂变量也方便在标志位之外扩展时间戳、计数等附加信息。真正容易踩坑的是去抖时间不能一刀切。红外对射信号干净300ms 足够振动传感器受安装环境影响大如果还有持续余振就需要把去抖时间调大或者连续检测到多次触发才认为有效。5.2 保龄球计分引擎状态机与完整规则接下来是最需要耐心的部分计分引擎。我强烈建议先把这部分在 PC 上用普通 C 写一遍并加单测确认规则正确后再移植到 ESP32。原因是保龄球计分规则的边界情况很多如果在嵌入式环境里调试每次烧录都要花时间效率太低。先看核心数据结构。一局保龄球有 10 个 Frame每个 Frame 有两次投球机会Strike 时只用一次Spare 比 Strike 多一个“追加一球”的规则第 10 格还有特殊补投规则。// 文件路径lib/ScoringEngine/ScoringEngine.h #pragma once #include Arduino.h struct Frame { uint8_t firstRoll 0; uint8_t secondRoll 0; bool isStrike false; bool isSpare false; bool closed false; // 当前 Frame 是否已结束 }; class ScoringEngine { public: void start(); void recordFall(uint8_t count); // 每次球停后调用 uint16_t getTotalScore(); uint8_t getCurrentFrame(); bool isGameOver(); private: Frame frames[10]; uint8_t currentFrame 0; // 0-9 uint8_t rollInFrame 0; // 0 或 1 bool gameOver false; uint16_t scoreAt(uint8_t frameIndex, uint8_t next1, uint8_t next2); };这个类的关键是recordFall(count)方法。它接收“本次球倒下的瓶数”内部根据当前 Frame 状态更新数据。Strike 的判断是第一次投球就击倒 10 个Spare 的判断是第二次投球后累计击倒 10 个普通 Frame 的两次投球累计不足 10 个时这一格就关闭。接下来是计分逻辑。保龄球计分的核心是“延迟计算”Strike 的得分依赖后续两球Spare 的得分依赖后续一球所以不能在当前 Frame 结束时立刻把总分算死必须等后续投球结果出来后再回填。// 文件路径lib/ScoringEngine/ScoringEngine.cpp #include ScoringEngine.h void ScoringEngine::start() { for (int i 0; i 10; i) { frames[i] Frame(); } currentFrame 0; rollInFrame 0; gameOver false; } void ScoringEngine::recordFall(uint8_t count) { if (gameOver) return; Frame f frames[currentFrame]; if (rollInFrame 0) { f.firstRoll count; if (count 10) { f.isStrike true; f.closed true; if (currentFrame 9) { // 第 10 格 Strike 需要保留补投状态 rollInFrame 1; // 这里用 rollInFrame 表示补投次数 } else { moveToNextFrame(); } } else { rollInFrame 1; } } else if (rollInFrame 1) { f.secondRoll count; f.closed true; if (f.firstRoll count 10) { f.isSpare true; } if (currentFrame 9 (f.isStrike || f.isSpare)) { rollInFrame 2; // 第十格补投第二球 } else { moveToNextFrame(); } } else if (rollInFrame 2) { // 第十格 Strike/Spare 后的额外补球 if (rollInFrame 2) { // 补投记入一个额外字段简化处理 } f.closed true; gameOver true; } } void ScoringEngine::moveToNextFrame() { if (currentFrame 9) { currentFrame; rollInFrame 0; } else { gameOver true; } }严格来说第十格的“补投”需要单独存储才能算出完整准确的总分。上面代码做了一个简化处理只保留补投的存在状态没有把补投的瓶数记录进独立字段。在真实项目中建议给第 10 格再加thirdRoll字段否则 Strike 后补投的分数无法计入总分。这个边界正好是保龄球计分里最容易被人忽略的地方新手写到这里通常会发现“为什么第 10 格全中后总分不对”。下面的scoreAt负责计算某一个 Frame 的实际得分。它需要读取后续一球或两球的数据因为 Strike 和 Spare 的加分依赖后续投球。uint16_t ScoringEngine::scoreAt(uint8_t i) { Frame f frames[i]; uint16_t base f.firstRoll f.secondRoll; if (f.isStrike) { uint8_t bonus1 0, bonus2 0; if (i 9) { bonus1 frames[i 1].firstRoll; if (frames[i 1].isStrike i 1 9) { bonus2 frames[i 2].firstRoll; } else { bonus2 frames[i 1].secondRoll; } } else { // 第十格 Strike 的补投分别记入 firstRoll/secondRoll bonus1 frames[i].secondRoll; bonus2 frames[i].thirdRoll; } return 10 bonus1 bonus2; } if (f.isSpare) { uint8_t bonus1 0; if (i 9) { bonus1 frames[i 1].firstRoll; } else { bonus1 frames[i].thirdRoll; } return 10 bonus1; } return base; }这个函数有一个隐含假设thirdRoll字段在普通 Frame 中为 0只在第 10 格有效。实际写的时候需要把结构体补上uint8_t thirdRoll并初始化。另外scoreAt依赖后续 Frame 的数据所以汇总总分时不能只遍历一次就输出最终值更稳妥的做法是先等待当前可得的分数数据闭合并逐格累加或者每次调用时重新计算所有已关闭 Frame 的分数之和。5.3 数据上报局域网 WebSocket 推送比分传感器数据采集和计分引擎都就绪后下一步是把比分实时推送到浏览器或手机。这里使用ESP Async WebServer库它基于 AsyncTCP能够在异步回调里处理多个客户端连接不用在业务流程里等待网络发送完成。这种方式非常适合保龄球场景比分变化时需要同时广播给多个观众设备而且不能因为网络慢而阻塞传感器中断处理。下面是一个最小可用的 WebSocket 上报实现。// 文件路径src/WebServer.cpp #include Arduino.h #include WiFi.h #include ESPAsyncWebServer.h #include ArduinoJson.h #include config.h static AsyncWebServer server(80); static AsyncWebSocket ws(/ws); void notifyClients(uint16_t totalScore, uint8_t currentFrame) { StaticJsonDocument128 doc; doc[type] score; doc[total] totalScore; doc[frame] currentFrame; char buffer[128]; size_t len serializeJson(doc, buffer); ws.textAll(buffer, len); } void WebServer_begin() { WiFi.mode(WIFI_STA); WiFi.begin(WIFI_SSID, WIFI_PASSWORD); while (WiFi.status() ! WL_CONNECTED) { delay(500); Serial.print(.); } Serial.print(\nWiFi connected, IP: ); Serial.println(WiFi.localIP()); ws.onEvent([](AsyncWebSocket *server, AsyncWebSocketClient *client, AwsEventType type, void *arg, uint8_t *data, size_t len) { if (type WS_EVT_CONNECT) { Serial.printf(Client connected: %u\n, client-id()); } }); server.addHandler(ws); server.begin(); }这个模块只做三件事连接 WiFi、注册 WebSocket 路由、提供notifyClients广播函数。StaticJsonDocument用于序列化 JSON 数据体积小且不会产生堆碎片适合嵌入式环境。在main.cpp里只需要在检测到球瓶倒下事件后调用recordFall()更新计分再调用notifyClients()广播即可。这样整个链路就是传感器中断 - 主循环消费标志位 - 计分引擎更新状态 - WebSocket 推送比分 - 浏览器实时刷新。如果你的目标终端是手机 App 而不是浏览器也可以用 ESP32 的 BLE 能力实现同样的上报逻辑。定义一个自定义 Service 和 Characteristic比分变化时调用notify发送给已连接的手机。BLE 方案的优点是手机可以直接通过低功耗蓝牙接收不需要依赖路由器局域网缺点是开发稍复杂且 BLE 广播速率不如 WiFi WebSocket。实际项目二选一即可如果只是演示和测试WebSocket 更省事。6. 运行验证与效果检查代码写完后如何确认整个系统真的可用建议按下面的顺序做验证每步都在串口日志和实际行为上留下可观察的依据。先验证传感器链路。烧录程序后打开串口监视器用手快速划过红外对射模块观察串口是否打印类似ball passed的事件再轻敲振动传感器观察是否打印pin impact。这里的验证标准是每次触发恰好打印一条日志连续快速触发也不会丢失。如果一次触发打印多条说明去抖时间不够或传感器输出信号本身有多次跳变如果完全不打印先检查引脚连接、共地和中断触发边沿是否配置正确。再验证计分引擎。程序里内置一个测试模式模拟一局投球序列例如[10, 10, 10, 7, 3, 8, 2, 0, 9, 10, 10, 10, 8, 1]打印每个 Frame 的累计分和总分。保龄球计分有标准答案拿标准答案去对引擎输出一致就说明规则实现正确。这里强烈建议在 PC 上先用本地测试脚本跑一遍标准序列不要直接在 ESP32 上反复烧录调试。最后验证网络上报。手机或电脑连接同一个 WiFi浏览器访问 ESP32 打印出的 IP 地址打开 WebSocket 页面。之后触发一次球瓶撞击事件页面上的比分应实时变化。如果页面不更新先确认 ESP32 的串口日志里有没有Client connected没有就检查 WiFi SSID/密码和服务端端口有就检查 WebSocket 事件回调里有没有正确调用广播函数。下面的表格汇总了常见的失败现象和排查方向问题现象可能原因排查方式解决方案串口无任何输出引脚接错或未共地检查接线、用万用表量电平重新接线确保传感器与 ESP32 共地一次触发记录多次去抖时间过短查看串口事件时间戳增大去抖时间或加连续触发计数中断导致系统重启ISR 未加IRAM_ATTR查看重启栈回溯给 ISR 加IRAM_ATTRWiFi 连接失败SSID 或密码错误查看连接日志核对配置换成 2.4G 网络页面收不到比分WebSocket 未连接查看串口 Client connected检查 WiFi 和端口确认广播函数被调用第 10 格总分不对未处理补投字段用标准序列跑引擎测试补充thirdRoll并重算7. 常见问题与排查思路这一节把上一章表格里的典型问题展开讲因为这些问题在 ESP32 项目中重复出现率实在太高。问题一振动传感器误触发。表现是球还没碰到球瓶比分已经变了。原因是振动传感器灵敏度太高球滚过地板、设备桌面被触碰甚至远处关门都会被检测到。处理思路有两种一是物理上去耦比如在传感器和球瓶区之间加缓冲材料二是算法上过滤连续多次触发才认为有效或者设置一个“球出手后 X 秒内”才接受撞击事件的时间窗即用红外对射作为启动闸门窗口期内才统计撞击。问题二传感器事件丢失。表现是球明明撞了球瓶系统无反应。多数原因是 ISR 里处理时间过长或者主循环正忙于执行delay()、网络发送等阻塞操作。ESP32 虽然主频高但delay()也会让主循环暂停此时如果中断标志位没有被及时消费后续事件标志位可能被新的值覆盖。解决办法是使用 FreeRTOS 队列或环形缓冲区来暂存事件而不是简单的布尔标志位。问题三WiFi 连接和局域网访问不稳定。很多人在室内测试时发现 WebSocket 经常断连尤其 ESP32 和路由器距离较远时。可以精简为三步优先连接 2.4G 频段ESP32 不支持 5G给 ESP32 分配固定 IP避免每次重连 IP 变化导致页面访问失败在 WebSocket 回调里增加重连逻辑客户端断开后自动重试。问题四烧录失败或反复重启。这在 ESP32 项目中很常见。第一个原因是开发板选择错误比如烧录 ESP32-S3 却选了 ESP32 Dev Module会报连接失败或 Flash 错误第二个原因是编译期间串口被其他程序占用第三个原因是电源不足ESP32 在 WiFi 发射瞬间电流会冲到几百毫安USB 线质量不好或供电不足会导致反复重启。排查顺序是“换开发板选项 - 检查串口占用 - 换电源和线材”。问题五计分引擎边界错误。比如第 10 格 Strike 后总分偏小或者 Spare 判定失败。这类问题最容易通过“标准序列测试”暴露。建议在ScoringEngine里加一个injectRoll测试方法写一个 PC 端测试用例把保龄球官方计分示例逐条跑一遍。8. 最佳实践与工程建议前面几章把系统讲通了下面这些工程建议是在真实项目中反复验证过的经验值得收藏后逐条对照。第一ISR 里只做“置位”不做“处理”。这是一个纪律性问题。很多人觉得 ISR 里多写一行判断没事但 ESP32 的中断优先级、Flash 访问和 FreeRTOS 调度互相作用一旦 ISR 里调用Serial.println或delay轻则丢事件重则触发看门狗复位。所有数据处理都放到主循环或独立任务里。第二用状态机而不是散落的 if。保龄球系统的状态包括等待球出手、等待球瓶倒下、等待下一格、比赛结束。用一个枚举状态变量和状态转换函数来管理比在loop()里堆条件判断清晰得多。每个状态只处理当前允许的事件非法事件直接忽略这样系统不会因为异常时序进入坏状态。第三重视日志和可观测性。嵌入式项目调试最痛苦的时刻就是“系统好像坏了但不知道坏在哪一步”。建议在关键事件处打印带时间戳的日志比如[1423ms] Ball passed、[1650ms] Pin impact count7。这些日志不仅是调试工具也是后续调参的依据。CORE_DEBUG_LEVEL3可以帮助打开 ESP32 内部日志但业务日志也要自己加。第四电源与硬件可靠性。保龄球系统往往运行在有人走动、有电机或电磁阀振动的环境中。给 ESP32 供电建议用 5V/2A 以上电源避免用电脑 USB 口长期供电传感器信号线尽量短必要时用屏蔽线如果传感器和主控距离超过 30cm建议用带差分输出的传感器或增加光耦隔离避免信号衰减和共模干扰。第五计分引擎与硬件解耦。整个项目里最值得单独测试的就是计分引擎。它不依赖 Arduino 任何库完全可以在电脑上用 C 标准库编译运行。把引擎独立出来后业务逻辑可以在 CI 里做自动化测试而 ESP32 侧只需要调用几个简单接口。这是嵌入式项目少“返工”的关键习惯。第六预留 OTA 和配置管理能力。如果这个系统要长期放在球馆使用烧录一次后就再无更新能力会很痛苦。建议在项目早期就加入 ESP32 OTA 升级能力同时把 WiFi 账号、传感器灵敏度等参数放到一个config.h或配置文件中统一管理。不要在多个源文件里直接写死参数否则后期换一套传感器就要全项目搜索替换。第七安全与合法使用提醒。保龄球系统如果被用于商业场所要注意传感器安装方式不能影响球道安全所有接线必须固定好避免绊倒人员。涉及远程访问时不要把 Web 服务直接暴露到公网尽量限制在局域网内并给管理页面加上简单密码认证。任何涉及生产环境的操作都要先在测试环境验证并做好回滚准备。9. 总结与后续学习方向这篇技术文章完整拆解了一个 ESP32 Bowling System 的最小实现用红外对射和振动传感器感知球与球瓶用状态机驱动的计分引擎处理保龄球规则再用 WebSocket 把比分实时推送到浏览器。整个链路把 ESP32 的 GPIO 中断、去抖算法、业务状态机和 WiFi 通信全部串了起来这正是嵌入式项目从 demo 走向“完整系统”最需要的能力。我建议你按下面的顺序实践第一步先在不接传感器的情况下把计分引擎单独跑通标准测试序列第二步接上红外对射和振动传感器在串口里验证事件采集可靠性第三步把 WebSocket 上报加上用手机浏览器看实时比分最后再逐步优化传感器精度和界面体验。每一步都有明确的验证标准不会出现“代码写完却不知道对不对”的情况。如果你对后续方向感兴趣可以继续深入这几个主题用 FreeRTOS 队列替代简单的布尔标志位解决高频率事件丢失问题为第 10 格增加完整的thirdRoll计分支持把 Web 页面升级为移动端友好的实时看板加入多球道数据采集让一个 ESP32 作为服务器接收多台设备的比分上报也可以研究 PIR、激光雷达或摄像头视觉方案替代振动传感器从根本上解决误触发问题。保龄球系统只是一个载体它背后的套路——中断采集、状态机、规则引擎、无线上报——几乎可以平移到你接下来要做的任何 ESP32 项目中。建议收藏本文下次做类似项目时按这个分层结构来设计能少踩很多坑。