裸机编程的几种模式、架构、缺陷

裸机编程模式/架构 1：初始化代码的编写

裸机编程模式/架构 2：轮询模式

裸机编程模式/架构 3：轮询加中断执行模式

裸机编程模式/架构 4：中断+定时器+主循环的前后台架构

裸机编程模式/架构 5：前后台 + 状态机架构

嵌入式常见的操作系统

绝大多数嵌入式初学者都从裸机编程开始，因为它更加直观、简单。通过裸机编程，你能够直接操作硬件，代码所见即所得，调试也非常方便。相比使用操作系统，裸机编程无需掌握大量的操作系统基础知识和调度机制的常识，也不需要考虑资源共享和竞争等概念。此外，裸机编程的调试过程也更加直观。

下面是裸机编程中常见的模式和架构：

1. 引脚配置和外设初始化：裸机编程的第一步是配置芯片的引脚和初始化外设。通过配置引脚的功能和模式，你可以连接和配置各种外设，如串口、定时器等。

2. 中断处理：中断是裸机编程中处理外部事件的常见方式，如定时器溢出、串口接收等。通过设置中断向量表和编写中断服务函数，你可以对外部事件进行及时响应和处理。

3. 状态机：裸机编程中经常使用状态机来处理复杂的任务。状态机将任务拆分为不同的状态，并根据当前状态和外部事件的触发来进行状态转移和处理。

4. 轮询方式：对于较简单的任务，裸机编程可以使用轮询方式来实现。也就是不断地查询和检测外部事件的状态，并根据需要做出相应的响应和处理。

5. 低功耗模式：裸机编程中可以通过设置芯片的低功耗模式来降低系统功耗。这可以通过配置和操作控制器状态机来实现。

6. 调试和测试：裸机编程具有直观性和简单性的特点，因此在调试和测试方面也相对容易。你可以使用调试器、示波器等工具来查看寄存器的值和程序的执行流程，以便定位问题并进行调试。这些是裸机编程中常见的模式和架构。

对于初学者来说，裸机编程在一些相对简单的项目上具有一定的优势。然而，对于复杂的应用场景，使用操作系统和软件抽象层会更具优势。

裸机编程模式/架构 1：初始化代码的编写

裸机编程模式/架构 2：轮询模式

这些函数依次执行，全部执行完毕后再次从第一个逻辑开始，以此不断循环。

这种模式是最简单也是最初级的模式，但其也存在很多问题。由于上述的每一个逻辑会依次执行，那么就会相互影响，因为是裸机嘛，代码是串行执行的，就会出现实行性不好的情况。

比如后续逻辑中存在一些交互行为，Key_Task()会判断一个按键的按下状态并做出响应，而此时还在 RTc_Task()中执行延时指令，那么整体运行就会显得非常卡顿，甚至还会因为错过用户按键的时机而导致即使按下了按键，也没有执行对应的反馈。这个实行性的问题也就是裸机的最大缺陷！

裸机编程模式/架构 3：轮询加中断执行模式

/* 按键中断的ISR */
void Key_Isr(void)
{
    do_c();
}

void main()
{
    /* 初始化 */
    /*
    .
    .
    .
    */

    while(1) {
        do_a();
        do_b();
    }

}

如上图所示，当程序中出现交互的设计的时候，采用外部中断确实很好的解决了按键按下立马得到响应，这种模式其实在很多简单的应用场景下已经够用了，那我们接下来来挑一下这种模式的缺陷。

假设现在我有这样的一个需求，需要在while(1)的轮询模式中， do_a()和do_b()每隔一定的时间调用一次，是不是相当于这样。

/* 按键中断的ISR */
void Key_Isr(void)
{
    do_c();
}

void d0_a()
{
    delay(100);
}

void d0_b()
{
    delay(200);
}

void main()
{
    /* 初始化 */
    /*
    .
    .
    .
    */

    while(1) {
        do_a();
        do_b();
    }

}

最初的想法是do_a()这个函数每隔100ms调用一次，如果while(1)只有这个任务，且不产生中断的情况，是可以达到我们设想的要求的。但是有了中断和while(1)中不只执行一个函数的时候，这种设计就是失败的。

裸机编程模式/架构 4：中断+定时器+主循环的前后台架构

__IO uint32_t a_tick, b_tick;

/* 按键中断的ISR */
void Key_Isr(void)
{
    do_c();
}

void d0_a()
{
    if(uwTick - a_tick < 100)
        return;
    a_tick = uwTick ;

    /*
    .
    .
    */
}

void d0_b()
{
    if(uwTick - b_tick < 200)
        return;
    b_tick = uwTick ;

    /*
    .
    .
    */
}

void main()
{
    /* 初始化 */
    /*
    .
    .
    .
    */

    while(1) {
        do_a();
        do_b();
    }

}

上述代码使用的system timer，每隔1ms将uwTick这个全局变量加1，使用定时器来辅助确定调用函数的时间间隔。这样，就能保证在这种模式下while(1)中的每一个任务每隔一定的时间调用一次。

由于去掉了每个逻辑中的延时，取而代之的是标志位的判断，其执行速度是非常快的，如上图所示，灰色的块表示在运行判断逻辑并且没有满足运行要求。这种情况下每个逻辑都能在其指定的周期内得到执行。

这种架构在裸机编程中可以算得上一种中高级的架构，能够满足大多数不是特别复杂的需求。当然，在上图中我们可以看到 do_a 和 do_b 一个为 100 毫秒，一个为 50 毫秒，存在公倍数情况，也就是说在某一时刻，如这里的 0 毫秒和 100 毫秒，就会出现两个逻辑同时运行的场景。实际在项目中如果要求比较严格，会对这个周期进行一个控制和计算，尽量减少各逻辑同时执行的概率，避免由于同时执行的逻辑过多且过于频繁，执行时间的总和仍然会太长，从而影响整体运行稳定性的问题。

到这里请思考一下，假如 do_a 逻辑本身的执行时间就很长，比如进行一个非常复杂的运算，或者需要读取一个 G 级别的文件，导致单一逻辑的执行时间就超过了最小周期（如例子中的 50 毫秒），那即使 50 毫秒的周期到了，由于 do_a 还没运行完，do_c 也无法得到运行，这时候时间标志已经形同虚设，甚至由于此处是取余判断，假如 do_a 运行了 51 毫秒结束，do_b 在判断的时候已经是 52 毫秒，52%50 不为零，do_b 直接无法执行，时间标志甚至产生了负面影响！

虽说将 “通过取余运算判断是否可以执行的逻辑” 修改为 “设置多个时间标志（如 50ms_flag、100ms_flag等），在中断中判断满足时间就将这些标志置位，主循环中直接对这些标志进行判断的逻辑” 可以避免由于时间后延导致的无法触发逻辑执行问题，但仍然无法解决周期被影响的本质。

裸机编程模式/架构 5：前后台 + 状态机架构

void do_a(void) {
    static unsigned char step = 0;
    if (tick % 100 == 0) {
        switch (step) {
            case 0:
                // 执行第一步
                step++;
                break;
            case 1:
                // 执行第二步
                step++;
                break;
            case 2:
                // 执行第三步
                step = 0;
                break;
            default:
                //  未知步骤，归零重来
                step = 0;
                break;
        }
    } else {
        return;
    }
}

可以观察到原先的执行方式do_a，我们将其视为一个不可拆分的逻辑，直到完整执行完成才会退出。而现在，我们将其分解为三个步骤，在执行完一个步骤后就会退出do_a函数，在下一次进入时执行下一个步骤。这样一来，能够有效缩短每次执行do_a所需的时间，大大降低了执行时间超过最小周期的可能性。主循环中的其他应用逻辑也采用了类似的状态机模式，以加快主循环的响应效率，进一步提高了裸机编程的稳定性和时间可控性。状态机的引入使裸机编程达到了其终极形态，使其能够处理更复杂的逻辑和应用。同时，代码量和复杂度也急剧增加，特别是当主循环中存在十几个甚至几十个任务逻辑时，面对的编程难度就变得非常高。当然，即使你能够应对极高的挑战，最终仍会遇到一个问题——随着应用逻辑的增加，同时执行大量状态机分支步骤的时间总和很难再人工进行分解，而且不幸的是，它们的执行时间总和超过了预定的周期，导致了各种问题的出现。

此时恭喜你，已经达到了裸机编程的巅峰，也是裸机编程的极限。是时候迈开脚步，进入操作系统编程的领域了！