单片机“多任务”时应该怎么去思考和处理？

gaosmile

今天分享的文章，主要给那些没有软件设计思想的MCU软件工程师看的！随着目前MCU的各方面性能显著提升，一些以MCU为控制中心的嵌入式系统也是越来越复杂，毫无软件设计理念的代码真的是拖累单片机，所以对每个MCU软件工程师在软件设计等方面的要求也将越来越高！

这里利用一个实际发生的例子，对入行的初级软件工程师提一些软件设计上的建议，并分享了一些经常走的弯路，希望可以帮到大家。这篇文章我没有谈编程的规范性的东西，如果你想让自己的程序文件代码更加直观、看起来美观、可读性强，推荐学习一下全面的编程规范，比如网络上广为流传的，华为“C语言编程规范”。本文主要想说一说当我们的单片机遇到多个模块的数据需要处理，类似于“多任务”时应该怎么去思考和处理？
背景是这样的，9月份开始安排一个工程师开始做电动汽车交流充电桩，机械设计部分由公司机械结构部门负责。充电桩的电子部分总体上分为X个部分（用到的资源）: 电阻触摸屏（RS232），M1卡读写（RS232），电能计量表（RS485），语音提示（SPI），电力开关（继电器IO），通讯接口（RS485、CAN）。
工程师做的过程非常勤奋，期间也是困难重重，改了很多个版本，很多的bug，总算第二年6月把充电桩立起来了。
当然此过程我并没有过多的干涉，系统也没有经过非常严格的测试，结果发现读卡的时候不能处理触摸屏，播放语音的时候不能处理读卡，语音播放不能打断或者跳跃，反正就是所有事件必须一个一个按部就班的来，一旦操作错误就需要多次执行、等待、甚至重新来过。
一个工作3年多的工程师怎么会把产品做成这样呢？思来想去不应该呀，是不是程序哪里出了问题 ? 解决问题的最好办法就是评审代码，来review代码瞧瞧。
不看不知道，一看吓一跳！整个的程序是没有逻辑的，一条线就往下写，这不正是当年在学校刚做第一个项目的代码吗 ? ……

//主循环
while（1）
{
  //上电进入主程序 或 触发触摸屏
  Function1();//播放提示语音
  Delay();//等待播放完毕

  //读取M1卡信息
  Function2();
  Delay();//等待读卡数据返回

  //播放提示语音
Function3();
  Delay();//等待播放完毕

  //M1卡数据交互，判定下一步操作及提示
Function4();
  Delay();//等待数据处理完毕

  ……
  ……
}

从代码上可以看出这个工程师基本上对于自己设计的产品没有任何软件上的设计可言，也很少去吸收一些优秀的代码和思想，对自己开发的程序在产品上的具体表现也不敏感，更被说对RTOS的学习和理解了。

他犯了几个我们在程序开发过程中几个忌讳的问题：
1、 delay（死等）这类函数应该只在实验室验证某个功能过程中用到，或许是在一些初始化时序使用到，而不会用来控制整个的程序运行架构，在实际的产品开发时无论是主循环while中，还是其调用的函数中，亦或是中断服务程序中几乎是不可能看到的。
2、 产品设计的各个相对比较独立的子模块之间的逻辑关系太强，例如：必须等待播音完毕才能读卡进入下一步操作等。
我们讲，产品设计中只有各个事件处理模块间的逻辑关系弱化，才能更加灵活的进行处理。例如：两个事件A和B，如果程序开发时将A做成B事件的必要条件，B事件的触发就必须等待A事件的发生。反之如果A事件作为B事件处理的一个特殊情况，也就是说我不执行A也有可能执行B，那么程序开发起来就变得灵活很多。
3、 没有考虑到单片机本身是一个单核单任务的架构，每一个事件都会独占CPU内核，当多个任务模块同时存在时我们应该对各个事件进行区分，我们应当分情况、分事件实时性要求等区分对待。　　

那么针对于这样的问题，或者是遇到类似的项目我们应该如何处理呢？　


这里提一下我的建议和想法，首先他这里是裸机开发，所以就不谈RTOS方面的设计建议了，仅仅只是针对前后台架构。
1、将硬件系统区分为独立单元单独做成底层驱动函数和应用函数，并且函数正常应该有参数和返回值，其中返回值是必要的。如何衡量这类函数呢？这类函数可移植性强，只要一个.h文件和一个或多个.c文件就可以随意放到任何工程中，一句话吧，模块化！例如：语音播放、M1读卡、485处理等等。
2、将1中的所有函数进行时间评估，评估点有两个。一个是函数的执行时间t，第二个是函数的周期性发生的时间T，一个最基本的条件是t < T，理想情况应该是t << T。
3、建立一个集中逻辑处理函数，也就是核心任务调度处理函数，在这个函数中对1中的各个函数进行调度。这个函数发挥的作用相当于嵌入式系统中的系统调度。这种调度是整个硬件逻辑中所有事件处理的调度，它的目的是完成一个处理过程，但是绝不依赖于任意事件的必要处理过程。这样就将问题2中提到的事件间的逻辑关系弱化了，处理起来变得十分灵活，使得各个关系不在相互必要。bug菌记得有一本书籍叫<时间触发型调度系统>,大伙可以看看，大体思想与这里的观点差不多！
4、为了保证前面内容的正常实施还需要针对各类事件的周期，建立一个必要的时间管理函数，时间函数的基础一般情况下由一个内部定时器的中断来完成，中断的周期一般我们考虑5-10ms。按照实际需求将N个定时器中断定义为一个事件处理的周期TT，这个周期应该保证处理完最恶劣情况可能发生的所有t，且保证TT < T。
5、 这其中也有例外，一些实时性要求高的事件应当用中断完成。其中中断处理函数的处理事件应尽量短，时间要求参见2。bug菌觉得，不管你所做的项目有没有用到RTOS，平时都需要玩玩RTOS，对该观点的理解会有帮助。6、如果某种情况需要裸机开发，大家可以看一些比较好的架构，一些经典的菜单，按键，软件定时器，还有串口等，移植起来非常方便，效率也非常高，可以大大健壮我们的代码。