在实时系统里处理面板按键，问题往往不在于能不能读到这个键，而在于事件从硬件到应用层的这条链路该怎么设计。
按键信号进入控制器之后，第一件事是区分状态与事件。状态回答的是现在按着没有，事件回答的是什么时候被按下的，两者在上层用起来的差别很大。
如果只把状态交给应用，长按和连击这类操作就无法被上层正确区分，应用层拿到的只是最后一次的变化结果。
事件式上报需要在检测到有效触发的时刻生成一条记录，并且带上足够的信息，让上层能判断这是哪一次按下。
时间戳的来源要明确。直接用读取寄存器那一刻的时间，包含了中断响应与调度延迟，作为操作发生时刻会偏晚。
从中断到任务真正处理之间存在延迟，这段延迟在不同负载下差别很大，需要在设计阶段就估计出来。
消抖放在哪一层也要做选择。放在中断里会占用中断处理时间，放在任务里则按键响应会跟着任务周期变慢，两种做法各有代价。
一个常见的折中是中断只负责记录触发时刻并置标志，消抖与判定放在周期任务里执行，这样中断路径足够短。
消息队列适合事件量较多或需要按顺序处理的场合，队列长度不足时新事件会被丢弃，丢弃策略要事先想清楚。
直接置标志加计数的方式更省资源，适合只需要知道按下次数而不需要还原顺序的场景。
多个按键同时触发时，事件顺序可能与物理顺序不同，这在结构上无法完全避免，上层不应依赖这个顺序做严格判断。
事件结构里带上键号和序号比只带键号更稳妥，序号可以用来识别丢失，让上层知道数据并不连续。
处理超时的场景要谨慎，事件积压时如果一直按最旧的取走处理，用户按了很多次却只看到最初那一次，体验上会出现迟钝。
在设计阶段做一次简单的估算就能看出队列够不够用，按最长任务周期乘以最大事件速率得到每周期的事件数，这个数乘以允许积压的周期数就是队列长度。
最后是验证。事件链路的问题在台面上不一定能看出来，长时间运行加上随机按键的组合更容易暴露丢事件和顺序错乱。
固件侧还要处理按键未释放的情况，用户按住不放时不能反复产生事件，这类状态要单独表示。
事件上报的延迟如果需要进入界面响应时间的统计，就要从硬件触发到界面刷新整条链路一起算。
在有看门狗的系统里，事件处理任务不能长时间占用执行单元，否则会触发复位，这与消抖参数的选择有关联。
低功耗设计里还有一个常见问题，唤醒源配置之后，某些任务在休眠时仍然在跑，功耗并没有真正降下来。
调试阶段可以给每个事件加一个计数和序号，日志里就能看出有没有丢事件，丢在哪一段链路。
把这些约定写进接口文档，比在代码里到处加注释更有效，接手的人能看到设计时的取舍。
事件与状态混用的另一个后果是重复触发，上层收到两次相同的状态变化就可能执行两次动作。
在多任务环境里，按键事件的优先级要高于普通业务消息，否则界面响应会被拖慢。
如果设备支持远程按键注入，事件路径还要区分来源，本地按键和远程命令要在数据结构里标出来。
事件队列的长度如果按最坏情况算，通常会比实际需要大得多，可以先按正常负载估算再留余量。
调试时把按键的按下时长分成几档分别测试，长按的判定逻辑往往只有在极短的按压上才暴露问题。
一个实用的做法是把按键事件绑定到业务动作上，中间加一层映射，硬件层和业务层分开之后都好改。