|
在做MCU实时监控，说白了就是给系统装个电子眼，随时盯着有没有幺蛾子，会出什么问题。怎么把监控做实，技术要求是啥，再吐槽几个没盯住系统崩盘的惨剧，就在刚刚我们设计的产品，卖的很好的，居然就还屏都崩掉了，操作什么都没有反应了。 其实实时监控得把系统关键参数都搂进来，比如CPU负载任务调度是否超时、内存使用堆栈会不会溢出、外设状态SPI/UART有没有数据、传感器值合不合理。技术要求上，采样得低开销，别为了监控把主程序拖垮。比如用硬件定时器触发采样，或者DWT数据观察点单元统计任务执行时间，这样比软件轮询准还省CPU。然后是故障检测要“快而稳”。预设阈值和规则，比如内存低于20%报警，任务执行超过50ms正常是10ms就认为卡死，SPI连续10次没响应算故障。技术要点是快速响应，别等系统崩了才报错。比如用硬件中断触发故障处理，SPI出错直接进中断，比软件轮询快十倍。能够预判问题的发生和正常情况可以在实际时的运行状态点。 日志记录得高效不刷屏，串口日志要是每秒刷几百条，主程序早被打断傻了。得搞分级日志DEBUG/INFO/ERROR，重要错误才发串口，普通信息存缓冲区。技术要求上，用环形缓冲区+DMA传输，CPU只管往缓冲区写，DMA自动发串口，这样主程序几乎不受影响。掉电保存更关键，比如用FRAM铁电存储器或电池备份的SRAM，系统崩溃前把最后几条关键日志存下来，不然重启后啥都查不到。
看门狗是保命符，但得用对。独立看门狗喂狗时间宽松，窗口看门狗有喂狗时间窗口0.5秒到1秒之间，后者更严，能防喂狗太早或太晚。技术要点是喂狗时机必须关联系统关键任务，比如任务调度器的心跳信号，或者多个任务的联合喂狗电机任务+通信任务都正常才喂狗，防止某个任务卡死但其他任务正常，导致看门狗没触发。 系统健康度评估得“定期汇总”。比如每小时统计一次：任务最大执行时间、内存碎片率、外设错误次数SPI超时/UART丢包。技术要求是用低优先级任务处理统计数据，别影响实时性。比如用空闲任务CPU空闲时或定时器中断低优先级来汇总，这样主程序该跑跑，统计不耽误。 测试和验证得模拟真故障。别只测正常情况，得故意搞崩系统，比如让任务死锁、内存泄漏、外设断线，看监控能不能及时报错。技术要点是用故障注入工具软件模拟SPI不响应，或者手动改代码制造异常，验证监控系统的响应时间和准确性。 最后唠唠踩过的坑。有次日志系统缓冲区设太小64字节，高并发时日志丢了一半，故障发生后查不到原因，干瞪眼。还有次看门狗喂狗条件太简单，只要通信任务正常就喂狗，结果电机任务卡死半小时，看门狗没触发，电机烧了。更惨的是状态采样频率太低1秒一次，系统500ms就崩了，监控根本没抓到崩溃前的状态，白忙活。
在我们公司我再说一下几个手段，一个是通过串口屏去看，一个是示波器去抓波形，一个是上位机去看，还有那个modbus去实时监控。
实时监控要全、快、稳、省：关键参数全覆盖，故障检测快响应，日志记录稳保存，系统开销省到底。看门狗不是万能的，得结合任务调度和关键指标喂狗。这样系统崩了也能快速定位，少砸屏！你遇到过哪些监控没盯住的坑？一起唠唠，避避雷！
| 
楼主
标题置顶
标题高亮
