驱鸟器项目的 IO 组合模式设计(MCU 用多个引脚电平组合告诉语音模块当前模式),在群里走完了一次教科书级的排障:从"附加条件"到"变量+判断"的方案演进,再到"电平触发靠变化"的机制顿悟与"改用串口"的方案收束。本篇按演进顺序复盘,重点记录两个机制级教训。

需求:多引脚电平组合=模式选择

MCU→语音模块的控制逻辑:PA4 高=开机、PA5 高=关机、PA3 高=智能模式、PA2 高=定时模式;两脚同时高=高频/低频模式;三脚同时高=仿真驱鸟/爆闪模式。客户最初的实现是给 IO 触发配"附加条件",结果带 PA5 的组合只播"已关机"——单引脚触发器先响应了,组合条件根本轮不到。

方案一:IO 输入设变量+控制里判断

厂商的方案转型:"把附加条件去掉,然后都配置 IO 输入高低电平触发去设置变量的值,在控制里面去判断这几个变量的值再执行动作",并给了 A3/A2 的配置截图示例。这个思路把"组合条件"从触发层挪到了判断层:每个 IO 只负责把变量写成 1/0,动作在控制节点里按变量组合分发。

第一版判断写法立刻翻车:"不管点啥都是智能模式"——厂商点破:"0 不也是不等于 1,不也是都满足吗"?判断条件用了"不等于",任何值都命中,永远轮到智能模式。修正:判断必须精确等于目标组合值,且组合判断要用"与"逻辑(所有引脚变量同时为 1)而不是单个不等式。

教训一:电平触发靠"变化",不靠"状态"

修完判断,客户的新症状是"好像卡到里面了"。厂商的机制解释是本篇核心:"电平触发是电平变化了才会触发到,比如低变高,高变低,你都堆在一个已经一直在高电平的状态的引脚,怎么可能触发";延时恢复只是把变量值恢复,"你只是恢复他的值,没有电平变化触发到一样不会控制"。

把这条写进设计守则:电平触发是边沿语义(检测变化),不是电平语义(检测状态)。MCU 若把引脚长期保持高电平,只在模式切换瞬间才有触发;若需要模块持续知道"当前状态",要么 MCU 每次切换都制造一次变化(先拉低再拉高),要么改用串口持续上报——这正是方案二。

教训二:串口是组合指令的正解

方案收束时厂商建议:"要不你改用串口更方便"。客户起初担心 PB5/6 没连单片机,厂商提醒:"A2,A3 也可以用串口,你不知道吗"——串口不只一组。客户还想用 IR-RX 引脚,厂商纠正:"这是红外的接受,用来学习红外指令的"(与此前红外接收用途的结论一致)。

多引脚电平组合做模式选择的方案,在"触发是边沿、判断要精确、恢复不触发"三重约束下复杂度很高;串口一条指令带模式号,状态、触发、校验一次解决。群聊的结论清晰:模式类控制优先串口,IO 电平留给简单的开关量。

落地清单

1. 多引脚组合=变量化每个 IO+控制层精确判断("等于"且逐位与),不用附加条件;
2. "不等于"判断会命中一切,组合判断必须写全组合值;
3. 电平触发是边沿语义:检测变化,不检测状态;长期保持的电平不触发;
4. 延时恢复只恢复变量值,不产生触发;
5. 模式类控制优先串口(多组串口可选,A2/A3 也能复用);
6. IR-RX 是红外学习专用,不当通用 IO;
7. 变量掉电恢复:重新上电会重置,配置记忆功能可保持;

从附加条件到变量判断再到串口,这个项目的三次转向画出了一条清晰的复杂度阶梯——需求复杂度超过 IO 触发的表达力时,早转串口,少熬三夜。