原创 单片机的非OS的事件驱动思考1

很多单片机项目恐怕都是没有操作系统的前后台结构，就是main函数里用while无限循环各种任务，中断处理紧急任务。这种结构最简单，上手很容易，可是当项目比较大时，这种结构就不那么适合了，编写代码前你必须非常小心的设计各个模块和全局变量，否则最终会使整个代码结构杂乱无序，不利于维护，而且往往会因为修改了某部分代码而莫名其妙的影响到其他功能，而使调试陷入困境。

改变其中局面的最有效措施当然是引入嵌入式操作系统，但是大多数的操作系统都是付费的（特别是商业项目）。我们熟悉的uc-os/II如果你应用于非商业项目它是免费的，而应用于商业项目的话则要付费，而且价格不菲。

我们也可以自己编写一套嵌入式OS，这当然最好了。可要编写一套完整的OS并非易事，而且当项目并不是非常复杂的话也不需要一个完整的os支持。我们只要用到OS最基本的任务调度和上下文切换就够了。正是基于这样的想法，最近的一个项目中我就尝试采用事件驱动的思想重新构建了代码架构，实际使用的效果还不错，在这里做个总结。

本质上新架构仍然是前后台结构，只不过原来的函数直接调用改成通过指向函数的指针来调用。实际上这也是嵌入式OS任务调度的一个核心。C语言中可以定义指向函数的指针：

    void (*handle)(void);

这里的handle就是一个指向函数的指针，我们只要将某函数的函数名赋给该指针，就能通过实现函数的调用了：

    void func1(void)
    {
        // Code
    }

    handle = func1;
    (*handle)(); // 实现func1的调用

有了这个函数调用新方法，我们就可以想办法将某个事件与某个函数关联，实现所谓的事件驱动。例如，按键1按下就是一个事件，func1响应按键1按下事件。但是，如果是单纯的调用方法替代又有什么意义呢？这又怎么会是事件驱动呢？关键就在于使用函数指针调用方法可以使模块和模块之间的耦合度将到最低。一个例子来说明这个问题，一个按键检测模块用于检测按键，一个电源模块处理按键1动作。

传统的前后台处理方法：
main.c

    void main()
    {
        ...
        while(1)
        {
            ...
            keyScan();
            if(flagKeyPress)
            {
                keyHandle(); // 检测到按键就设置flagKeyPress标志，进入处理函数
            }
        }
    }

key.c

    void keyHandle(void)
    {
        switch (_keyName) // 存放按键值的全局变量
        {
             ...
            case KEY1: pwrOpen(); break;
            case KEY2: pwrClose(); break;
        }
    }

power.c

    void pwrOpen(void)
    {
        ...
    }

    void pwrClose(void)
    {
        ...
    }

这样的结构的缺点在哪里呢？
1. key代码中直接涉及到power代码的函数，如果power代码里的函数变更，将引起key代码的变更
2. 一个按键值对应一个处理函数，如果要增加响应处理函数就要再次修改key代码
3. 当项目越来越大时，引入的全局变量会越来越多，占用过多的内存
很显然key模块与其他模块的耦合程度太高了，修改其他模块的代码都势必去修改key代码。理想的状态是key模块只负责检测按键，并触发一个按键事件，至于这个按键被哪个模块处理，它压根不需要知道，大大减少模块之间的耦合度，也减少出错的几率。这不正好是事件驱动的思想吗？

接下来，该如何实现呢？