我最近把普中 STM32F103 开发板重新拿出来做了一个“精灵”智能井盖项目。目的不是简单地驱动几个模块点灯而是把一套完整的物联网终端链路走通井盖状态感知、环境气体监测、水浸预警、低功耗处理、远程数据上报。这块开发板在很多人的桌面上已经吃了很久灰但做智能井盖这种终端设备的原型验证它反而比直接上一颗高集成 SoC 更顺手。这篇文章会按实际落地顺序拆开讲适合有 C 语言基础、想用 STM32F103 把传感器采集、低功耗、串口通信和无线模块串成一条链路的人。先说我最直观的判断STM32F103 做智能井盖能不能跑通不是问题真正的问题有三个——低功耗状态下能不能被正确唤醒多种传感器的数据能不能稳定汇聚上报链路在长时间无人干预时会不会掉线。这三点会贯穿整个项目下面逐步展开。1. 智能井盖项目的需求拆解先想清楚采集什么、上报什么很多初学者拿到“智能井盖”第一反应是“用倾斜传感器检测有没有翻盖”然后把 GPIO 电平读回来就完事。可以跑通但距离实际场景还很远。1.1 井盖监测场景里的四类核心状态一套真正能演示、能扩展的智能井盖终端至少要覆盖四类状态第一类是井盖本体状态。比如井盖有没有被非法打开、有没有发生移位、长时间倾斜是否异常。这类状态在硬件上可以用常闭触点开关、倾斜开关、干簧管或加速度传感器来检测。演示项目里用 GPIO 外部中断读取数字电平就够了原因是事件发生具有突变性轮询会漏掉瞬时状态。第二类是井内环境状态。城市排水井、燃气井、电力井里容易出现可燃气体积聚或水位上升所以一般要采集气体浓度和水浸信号。气体传感器输出通常是模拟量必须经过 ADC 采样不能只当数字量看。第三类是位置信息。如果井盖被移动平台需要知道它从哪个位置被搬走否则只报“开盖”没有处置价值。实战中会用 GPS/北斗模块或 NB-IoT 基站定位学习阶段可以先在报文里预留经纬度字段。第四类是设备运行状态。比如电池电压、信号强度、最近一次上报时间。看不到这些信息远程维护基本靠猜。1.2 井盖终端的数据链路要先于硬件确定我建议把这些状态分类整理成一张字段表再做硬件选型。报文设计成 JSON 会让后续云平台解析非常省事例如{ device_id: MANHOLE_001, status: closed, tilt: 0, gas_raw: 820, water: 0, bat: 3.92, signal: 18, ts: 1719651200 }这样每个字段都对应一个明确硬件输入。如果报文只有“0”和“1”后面排查问题会非常痛苦因为你不知道井盖是处于“关闭”还是“传感器没接好”。2. 硬件选型与模块接线普中板只是主控外设供电才是风险点普中 STM32F103 开发板通常是学习型开发板集成了板载 LED、按键、USB 转串口等资源。用它做智能井盖原型时建议把板载的 3.3V、5V、GND 和串口引脚引出来整体按外部模块规划。2.1 开盖和移位检测倾斜开关、干簧管还是加速度计三种方案各有适用场景干簧管配合磁铁成本最低井盖闭合时磁铁靠近干簧管回路导通开盖后断开。适合金属井盖但对安装位置要求严格。倾斜开关/滚珠开关检测角度变化。井盖被掀起时角度明显变化容易触发。加速度计如 MPU6050能输出三轴角度可以区分“正常开盖维护”和“小幅扰动”但驱动和数据处理更复杂会占用 I2C 资源和定时器。学习阶段我建议用干簧管或倾斜开关加外部中断。给每个传感器一个明确的上拉或下拉配置保证在没有触发时 GPIO 是高电平或低电平稳定状态。实测中很多人把引脚悬空导致中断误触发井盖没动却有上百条上报记录。2.2 气体和水浸检测模拟量与数字量要分开接可燃气体传感器MQ-2、MQ-4 这类通常需要加热电阻模块上会集成比较器输出 DO 数字量同时暴露 AO 模拟量。不要只接 DO 口因为比较器的阈值不可调现场环境一变化就会误报或漏报。正确做法是把 AO 接到 STM32F103 的 ADC 引脚通过定时采样读取原始值再在程序里做阈值判断。水浸传感器可以采用带探针的模块输出数字量同时也可以用 ADC 看出“轻微潮湿”和“完全浸水”的差异。实际井内环境复杂探头表面容易有污物建议用 ADC 值变化判断不要只看高低电平。常用 GPIO 分配示例功能模块STM32F103 引脚信号类型使用外设倾斜/开盖检测PB0数字量中断输入EXTI0水浸检测PA4ADC 模拟输入ADC1_IN4可燃气体 AOPA5ADC 模拟输入ADC1_IN5LCD/OLED I2CPB8/PB9I2CI2C1通信模块 UARTPA2/PA3串口USART2调试串口PA9/PA10串口USART1电池电压检测PA6ADC 模拟输入ADC1_IN62.3 电源方案要按“三个月无人维护”倒推功耗普中开发板本身带 USB 转串口直接 USB 供电开发没有任何问题。但智能井盖是电池供电场景实际部署时考虑的目标是“静态电流微安级上报瞬间几十毫安”。普通锂电池经过 AMS1117 给 STM32F103 供电AMS1117 自身静态电流就有几毫安哪怕主控进入 STOP 模式也会被电源芯片拖垮这是很多人做完发现电池几天没电的根本原因。所以项目演示阶段不要把低功耗优化当成唯一目标。如果你的模块只是“跑通数据链路”用 USB 供电很合理如果想验证电池续航要单独做一块低功耗电源板或者把 STM32F103 的核心板最小化配合低静态电流的 LDO 或 DCDC。3. 用 STM32CubeMX 初始化工程时钟、串口、GPIO 不能只走默认配置开发环境建议直接用 STM32CubeMX 生成 HAL 库工程IDE 用 Keil MDK 或 STM32CubeIDE 都可以。普中 STM32F103 板载芯片多为 ZET6 或 C8T6配置时一定要先确认芯片具体型号选错了引脚定义会乱。3.1 时钟树和调试接口配置STM32F103 最大主频 72MHz外部晶振通常是 8MHz。在 STM32CubeMX 的 Clock Configuration 里直接把 HSE 设为 Crystal/Ceramic Resonator然后倍频到 72MHz。有一点容易踩坑如果 SWD 下载口和传感器共用了引脚代码下载一次后第二次可能就找不到芯片。尤其做外部中断或 ADC 实验时尽量避开 PA13、PA14、PA15、PB3、PB4 这些调试复用脚。3.2 GPIO 初始化里的电平配置细节配置外部中断输入引脚时要区分模块输出类型不能全部照搬默认下拉或上拉。以干簧管传感器为例如果传感器闭合接地、断开悬空GPIO 就要配置为上拉输入如果传感器输出高电平表示触发则配置为下拉输入或直接读取电平。我踩过比较多的坑是在 STM32CubeMX 中选了“Falling edge trigger interrupt”但实际信号是传感器从高到低变化时触发。先拿万用表量一下模块输出电平再决定上升沿还是下降沿触发不要凭经验猜。3.3 ADC 采样建议配置扫描加 DMA智能井盖里模拟量不止一路。气体传感器、水浸传感器、电池电压都要采集。单路阻塞式 ADC 在实时性要求不高的项目里可以接受但最佳实践是开启 ADC 扫描模式加 DMA把所有模拟通道放在一个序列里连续采集。DMA 启动后ADC 会自动把样本搬运到内存数组CPU 只需要在任务循环里读取数组。这能减少很多中断处理负担。关于 DMA 的通道选择不同 STM32F103 型号略有差异CubeMX 里勾选后会自动生成不需要硬背。4. 关键功能实现外部中断、多路模拟量和低功耗唤醒流程配置好基础工程后核心逻辑就是井盖状态机。状态机包含正常运行、告警上报、低功耗睡眠、唤醒判定四个阶段。4.1 开关盖检测外部中断唤醒后延迟确认实际开井盖维护时工人动作很快从打开到合上可能只有几秒。如果唤醒后立即上报一次开盖再上报一次合盖平台会产生大量无效工单。比较好的做法是检测到中断后先进入防抖计时时长设为 2 到 5 秒防抖结束后读取 GPIO 电平确认状态确实变化再通过串口或状态灯指示事件发生如果需要上报先记录事件等通信模块模块上电后统一发送。防抖代码的核心逻辑可参照下面的伪代码框架void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin TILT_Pin) { tilt_pending 1; HAL_Delay(50); // 简单消抖 tilt_level HAL_GPIO_ReadPin(TILT_PORT, TILT_Pin); if (tilt_pending) { // 记录事件而不是立即发送 append_sensor_record(EVENT_OPENED, tilt_level); __HAL_PWR_CLEAR_FLAG(PWR_FLAG_WU); HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI); } } }注意不要在中断回调里做太长耗时操作不要在中断回调里直接驱动通信模块。把它们放在主循环里统一调度会更稳定。4.2 低功耗模式STOP 模式 RTC 闹钟 外部中断STM32F103 的低功耗模式有 SLEEP、STOP 和 STANDBY 三种。智能井盖最合适的是 STOP 模式STANDBY 功耗最低但是唤醒后程序从头运行相当于复位。如果对实时性要求高或需要保存运行状态会麻烦。STOP 模式唤醒后能继续执行寄存器内容大部分保留Flash 不掉电对于状态机更友好。进入 STOP 模式前要做几件事关闭不用的外设时钟尤其是 ADC、DAC、定时器。把串口发送完成标志确认完毕避免唤醒后串口卡死。把传感器供电引脚拉低让外设模块断电。配置 RTC 闹钟定期唤醒设备进行周期性采数和上报。配置外部中断引脚作为开盖唤醒源保证事件发生时能立刻醒来。如果配置完 STOP 模式后发现电流还是居高不下先用排除法把所有外设模块从板子上拔掉只保留最小核心板和一块微安表看基础电流是多少然后逐一挂载外设观察哪一级电流跳变最明显。这个排查流程比反复看代码省时间得多。4.3 RTC 外部晶振不起振怎么办RTC 使用 32.768kHz 外部晶振时经常出现一个现象CubeMX 配置没问题但初始化卡死或读取时间永远不变。原因通常是晶振的负载电容不匹配或者 OS 引脚上的寄生电容干扰了振荡器。如果确实起振困难有一个稍微牺牲时间的替代方案使用 LSI 内部低速时钟驱动 RTC。LSI 精度不高长时间运行会有累积误差但作为十分钟级别的周期唤醒基本够用。产品化时还是应该选质量稳定的外部晶振并把 PCB 布局处理好只是原型阶段不要被这个问题卡太久。5. 通信模块接入AT 指令和报文传输的坑比传感器更值得关注智能井盖终端的第二个核心是通信。常见通信手段有 NB-IoT、4G Cat.1、LoRa 和 WiFi。学习阶段最容易使用的是 WiFi 串口透传模块或 NB-IoT 模组它们都能通过 AT 指令完成联网和数据上报。5.1 串口资源分配和波特率稳定性STM32F103 有多路 USART但很多型号的低密度芯片串口资源有限。开发调试用 USART1 连接板载 USB 转串口用 USART2 连接通信模块用 USART3 留作 GPS 或其它传感器扩展。通信模块的波特率建议单独固定不要和调试串口相同。如果所有数据都混在同一个终端窗口里模块返回的 URC 上报和你的调试日志会来回交错很难看。AT 指令交互时要注意模块初始化完成后可能有不定长数据上报例如信号塔注册成功、网络附着成功等提示。代码必须把串口接收做成环形缓冲或 DMA 接收不能简单读一个字节处理一个否则长 AT 响应会溢出。5.2 数据上云方式MQTT over TCP 是更现成的选择传统 TCP 私有协议要自己设计报文序号、重传、丢包补偿HTTP 上报在无线网络下响应可能不及时且功耗较高。现阶段较多平台支持 MQTTNB-IoT 模块也会支持 MQTT因此建议项目采用 MQTT over TCP/\TLS。设备数据上云的典型流程通过指令查询 IMSI/IMEI等待模组注册网络成功如果平台要求 MQTT需要设置接入点域名和端口客户端 ID 使用设备唯一标识如设备 IMEI 或自定义 device_idQoS 设为 1保证消息至少到达一次每一条上报消息预留消息 ID 字段。如果你用某类平台的公共物联网云服务要注意服务端会为每个设备分配密钥鉴权。生产环境里密钥必须放在 Flash 独立扇区不能烧满整个 Flash 然后每次写入都把整片擦除那样掉电写入很容易损坏配置数据。5.3 通信模块的“假死”和看门狗策略无线模块最麻烦的问题不是连不上而是运行一段时间后收不到任何响应。这个现象在 NB-IoT 弱覆盖区域尤其频繁。模块本身没损坏但协议栈卡死TCP 连接处于半开状态。处理办法有两个层面应用层层面每 N 次上报后让主控重新拉高模块复位引脚执行硬复位系统层面启用独立看门狗 IWDG主循环每隔一段较长时间未完成任务就喂狗超时系统自动复位。实测最稳定的组合是串口 AT 指令发送 5 秒无应答就判定模块异常累计 3 次异常后拉低复位引脚 100ms再等待模块冷启动完成。不要在每次上报失败后立刻复位模块一来功耗高二来可能错过网络恢复。6. 实测踩坑记录GPIO 耐压、串口错误中断和 PWM 占空比的坑做这个项目时有几个问题会消耗大量时间。它们单看知识点都不复杂但表现现象会伪装成“传感器没反应”“模块不上报”实际出在主控配置层面。6.1 STM32F103 的 GPIO 能不能承受 5V 输入这是搜索热词里出现频率很高的问题。STM32F103 绝大多数 GPIO 是 FTFive-volt tolerant引脚可以承受 5V 输入但条件是没有上拉到 3.3V 以上。更严格地说FT 引脚允许 5V 输入但 ADC 相关引脚通常不是 5V 容忍的供电电压和 IO 电压都有约束。最稳妥的接法是如果传感器或通信模块输出 5V TTL 电平在 STM32F103 输入引脚前加电阻分压比如 1k 串联再接 2k 对地把 5V 降到 3V 左右。不要追求所谓的“绝对兼容 FT”尤其是批量做板时不同批次芯片 IO 电气参数存在波动。6.2 串口接收出现 HAL_UART_ERROR_FE 怎么处理有些红外模块或传感器串口模块输出时序不标准和 STM32F103 串口连接后容易触发 Frame Error。表现为串口中断回调不停进入 Error 回调正常数据收不到主循环被串口中断淹没。这只说明模块输出的波特率偏差较大或者线路上恰好有干扰。排查步骤用逻辑分析仪抓模块发送数据的实际波特率确认与配置一致。如果模块在 3.3V 下工作但逻辑电平偏低检查共地是否牢靠。若 HAL_UART_ERROR_FE 出现一次就停止接收是因为没有调用HAL_UART_Receive_IT重新开启中断。如果模块确实依赖 5V 电源不能用板载 3.3V 引脚强行供电。6.3 定时器 PWM 占空比到不了 100%很多人调蜂鸣器或 LED 呼吸灯时用 PWM 控制亮度。PWM 确实可以调速但遇到一个问题占空比设成 999/1000 时输出看起来还行一旦设置比较寄存器值和 ARR 完全相等输出反而变为恒低。原因在于 STM32F103 的 PWM 模式是“脉冲宽度调制模式 1”或“模式 2”。当计数器的值等于比较寄存器的值时会复位或翻转输出具体行为取决于模式和极性设置。比如在向上计数模式、PWM1 模式下当计数值小于 CCR 时输出有效电平所以如果 CCR 等于 ARR几乎整个周期都有效但最后一个计数点可能会跳变。要让占空比稳定达到 100%不能只把 CCR 设成 ARR。更可靠的方法是当需要满占空比时直接把输出引脚强制拉高断开定时器比较输出不需要满占空比时再恢复 PWM 输出。这个思路在智能井盖里的实际用途是控制加热型气体传感器的加热周期效果会稳定得多。6.4 排查问题时的顺序比技术本身更重要我处理这个项目的问题一般按固定顺序来看电源模块电源指示灯和万用表电压是否正常。看供电电流用手摸芯片外壳如果异常发烫要先断电排除短路。看串口日志HAL 库初始化是否都成功外设是否报错。看 GPIO 电平用万用表量模块输出和代码读到的电平比对。看中断触发在回调函数入口加翻转 GPIO 的调试代码判断中断有没有进。看地图文件如果程序运行异常打开 Keil 生成的 map 文件查看 RAM 占用和栈冲突可能性。这些步骤看起来基础但能解决大约 80% 的“跑不通”问题。7. 项目再往前走一步任务调度、数据存储和批量部署智能井盖从原型到可以长期运行还需要处理几个现实问题。7.1 要不要引入 FreeRTOS如果项目只有“定时上报”和“中断唤醒”裸机主循环已经够用。但一旦加入 OLED、NB-IoT 通信模块、气体传感器预热、GPS 数据解析、看门狗复位、按键调试等多个任务后裸机的逻辑会开始互相牵制。比较典型的问题是主循环里做了一次串口阻塞接收导致 GPIO 中断事件没有及时处理。FreeRTOS 在这个场景的价值不是“用上 RTOS 就高级”而是把不同节奏的任务放到独立线程OLED 刷新任务可以单独跑但不影响传感器采集通信任务在等待 AT 响应时释放 CPU开盖检测中断任务能立马通知采集任务低功耗模式下多个任务协调进入 Tickless 模式。不过 FreeRTOS 下做低功耗会复杂很多尤其当多个任务都在等待事件时需要选择适合的 Tickless 配置否则空闲任务无法真正降低功耗。所以我的建议是项目初期先裸机跑通等逻辑复杂超过两个状态机时再切 FreeRTOS。7.2 掉电保存数据是井盖终端的刚需井盖环境经常出现电池电压波动再加上通信模块瞬间拉电流很大主控可能在上报过程中突然掉电。如果某些关键数据只存在内存变量掉电后会全部丢失。STM32F103 内部有带后备区域的寄存器可以用 VBAT 引脚的纽扣电池维持。把开关状态、事件计数、最近一次采集时间放到后备寄存器里能在系统复位后快速恢复。注意后备寄存器数量有限不适合存储大数据只适合存少量状态标志。如果要用 Flash 保存历史记录或设备配置最简单的做法是模拟 EEPROM 操作专门划分一页或几页作为配置区写入时先备份关键字段再执行擦除写入完成后进行校验下次启动时先读取配置区如果不完整就恢复默认参数。7.3 运维阶段更关心输出命名和日志格式单个井盖怎么都行一旦同时调试多个井盖终端就一定要定义清晰规则每台设备一个固定 device_id例如MH-2024-001日志统一输出到同一个调试终端时前缀必须带设备号发送报文和接收响应都要留打印否则看不到模块是不是已经卡死云端要能根据设备号按时间检索历史数据不能光看实时状态。在批量部署前还要在测试环境连续运行至少 48 小时统计上报成功率、平均发送耗时、复位次数、电池电压下降曲线。只有这些数据达标才能说这个方案不止能跑 Demo。7.4 用普中板子做产品验证和最终部署之间的落差最后提醒一点普中 STM32F103 开发板带有大量板载外设USB 转串口、按键、LED、排针都会持续耗电。如果你只是学习验证这样很方便如果要做真正低功耗的井盖终端最终一定需要重新画一块最小系统板。最小系统板需要考虑选择合适封装的 STM32F103 芯片比如 C8T6 或 RBT6外部 8MHz 主晶振和 32.768kHz RTC 晶振SWD 下载接口电池供电电路和电压检测电阻传感器和通信模块的独立电源开关所有可能被误接的引脚增加保护电阻。这个“先开发板验证再最小系统打样”的流程适合大多数物联网终端项目。它能让你先把代码逻辑跑通再解决体积和功耗问题而不是一上来就焊板子结果代码和硬件混在一起出了问题根本没法定位。如果你正准备用 STM32F103 做类似的智能井盖、智能市政设备或环境监测终端我更建议先把单任务跑通记录每一次的电压、状态字段和串口日志然后再考虑批量、上云和低功耗优化。踩过几轮后会发现很多问题不是主控不够强而是电源、输入格式和模块之间的配合没有处理干净。