三年以下单片机工程师都会犯的错,今天给你将通了

今天用一个真实发生的例子，针对初级工程师经常犯的一个小错误，或者经常要走的一个弯路，做了针对性的纠正。希望可以帮到各位小伙伴，在以后的项目设计中不在踩坑。

假如现在你就要自己接下一个大型的多任务的项目，项目中需要单片机处理多个模块的数据，类似于“多任务”，此时的你应该怎么办？

故事的开始是这样的，就近公司安排一个3年工作经验的工程师接手一个多任务项目，项目大概需要用到电阻触摸屏（RS232），M1卡读写（RS232），电能计量表（RS485），语音提示（SPI），电力开关（继电器IO），通讯接口（RS485、CAN）。

工程师做的过程非常勤奋，期间也是困难重重，改了很多个版本，总算完工了，进入验收流程。

一开始验收就翻车了，发现读卡的时候不能处理触摸屏，播放语音的时候不能处理读卡，语音播放不能打断或者跳跃，反正就是所有事件必须一个一个按部就班的来，一旦操作错误就需要多次执行、等待、甚至重新来过。

一个工作3年多的工程师怎么会把产品做成这样呢？看看程序吧！

一看不要紧，吓一跳！整个的程序是没有逻辑的，一条线就往下写……

While（1）{
//上电进入主程序 或 触发触摸屏
//播放提示语音
　Delay（）；
//等待播放完毕
//读取M1卡信息
  Delay（）；
//等待读卡数据返回　
//播放提示语音
　Delay（）；
 //等待播放完毕
//M1卡数据交互，判定下一步操作及提示
　Delay（）；
//等待数据处理完毕
　　……
　　……
}

这里说这个工程师基本上对于自己设计的产品没有任何的整体概念，或者说对自己开发的程序用到设计上会有怎样的实际效果根本就不清楚。

几个问题

他犯了几个我们在程序开发过程中最忌讳的几个问题：

1、 delay（死等）这类函数只在应该实验室验证某个功能过程中用到，在实际的产品开发时无论是主循环while中，还是其调用的函数中，亦或是中断服务程序中绝对不可以用到。

2、 产品设计的各个子模块之间的逻辑关系太强，例如：必须等待播音完毕才能读卡进入下一步操作等。

我们讲，产品设计中只有各个事件处理模块间的逻辑关系弱化，才能更加灵活的进行处理。例如：两个事件A和B，如果程序开发时将A做成B事件的必要条件，B事件的触发就必须等待A事件的发生。反之如果A事件作为B事件处理的一个特殊情况，那么程序开发起来就变得灵活很多。

3、 没有考虑到单片机本身是一个单核单任务的架构，每一个事件都会独占CPU内核，当多个任务模块同时存在时我们应该对各个事件进行区分，我们应当分情况、分事件实时性要求等区分对待。　

如何处理

那么针对于这样的问题，或者是遇到类似的项目我们应该如何处理呢？小代提几条建议：

1、将硬件系统区分为独立单元单独做成底层驱动函数和应用函数，并且函数正常应该有参数和返回值，其中返回值是必要的。如何衡量这类函数呢？这类函数可移植性强，只要一个.h文件和一个.c文件就可以随意放到任何工程中。例如：语音播放、M1读卡、485处理等等。

2、将1中的所有函数进行时间评估，评估点有两个。一个是函数的执行时间t，第二个是函数的周期性发生的时间T，一个最基本的条件是t < T，理想情况应该是t << T。

3、建立一个集中逻辑处理函数，在这个函数中对1中的各个函数进行调度。这个函数发挥的作用相当于嵌入式系统中的系统调度。这种调度是整个硬件逻辑中所有事件处理的调度，它的目的是完成一个处理过程，但是绝不依赖于任意事件的必要处理过程。这样就将问题2中提到的事件间的逻辑关系弱化了，处理起来变得十分灵活，使得各个关系不在相互必要。

4、为了保证前面内容的正常实施还需要针对各类事件的周期，建立一个必要的时间管理函数，时间函数的基础一般情况下由一个内部定时器的中断来完成，中断的周期一般我们考虑5-10ms。按照实际需求将N个定时器中断定义为一个事件处理的周期TT，这个周期应该保证处理完最恶劣情况可能发生的所有t，且保证TT < T。

5、 这其中也有例外，一些实时性要求高的事件应当用中断完成。其中中断处理函数的处理事件应尽量短。