今天分享的文章,主要给那些没有软件设计思想的MCU软件工程师看的!随着目前MCU的各方面性能显著提升,一些以MCU为控制中心的嵌入式系统也是越来越复杂,毫无软件设计理念的代码真的是拖累单片机,所以对每个MCU软件工程师在软件设计等方面的要求也将越来越高!
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中提到的事件间的逻辑关系弱化了,处理起来变得十分灵活,使得各个关系不在相互必要。有一本书籍叫<时间触发型调度系统>,大伙可以看看,大体思想与这里的观点差不多!4、为了保证前面内容的正常实施还需要针对各类事件的周期,建立一个必要的时间管理函数,时间函数的基础一般情况下由一个内部定时器的中断来完成,中断的周期一般我们考虑5-10ms。按照实际需求将N个定时器中断定义为一个事件处理的周期TT,这个周期应该保证处理完最恶劣情况可能发生的所有t,且保证TT < T。
5、 这其中也有例外,一些实时性要求高的事件应当用中断完成。其中中断处理函数的处理事件应尽量短,时间要求参见2。不管你所做的项目有没有用到RTOS,平时都需要玩玩RTOS,对该观点的理解会有帮助。来源:最后一个bug,参考作者:handong