深入探讨RTOS任务调度与多任务

RTOS中协程与任务的主要区别体现在资源占用、调度方式及实现机制上：

资源占用

‌任务‌：每个任务需独立分配堆栈空间、堆空间及任务控制块，资源占用较大。 ‌

‌协程‌：所有协程共享同一线程的堆栈空间，仅需少量内存存储局部变量和状态，显著减少RAM使用。 ‌

调度方式

‌任务‌：由RTOS调度器自动管理，涉及上下文切换和内核干预。 ‌

‌协程‌：由用户代码显式控制(如调用crDELAY)，无需操作系统介入，灵活性更高。 ‌

实现机制

‌任务‌：支持抢占式优先级调度，适用于复杂系统。 ‌

‌协程‌：通过宏定义实现，仅在单线程内运行，适合内存受限的嵌入式系统。 ‌

适用场景

‌任务‌：适用于需要高可靠性和复杂任务管理的系统。 ‌

‌协程‌：适合资源受限的场景(如8/16位MCU)，可减少系统开销。

01RTOS中的协程概述在RTOS系统中，除了我们熟悉的进程和线程(在RTOS中通常被称为任务)，还存在着另一种程序模型——协程。协程，作为协同程序的简称，英文名Coroutine，以其更轻量级的特性在并发编程领域占据了一席之地。它允许在单个线程内高效执行多个协程，这些协程能够灵活地挂起与恢复，从而实现了高效的并发执行。接下来，我们将深入探讨RTOS中协程与任务的内容，并剖析它们的异同。

◇ 协程的三种状态

协程在RTOS中主要呈现为三种状态：运行、就绪和阻塞。这些状态相互转换，共同构成了协程在RTOS中的执行模型。

运行状态：当协程正在执行时，它被称为处于运行状态，此时处理器正被当前协程所使用。

就绪状态：就绪的协程是那些已经准备好执行(未被阻塞)但当前尚未执行的协程。

阻塞状态：若协程当前正处于等待时间事件或外部事件的状态，则该协程被视为处于阻塞状态。

◇ 协程与任务的区别

尽管协程与RTOS中的任务在某些方面相似，但它们之间也存在诸多差异。协程在轻量级和不需系统调度器介入方面有显著不同，灵活性更高。协程函数以crSTART开始，并以crEND结束，且该函数不应返回任何值。

从裸机到RTOS的转型，对于许多嵌入式开发者来说，确实是一个充满挑战的阶段。这个过程中，他们可能会遇到诸如临界段、调度、信号量和互斥锁等复杂概念，这些概念对于初学者来说往往让人感到困惑。然而，通过深入了解和掌握这些核心概念，他们将能够更好地理解RTOS的多任务调度机制。

▣ 多任务与调度器

多任务，相较于裸机系统的单任务或轮询模式，意味着系统能够同时处理多个任务。在RTOS中，这些任务通过调度器进行高效管理，确保每个任务都能得到及时的响应和处理。通过引入信号量和互斥锁等同步机制，RTOS能够有效地解决多任务环境下的资源竞争和同步问题，从而提升系统的整体性能和响应速度

▣ 信号量与互斥锁

了解多任务调度的原理和应用，对于嵌入式开发者来说至关重要。它不仅能够帮助他们更好地应对RTOS带来的挑战，还能够提升他们的开发效率和系统稳定性。因此，掌握多任务调度的核心概念和技巧，是每一个嵌入式开发者不可或缺的技能。

02多任务调度的原理与应用▣ 多任务定义与实现

那么，多任务究竟是什么呢?在多任务操作系统中，通过特定的任务调度策略，两个或更多进程能够并发地共享一个处理器。但需要注意的是，在任意时刻，处理器仅会为一件任务提供服务。由于任务调度机制的高效性，不同任务之间的切换速度非常快，从而产生了多个任务同时运行的错觉。

对于初学者来说，可以这样理解：多任务系统类似于我们之前提到的多个轮询系统。在代码层面，我们可以将一个大while循环中的多项任务拆分成几个小任务，分别进行处理。这样，每个任务都能得到有序且高效的处理，从而提升了系统的整体性能和响应速度。

▣ 任务切换与效率

在多任务处理中，各个任务之间的切换与调度是不可或缺的环节。然而，这种切换是否会占用大量CPU时间，从而影响任务执行效率呢?这曾经是我初学RTOS时的困惑。当时，我误以为在滴答设置1000(即1ms时间)的情况下，CPU在各个任务间频繁切换会消耗大量资源。

事实上，我那时对处理器能力的估计过于保守。以STM32F103运行72M为例，每1ms内能执行的代码量是相当可观的。深入思考后，我们会发现，任务切换所需的几行代码在CPU的高速处理能力下，其所需时间几乎可以忽略不计。当然，这主要是针对高速处理器而言。对于低频处理器，这个时间可能相对较长，但即便如此，任务调度仍然是一种高效的任务管理方式。

▣ 占抢调度与轮询调度

任务调度可分为抢占调度和轮询调度两种方式。在实时操作系统(RTOS)中，为了确保任务能够获得及时的响应，通常采用抢占调度策略。以UCOS为例，它就是一种典型的抢占式调度系统。

在程序执行过程中，一旦出现高优先级任务，它将会打断当前正在执行的低优先级任务。这种打断会持续到高优先级任务执行完毕，之后低优先级任务才会重新获得执行机会。然而，有人可能会提出疑问：如果高优先级任务长时间持续执行，这种情况是否可行?

事实上，这涉及到了任务优先级的合理分配以及任务设计的考量。通常，高优先级任务被设计为响应某种紧急事件，执行一些既紧急又不耗时的操作。而对于那些耗时较长的任务，则通常被赋予较低的优先级，在系统负载较轻时逐步处理。