裸机开发警钟

我们在程序开发过程中几个忌讳的问题：
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，对该观点的理解会有帮助。