单片机/嵌入式系统程序架构总结

2020-5-28 16:35

在工作中经过摸索实验，总结出单片机大致应用程序的架构有三种：

1. 简单的前后台顺序执行程序，这类写法是大多数人使用的方法，不需用思考程序的具体架构，直接通过执行顺序编写应用程序即可。

2. 时间片轮询法，此方法是介于顺序执行与操作系统之间的一种方法。

3. 操作系统，此法应该是应用程序编写的最高境界。

下面就分别谈谈这三种方法的利弊和适应范围等。

2020-5-28 16:36

一、顺序执行法

这种方法，这应用程序比较简单，实时性，并行性要求不太高的情况下是不错的方法，程序设计简单，思路比较清晰。但是当应用程序比较复杂的时候，如果没有一个完整的流程图，恐怕别人很难看懂程序的运行状态，而且随着程序功能的增加，编写应用程序的工程师的大脑也开始混乱。即不利于升级维护，也不利于代码优化。本人写个几个比较复杂一点的应用程序，刚开始就是使用此法，最终虽然能够实现功能，但是自己的思维一直处于混乱状态。导致程序一直不能让自己满意。

这种方法大多数人都会采用，而且我们接受的教育也基本都是使用此法。对于我们这些基本没有学习过数据结构，程序架构的单片机工程师来说，无疑很难在应用程序的设计上有一个很大的提高，也导致了不同工程师编写的应用程序很难相互利于和学习。

前后台系统：这样的程序包括一个死循环和若干个中断服务程序：

　　应用程序是一个无限循环，循环中调用API函数完成所需的操作，这个大循环就叫做后台系统。
　　中断服务程序用于处理系统的异步事件，也就是前台系统。前台是中断级，后台是任务级。

弊端：假设当前有模块1,2,3。假设来了中断需要处理模块3，如果模块3的处理是最紧迫的，但是当前cpu 只运行到模块1，这样的话，必须还要承受模块2的运行时间延迟，才能轮到模块3的处理，当模块越多的时候很可能情况更糟糕。单个循环要解决此类问题的话，只能在中断里面去处理紧急事件，这样会造成中断执行太长，造成多层的中断嵌套，最终可能导致中断栈空间爆掉。更重要的是：不是所有的中断都是紧急的重要的，很可能各个要处理的模块优先级要大于不紧急的中断处理。这样造成的后果是不但各个模块间不能相互通讯，而且实时模块完全得不到处理，在一个中大型软件项目中，采用此类方法可以说是一种管理的灾难。

2020-5-28 16:37

本人建议，如果喜欢使用此法的网友，如果编写比较复杂的应用程序，一定要先理清头脑，设计好完整的流程图再编写程序，否则后果很严重。当然应该程序本身很简单，此法还是一个非常必须的选择。

下面就写一个顺序执行的程序模型，方便和下面两种方法对比：

复制

/**************************************************************************************

* FunctionName   : main()

* Description    : 主函数

* EntryParameter : None

* ReturnValue    : None

**************************************************************************************/



int main(void)

{

    uint8 keyValue;



    InitSys();                  // 初始化



    while (1)

    {

        TaskDisplayClock();

        keyValue = TaskKeySan();

        switch (keyValue)

       {

            case x: TaskDispStatus(); break;

            ...

            default: break;

        }

    }

}