单片机程序开发时,初级工程师常犯的一个错误单片机程序开发时,初级工程师常犯的一个错误
这里利用一个实际发生的例子,针对初级工程师经常犯的一个小错误,或者经常要走的一个弯路,做了针对性
的纠正。希望可以帮到大家,文笔不好文章中有叙述不清的地方大家多多指教。
这篇文章我不是想说编程的规范性的东西,如果你想让自己的程序文件最起码直观的看起来美观、可读性强,推荐找华为
的“C语言编程规范”。我只想说一说当我们的单片机遇到多个模块的数据需要处理,类似于“多任务”时我们应该怎么办?
背景是这样的,去年9月份开始安排一个工程师开始做电动汽车交流充电桩,机械设计部分由公司机械结构部门负责。充电桩
的电子部分总体上分为X个部分(用到的资源),电阻触摸屏(RS232),M1卡读写(RS232),电能计量表(RS485),
语音提示(SPI),电力开关(继电器IO),通讯接口(RS485、CAN)。
工程师做的过程非常勤奋,期间也是困难重重,改了很多个版本,总算今年6月把充电桩立起来了。
咱们来验收一下吧,结果发现读卡的时候不能处理触摸屏,播放语音的时候不能处理读卡,语音播放不能打断或者跳跃,反正
就是所有事件必须一个一个按部就班的来,一旦操作错误就需要多次执行、等待、甚至重新来过。
一个工作3年多的工程师怎么会把产品做成这样呢?看看程序吧!
一看不要紧,吓一跳!整个的程序是没有逻辑的,一条线就往下写……
While(1)
{
//上电进入主程序 或 触发触摸屏
//播放提示语音
Delay();//等待播放完毕
//读取M1卡信息
Delay();//等待读卡数据返回
//播放提示语音
Delay();//等待播放完毕
//M1卡数据交互,判定下一步操作及提示
Delay();//等待数据处理完毕
……
……
}
这里说这个工程师基本上对于自己设计的产品没有任何的整体概念,或者说对自己开发的程序用到设计上会有怎样的实际效果
根本就不清楚。
他犯了几个我们在程序开发过程中最忌讳的几个问题:
1、 delay(死等)这类函数只在应该实验室验证某个功能过程中用到,在实际的产品开发时无论是主循环while中,还是其调
用的函数中,亦或是中断服务程序中绝对不可以用到。
2、产品设计的各个子模块之间的逻辑关系太强,例如:必须等待播音完毕才能读卡进入下一步操作等。
我们讲,产品设计中只有各个事件处理模块间的逻辑关系弱化,才能更加灵活的进行处理。例如:两个事件A和B,如果程序
开发时将A做成B事件的必要条件,B事件的触发就必须等待A事件的发生。反之如果A事件作为B事件处理的一个特殊情况,
那么程序开发起来就变得灵活很多。
3、 没有考虑到单片机本身是一个单核单任务的架构,每一个事件都会独占CPU内核,当多个任务模块同时存在时我们应该对
各个事件进行区分,我们应当分情况、分事件实时性要求等区分对待。
那么针对于这样的问题,或者是遇到类似的项目我们应该如何处理呢?
我提几条建议:
1、将硬件系统区分为独立单元单独做成底层驱动函数和应用函数,并且函数正常应该有参数和返回值,其中返回值是必要