嵌入式软件开发中那些令人难忘的bug

本文通过博主亲身经历的实例,探讨了嵌入式开发中常见的全局变量和数组越界问题,以及硬件因素带来的挑战。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.前言

博主目前在嵌入式(物联网领域)深耕,从小白到现在(当然,现在还是小白微笑)躺过了无数大大小小的坑,细想那几个令人难忘的深坑,现在还能感受到当时的酸爽微笑。话不多说,让我们一起上车,开启嵌入式bug之旅。

2.话语bug

嵌入式界是一个充满惊喜的世界,是人与自然相互融合的典范。

2.1 全局变量的惊喜

全局变量是一把利剑,用于信息传递是非常灵活方便的,但用不好很容易伤身。常见的问题表现在全局变量在某处被异常变更(如某中断处理函数中),导致其他使用该全局变量的函数处理出现问题。以博主亲身经历过的bug为例:如在无线数据接收处理中断程序中,用全局变量A的bit位来表示接收到的包类型,且每次收到新的数据包时只更新其中相应的bit位(如置位),其它位由于忽视未进行清零处理,导致在传递该信息给另外一个全局变量B进行处理时出现问题。此类问题测试时也不容易发现,有可能需要对产品做大批量测试(如各类数据包收发等)及长时间运行等观察才会出现(和具体的异常功能有关)。
当然此类错误是比较低级的,往往和全局变量的滥用、程序的可读性差、程序的架构(如可扩展性、代码模块的可复用性)是否合理相关。当使用的全局变量较多,程序结构较为复杂、功能较多时,容易“牵一发而动全身”,即程序功能之间的耦合性较高,此时可将裸机程序迁移到RTOS上,可大程度降低程序功能之间的耦合性,也提高了可扩展性,避免类似的悲剧。

2.2 数组越界的困惑

在无线通信领域涉及到数据接收处理时,一般的方法是利用数组作为数据的接收缓冲区(如一级、二级缓冲区),这里如果读写指针处理不当往往会导致数组越界的问题,如对丢失的数据包进行补偿时,未对数组剩余缓冲区的长度进行判断等。数组越界导致的异常是不可预料的,如其它地址上数值被异常更改进而引发程序执行出错甚至跑飞。对于此类问题可对读写指针及数组剩余缓冲区的大小的可能情况进行穷举,并作异常判断来尽量避免。

3.bug之番外篇

番外篇是留给硬件的,在嵌入式界,硬件和软件是难以分割的,而硬件也占据了十分重要的地位。硬件制造的惊喜往往是难以想象的。

3.1 论防潮的重要性

在户外密闭空间且需要电池供电的设备,在长期运行的过程中,难免受到潮气的影响使板子电容漏电加大甚至短路,导致设备运行故障。常见的处理方式是出厂后直接给板子打胶或者刷三防漆使之与空气隔绝。

4.结语

嵌入式的坑不仅体现了人类自身逻辑设计的缺陷,也完美的展现了大自然才是你父亲的宗旨。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值