第2章_freeRTOS入门与工程实践之单片机程序设计模式

本教程基于韦东山百问网出的 DShanMCU-F103开发板 进行编写，需要的同学可以在这里获取： https://item.taobao.com/item.htm?id=724601559592

配套资料获取：https://rtos.100ask.net/zh/freeRTOS/DShanMCU-F103

freeRTOS系列教程之freeRTOS入门与工程实践章节汇总： https://blog.csdn.net/qq_35181236/article/details/132842016

---

第2章 单片机程序设计模式

本章目标

• 理解裸机程序设计模式
• 了解多任务系统中程序设计的不同

2.1 裸机程序设计模式

裸机程序的设计模式可以分为：轮询、前后台、定时器驱动、基于状态机。前面三种方法都无法解决一个问题：假设有A、B两个都很耗时的函数，无法降低它们相互之间的影响。第4种方法可以解决这个问题，但是实践起来有难度。

假设一位职场妈妈需要同时解决2个问题：给小孩喂饭、回复工作信息，场景如图所示，后面将会演示各类模式下如何写程序：

2.1.1 轮询模式

示例代码如下：

// 经典单片机程序: 轮询
void main()
{while (1){喂一口饭();回一个信息();}
}

在main函数中是一个while循环，里面依次调用2个函数，这两个函数相互之间有影响：如果“喂一口饭”太花时间，就会导致迟迟无法“回一个信息”；如果“回一个信息”太花时间，就会导致迟迟无法“喂下一口饭”。

使用轮询模式编写程序看起来很简单，但是要求while循环里调用到的函数要执行得非常快，在复杂场景里反而增加了编程难度。

2.1.1 前后台

所谓“前后台”就是使用中断程序。假设收到同事发来的信息时，电脑会发出“滴”的一声，这时候妈妈才需要去回复信息。示例程序如下：

// 前后台程序
void main()
{while (1){// 后台程序喂一口饭();}
}// 前台程序
void 滴_中断()
{回一个信息();
}

• main函数里while循环里的代码是后台程序，平时都是while循环在运行；
• 当同事发来信息，电脑发出“滴”的一声，触发了中断。妈妈暂停喂饭，去执行“滴_中断”给同事回复信息；

在这个场景里，给同事回复信息非常及时：即使正在喂饭也会暂停下来去回复信息。“喂一口饭”无法影响到“回一个信息”。但是，如果“回一个信息”太花时间，就会导致 “喂一口饭”迟迟无法执行。

继续改进，假设小孩吞下饭菜后会发出“啊”的一声，妈妈听到后才会喂下一口饭。喂饭、回复信息都是使用中断函数来处理。示例程序如下：

// 前后台程序
void main()
{while (1){// 后台程序}
}// 前台程序
void 滴_中断()
{回一个信息();
}// 前台程序
void 啊_中断()
{喂一口饭();
}

main函数中的while循环是空的，程序的运行靠中断来驱使。如果电脑声音“滴”、小孩声音“啊”不会同时、相近发出，那么“回一个信息”、“喂一口饭”相互之间没有影响。在不能满足这个前提的情况下，比如“滴”、“啊”同时响起，先“回一个信息”时就会耽误“喂一口饭”，这种场景下程序遭遇到了轮询模式的缺点：函数相互之间有影响。

2.1.2 定时器驱动

定时器驱动模式，是前后台模式的一种，可以按照不用的频率执行各种函数。比如需要每2分钟给小孩喂一口饭，需要每5分钟给同事回复信息。那么就可以启动一个定时器，让它每1分钟产生一次中断，让中断函数在合适的时间调用对应函数。示例代码如下：

// 前后台程序: 定时器驱动
void main()
{while (1){// 后台程序}
}// 前台程序: 每1分钟触发一次中断
void 定时器_中断()
{static int cnt = 0;cnt++;if (cnt % 2 == 0){喂一口饭();}else if (cnt % 5 == 0){回一个信息();}
}

• main函数中的while循环是空的，程序的运行靠定时器中断来驱使。
• 定时器中断每1分钟发生一次，在中断函数里让cnt变量累加（代码第14行）。
• 第15行：进行求模运算，如果对2取模为0，就“喂一口饭”。这相当于每发生2次中断就“喂一口饭”。
• 第19行：进行求模运算，如果对5取模为0，就“回一个信息”。这相当于每发生5次中断就“回一个信息”。

这种模式适合调用周期性的函数，并且每一个函数执行的时间不能超过一个定时器周期。如果“喂一口饭”很花时间，比如长达10分钟，那么就会耽误“回一个信息”；反过来也是一样的，如果“回一个信息”很花时间也会影响到“喂一口饭”；这种场景下程序遭遇到了轮询模式的缺点：函数相互之间有影响。

2.1.3 基于状态机

当“喂一口饭”、“回一个信息”都需要花很长的时间，无论使用前面的哪种设计模式，都会退化到轮询模式的缺点：函数相互之间有影响。可以使用状态机来解决这个缺点，示例代码如下：

// 状态机
void main()
{while (1){喂一口饭();回一个信息();}
}

在main函数里，还是使用轮询模式依次调用2个函数。

关键在于这2个函数的内部实现：使用状态机，每次只执行一个状态的代码，减少每次执行的时间，代码如下：

void 喂一口饭(void)
{static int state = 0;switch (state){case 0:{/* 舀饭 *//* 进入下一个状态 */state++;break;}case 1:{/* 喂饭 *//* 进入下一个状态 */state++;break;}case 2:{/* 舀菜 *//* 进入下一个状态 */state++;break;}case 3:{/* 喂菜 *//* 恢复到初始状态 */state = 0;break;}}
}void 回一个信息(void)
{static int state = 0;switch (state){case 0:{/* 查看信息 *//* 进入下一个状态 */state++;break;}case 1:{/* 打字 *//* 进入下一个状态 */state++;break;}case 2:{/* 发送 *//* 恢复到初始状态 */state = 0;break;}}
}

以“喂一口饭”为例，函数内部拆分为4个状态：舀饭、喂饭、舀菜、喂菜。每次执行“喂一口饭”函数时，都只会执行其中的某一状态对应的代码。以前执行一次“喂一口饭”函数可能需要4秒钟，现在可能只需要1秒钟，就降低了对后面“回一个信息”的影响。

同样的，“回一个信息”函数内部也被拆分为3个状态：查看信息、打字、发送。每次执行这个函数时，都只是执行其中一小部分代码，降低了对“喂一口饭”的影响。

使用状态机模式，可以解决裸机程序的难题：假设有A、B两个都很耗时的函数，怎样降低它们相互之间的影响。但是很多场景里，函数A、B并不容易拆分为多个状态，并且这些状态执行的时间并不好控制。所以这并不是最优的解决方法，需要使用多任务系统。

2.2 多任务系统

2.2.1 多任务模式

对于裸机程序，无论使用哪种模式进行精心的设计，在最差的情况下都无法解决这个问题：假设有A、B两个都很耗时的函数，无法降低它们相互之间的影响。使用状态机模式时，如果函数拆分得不好，也会导致这个问题。本质原因是：函数是轮流执行的。假设“喂一口饭”需要t1_{t5这5段时间，“回一个信息需要”ta}te这5段时间，轮流执行时：先执行完t1_{t5，再执行ta}te，如下图所示：

对于职场妈妈，她怎么解决这个问题呢？她是一个眼明手快的人，可以一心多用，她这样做：

• 左手拿勺子，给小孩喂饭
• 右手敲键盘，回复同事
• 两不耽误，小孩“以为”妈妈在专心喂饭，同事“以为”她在专心聊天
• 但是脑子只有一个啊，虽然说“一心多用”，但是谁能同时思考两件事？
• 只是她反应快，上一秒钟在考虑夹哪个菜给小孩，下一秒钟考虑给同事回复什么信息
• 本质是：交叉执行，t1_t5和tate交叉执行，如下图所示：

基于多任务系统编写程序时，示例代码如下：

// RTOS程序
喂饭任务()
{while (1){喂一口饭();}
}回信息任务()
{while (1){回一个信息();}
}void main()
{// 创建2个任务create_task(喂饭任务);create_task(回信息任务);// 启动调度器start_scheduler();
}

• 第21、22行，创建2个任务；
• 第25行，启动调度器；
• 之后，这2个任务就会交叉执行了；

基于多任务系统编写程序时，反而更简单了：

1. 上面第2~8行是“喂饭任务”的代码；
2. 第10~16行是“回信息任务”的代码，编写它们时甚至都不需要考虑它和其他函数的相互影响。就好像有2个单板：一个只运行“喂饭任务”这个函数、另一个只运行“回信息任务”这个函数。

多任务系统会依次给这些任务分配时间：你执行一会，我执行一会，如此循环。只要切换的间隔足够短，用户会“感觉这些任务在同时运行”。如下图所示：

2.2.2 互斥操作

多任务系统中，多个任务可能会“同时”访问某些资源，需要增加保护措施以防止混乱。比如任务A、B都要使用串口，能否使用一个全局变量让它们独占地、互斥地使用串口？示例代码如下：

// RTOS程序
int g_canuse = 1;void uart_print(char *str)
{if (g_canuse){g_canuse = 0;printf(str);g_canuse = 1;}
}task_A()
{while (1){uart_print("0123456789\n");}
}task_B()
{while (1){uart_print("abcdefghij");}
}void main()
{// 创建2个任务create_task(task_A);create_task(task_B);// 启动调度器start_scheduler();
}

程序的意图是：task_A打印“0123456789”，task_B打印“abcdefghij”。在task_A或task_B打印的过程中，另一个任务不能打印，以避免数字、字母混杂在一起，比如避免打印这样的字符：“012abc”。

第6行使用全局变量g_canuse实现互斥打印，它等于1时表示“可以打印”。在进行实际打印之前，先把g_canuse设置为0，目的是防止别的任务也来打印。

这个程序大部分时间是没问题的，但是只要它运行的时间足够长，就会出现数字、字母混杂的情况。下图把uart_print函数标记为①~④个步骤：

void uart_print(char *str)
{if( g_canuse )     ①{g_canuse = 0;  ②printf(str);   ③g_canuse = 1;  ④}
}

如果task_A执行完①，进入if语句里面执行②之前被切换为task_B：在这一瞬间，g_canuse还是1。

task_B执行①时也会成功进入if语句，假设它执行到③，在printf打印完部分字符比如“abc”后又再次被切换为task_A。

task_A继续从上次被暂停的地方继续执行，即从②那里继续执行，成功打印出“0123456789”。这时在串口上可以看到打印的结果为：“abc0123456789”。

是不是“①判断”、“②清零”间隔太远了，uart_print函数改进成如下的代码呢？

void uart_print(char *str)
{g_canuse--;            ① 减一if( g_canuse == 0 )    ② 判断{printf(str);     ③ 打印}g_canuse++;          ④ 加一
}

即使改进为上述代码，仍然可能产生两个任务同时使用串口的情况。因为“①减一”这个操作会分为3个步骤：a.从内存读取变量的值放入寄存器里，b.修改寄存器的值让它减一，c.把寄存器的值写到内存上的变量上去。

如果task_A执行完步骤a、b，还没来得及把新值写到内存的变量里，就被切换为task_B：在这一瞬间，g_canuse还是1。

task_B执行①②时也会成功进入if语句，假设它执行到③，在printf打印完部分字符比如“abc”后又再次被切换为task_A。

task_A继续从上次被暂停的地方继续执行，即从步骤c那里继续执行，成功打印出“0123456789”。这时在串口上可以看到打印的结果为：“abc0123456789”。

从上面的例子可以看到，基于多任务系统编写程序时，访问公用的资源的时候要考虑“互斥操作”。任何一种多任务系统都会提供相应的函数。

2.2.3 同步操作

如果任务之间有依赖关系，比如任务A执行了某个操作之后，需要任务B进行后续的处理。如果代码如下编写的话，任务B大部分时间做的都是无用功。

// RTOS程序
int flag = 0;void task_A()
{while (1){// 做某些复杂的事情// 完成后把flag设置为1flag = 1;}
}void task_B()
{while (1){if (flag){// 做后续的操作}}
}void main()
{// 创建2个任务create_task(task_A);create_task(task_B);// 启动调度器start_scheduler();
}

上述代码中，在任务A没有设置flag为1之前，任务B的代码都只是去判断flag。而任务A、B的函数是依次轮流运行的，假设系统运行了100秒，其中任务A总共运行了50秒，任务B总共运行了50秒，任务A在努力处理复杂的运算，任务B仅仅是浪费CPU资源。

如果可以让任务B阻塞，即让任务B不参与调度，那么任务A就可以独占CPU资源加快处理复杂的事情。当任务A处理完事情后，再唤醒任务B。示例代码如下：

// RTOS程序
void task_A()
{while (1){// 做某些复杂的事情// 释放信号量,会唤醒任务B;}
}void task_B()
{while (1){// 等待信号量, 会让任务B阻塞// 做后续的操作}
}void main()
{// 创建2个任务create_task(task_A);create_task(task_B);// 启动调度器start_scheduler();
}

• 第15行：任务B运行时，等待信号量，不成功时就会阻塞，不在参与任务调度。
• 第7行：任务A处理完复杂的事情后，释放信号量会唤醒任务B。
• 第16行：任务B被唤醒后，从这里继续运行。

在这个过程中，任务A处理复杂事情的时候可以独占CPU资源，加快处理速度。

---

本章完