如何判断一个项目是否需要使用RTOS

本文简单介绍了什么是RTOS，并给出了系统化地权衡一个项目是否需要使用RTOS的方法，最后列举了一些国际国内主流的RTOS系统

Mooney_yuan

1503人浏览 · 2025-04-28 17:18:45

Mooney_yuan · 2025-04-28 17:18:45 发布

文章目录

1 从什么是 RTOS 说起

提到 RTOS，不论是网上搜索，AI 的回答，又或者书本上的答案，跟下面的回答大同小异。

RTOS 即实时操作系统（Real - Time Operating System），是一种能够在指定或确定的时间内完成系统功能和对外部或内部、同步或异步事件做出响应的操作系统。以确定性，多任务调度和实时响应为关键特征，广泛应用于嵌入式系统和实时控制场景。

1.1 关键特性

确定性: 可预测的任务执行时间，避免延迟不确定性
多任务处理: 支持并发任务执行，每个任务具有独立优先级
资源管理: 高效管理硬件资源（如内存、处理器时间），提供同步机制（信号量、互斥量）
低延迟中断处理: 快速响应外部事件，保障实时性

1.2 应用场景与优势

典型应用领域：工业自动化、医疗设备、汽车电子（如自动驾驶控制系统）、航空航天等
开发优势：
- 提高系统可靠性：通过任务隔离减少逻辑耦合
- 增强开发效率：提供标准组件（如 FreeRTOS的网络协议栈、文件系统），缩短开发周期
- 发挥硬件潜力：充分利用32位CPU（如 STM32）的多任务能力

如果你第一次听说 RTOS，或者说不太了解 RTOS，对上面提到的内容肯定一头雾水，不知所云。事实上，RTOS 所指十分宽泛，几乎囊括了除 Android，WCE，Linux 等大型操作系统外，所有运行在嵌入式硬件上的操作系统，包括RT Linux（Linux 变种，针对实时应用设计）。从简单的只包含内核，到复杂的包含文件系统，协议栈，程序框架，测试框架等。可支持的硬件从 8 位到 16 位，到 32 位，64 位，arm ，mips，risc-v，avr，ia32… 几乎所有 CPU体系架构。随便列举一些常见的 RTOS，VxWorks，QNX，uClinux, Zephyr, uC/OS-II, FreeRTOS, Nuttx, RT-thread, Lite-OS…

对于没有任何基础开发框架的项目来说，用还是不用 RTOS，这是个问题。而如果决定要用 RTOS，就涉及到选哪个 RTOS ，这是个更令人头疼的问题。看上去，前者是个 2选 1的问题，后者是个 n 选 1 的问题。不过，从本质上来说，把不用操作系统（裸机系统）看作选项 A，其它所有待选 RTOS 看作其它选项之一，这两个问题其实是一个问题。

A: 裸机（无 RTOS）
B: RTOS 1
C: RTOS 2
D: RTOS 3
…

2 缩小范围

对于一个项目来说，应用的复杂度决定了选用什么样的芯片，最终决定适用什么样的系统。通常来说，当你在衡量要不要用 RTOS 时，项目通常不会是很复杂的应用，以 Arm 系列微处理器举例，通常是Arm cortex M0，M3，M4 同级水平，ROM 空间在 20k~512k 之间，RAM 空间在 8k~64k 之间。低于这个级别的芯片通常不会用操作系统，高于这个级别的通常都会用到 RTOS。对于那些 cortex-a 及以上级别的芯片，一般原厂会提供带操纵系统（RTOS 系统或 Linux 等非实时系统）的BSP，免去选择系统的困恼。

前文提到，RTOS 范围极广，简单的只有内核，复杂的带设备框架，文件系统，协议栈，UI 框架等。当你的应用需要用到文件系统，协议栈等高级组件，那么，不用考虑用还是不用，选用一个功能丰富一点的RTOS ，比直接裸机开发更明智。

本文要权衡的是裸机和简单的 RTOS （只有内核功能）之间的选择。

3 RTOS 内核的功能

不同的 RTOS 实现方式和使用方法可能有比较大的差别，但通常包含下面这些功能。

3.1 线程管理

线程的创建，初始化，启动，运行，调度

3.2 时钟管理

系统时钟节拍，定时器

3.3 线程同步和通信

信号量，互斥量，事件集，邮箱，消息队列

3.4 内存管理

内存堆管理，内存池

4 裸机程序对比 RTOS 应用程序

4.1 裸机程序

裸机程序由中断服务程序和 main 主程序组成，通常采用主循环或者简单的状态机来执行任务，多为单个任务或者多个任务，各任务按顺序依次执行。各任务以及中断服务程序之间通常靠全局变量或者自定义函数接口通信。

另外，裸机程序通常不会启用线程堆栈（如果需要用到这个高级功能，应该选用 RTOS），中断服务程序和主程序用同一个堆栈（stack）。

下面是一个常见的裸机程序框图。

在这里插入图片描述

4.2 RTOS 应用程序

RTOS 应用程序由 RTOS 系统，中断服务程序，任务线程组成。通常来说，RTOS 一定会包含一个 systick 中断服务程序（提供 RTOS 的时钟），以及 PendSV 服务程序（用于线程上下文切换）。任务线程可设置不同的优先级，支持多任务并发执行。系统会根据不同的优先级进行调度。任务线程以及中断服务之间可通过操作系统提供的 API 进行同步和通信。

上电初始化程序和中断服务使用主堆栈，每个线程使用该线程自己的堆栈（相比于裸机系统，线程堆栈是多出来的内存开销）。

下面是一个常见的 RTOS 应用程序框图

在这里插入图片描述

5 RTOS 内核的开销

不同的 RTOS 内核，根据功能的复杂和丰富程度，所需的 ROM 和 RAM 资源差别比较大。简单的 RTOS 内核 ROM 和 RAM 开销非常小。以国产 RTOS rt-thread Nano 举例，最低只需要 3k ROM 和 1.2k RAM。同等功能下，FreeRTOS，ThreadX 等所需资源跟这个差不多。

6 权衡

判断一个项目是否应该使用实时操作系统（RTOS）需要综合考虑项目的功能需求、硬件资源、开发复杂度以及实时性要求。以下是一个系统化的评估方法，涵盖关键因素和决策流程，帮助你决定是否需要RTOS：

6.1. 评估实时性需求

实时性是RTOS的核心优势，分为硬实时、软实时和非实时。以下问题可以帮助判断实时性需求：

任务是否有严格的时间约束？
- 硬实时：任务必须在固定截止时间（deadline）内完成，否则可能导致系统失败（如汽车ABS系统、医疗设备）。RTOS适合此类场景，因其提供确定性调度。
- 软实时：任务偶尔延迟可接受，但需尽量满足时间要求（如流媒体播放、工业传感器）。RTOS通常适用，但裸机（Bare-metal）方案也可考虑。
- 非实时：无严格时间约束（如简单的数据记录）。裸机或简单循环轮询可能更合适。
是否存在多个并发任务？
- 如果系统需要同时处理多个任务（如通信、数据采集、用户界面），RTOS的多任务调度（线程、优先级抢占）能简化开发并确保任务按优先级执行。
- 单任务或顺序执行的简单系统可能无需RTOS。

示例：一个无人机控制系统需要同时处理传感器数据、电机控制和通信，硬实时要求高，适合使用RTOS（如ThreadX、FreeRTOS）。而一个简单的温湿度记录器，任务单一，裸机即可满足。

6.2. 分析硬件资源约束

RTOS会引入额外的开销，需确保硬件支持。评估以下因素：

内存资源：
- RTOS内核和任务管理需要一定的ROM和RAM。例如，ThreadX最小占用约2KB ROM和1KB RAM，FreeRTOS类似。
- 检查微控制器（MCU）的Flash和RAM容量是否足够支持RTOS及其任务栈。资源极低的设备（<16KB Flash）可能更适合裸机。
处理能力：
- RTOS的上下文切换和调度需要CPU性能支持。低端8位MCU（如8051）可能难以高效运行RTOS，而32位MCU（如ARM Cortex-M、RISC-V）更适合。
外设需求：
- 如果项目涉及复杂外设管理（如DMA、定时器、中断），RTOS的线程模型能简化中断处理和资源共享。

示例：一个基于STM32F4（168MHz，192KB RAM，1MB Flash）的物联网网关可以轻松运行RTOS，而一个ATtiny85（8KB Flash，512B RAM）可能因资源不足更适合裸机。

6.3. 考虑系统复杂度和开发效率

RTOS通过任务分解和模块化设计提高开发效率，但也增加学习和调试成本。评估以下方面：

任务数量和复杂性：
- 如果系统有多个独立功能模块（如通信协议栈、GUI、数据处理），RTOS的任务管理能降低代码耦合，提高可维护性。
- 简单系统（1-2个任务）用裸机的主循环加中断即可，RTOS可能增加不必要的复杂性。
开发团队经验：
- 如果团队熟悉RTOS（如FreeRTOS、RT-Thread），使用RTOS可加速开发；若团队缺乏经验，学习曲线可能延长开发周期。（考虑一下，学习投资是一次性的，受益却是终身的）
可重用性和可扩展性：
- RTOS提供标准化的任务管理和中间件（如文件系统、TCP/IP协议栈），便于代码复用和未来扩展。
- 裸机代码通常高度定制，扩展性较差。

示例：一个智能家居中心需要集成Wi-Fi、BLE、传感器和云连接，任务多且需扩展，RTOS能简化开发。而一个简单的LED闪烁控制器，裸机实现更直接。

6.4. 评估功耗需求

功耗是嵌入式系统的关键因素，尤其在电池供电设备中：

低功耗场景：
- 裸机通过精确控制休眠和唤醒可实现极低功耗，适合超低功耗设备（如传感器节点）。
- 现代RTOS（如ThreadX、Zephyr）支持低功耗模式（如tickless模式），但调度开销可能略增加功耗。
任务调度对功耗的影响：
- RTOS的任务切换可能导致频繁唤醒，增加功耗。需评估任务调度频率是否影响功耗目标。
硬件支持：
- 检查MCU是否支持低功耗模式（如Sleep、Deep Sleep），以及RTOS是否能有效利用这些模式。

示例：一个电池供电的智能手表需长时间运行，裸机可能更易优化功耗；但如果手表需处理复杂UI和通信，RTOS的低功耗模式（如FreeRTOS的tickless idle）仍可满足需求。

6.5. 检查安全性和可靠性要求

RTOS在安全关键型应用中有优势：

安全认证：
- 如果项目需符合行业标准（如ISO 26262汽车、IEC 61508工业），RTOS（如ThreadX、QNX）提供预认证内核和文档，降低合规成本。
- 裸机实现需自行验证，成本和风险较高。
任务隔离：
- RTOS通过任务优先级和内存保护（如ThreadX的MPU支持）提高系统稳定性，防止单一任务故障影响全局。
- 裸机系统通常缺乏隔离，调试和错误恢复更复杂。
容错性：
- RTOS支持看门狗、错误处理和任务监控，便于构建高可靠性系统。

示例：一个汽车ADAS系统需硬实时和高可靠性，ThreadX的认证和任务隔离使其成为理想选择；而一个DIY玩具项目无需认证，裸机更简单。

6.6. 考虑生态和中间件支持

RTOS通常提供丰富的生态支持，适合复杂项目：

协议栈和库：
- RTOS常集成中间件，如ThreadX的NetX（TCP/IP）、FileX（文件系统），或FreeRTOS的AWS IoT SDK，简化联网和存储开发。
- 裸机需手动实现或移植协议栈，增加工作量。
硬件生态：
- 检查目标芯片是否预集成RTOS（如STM32的Azure RTOS包），或是否有现成的BSP（板级支持包）。
- 国产芯片（如全志、兆易创新）常支持RT-Thread，生态适配更好。

示例：一个需要MQTT协议的物联网设备可利用ThreadX的NetX Duo快速开发，而裸机需自行移植lwIP，开发周期长。

6.7. 权衡成本和开发周期

开发成本：
- RTOS的中间件和工具链可缩短开发时间，但学习和调试可能增加初期成本。
- 裸机开发初期简单，但复杂项目后期维护成本可能更高。
授权成本：
- 开源RTOS（如ThreadX、FreeRTOS）免费，商业RTOS（如VxWorks）可能需授权费。
- 安全认证文档（如ThreadX的IEC 61508）可能需额外购买。
调试工具：
- RTOS支持图形化调试工具（如ThreadX的TraceX），便于分析任务行为；裸机调试通常依赖基本工具（如JTAG）。

6.8. 决策流程总结

以下是一个简化的决策树，帮助判断是否使用RTOS：

实时性：是否有硬实时或软实时需求？
- 是 → 倾向于RTOS。
- 否 → 考虑裸机。
任务复杂性：是否有多个并发任务或复杂功能？
- 是 → RTOS更高效。
- 否 → 裸机可能足够。
硬件资源：Flash和RAM是否支持RTOS开销？
- 是 → RTOS可行。
- 否 → 选择裸机。
功耗：是否为超低功耗设备？
- 是 → 优先裸机，或选择支持tickless的RTOS。
- 否 → RTOS适用。
安全/可靠性：是否需要认证或高可靠性？
- 是 → 选择带认证的RTOS（如ThreadX）。
- 否 → 视其他需求决定。
生态支持：是否需要协议栈或快速开发？
- 是 → RTOS的中间件有优势。
- 否 → 裸机可考虑。

6.9. 实际案例分析

适合RTOS的场景：
- 智能门锁：需处理BLE通信、触摸屏、指纹识别，软实时，RTOS（如RT-Thread）简化多任务管理。
- 汽车ECU：硬实时，需ISO 26262认证，ThreadX或QNX是优选。
适合裸机的场景：
- 简单LED控制器：单任务，定时闪烁，裸机主循环即可。
- 低功耗传感器：仅周期性采集数据，裸机优化休眠更高效。

6.10 建议

如果你不确定是否需要RTOS，可以：

原型验证：先用裸机实现最小功能，评估实时性和复杂性。若发现任务冲突或代码难以维护，再引入RTOS。
选择轻量RTOS：如 Rt-Thread 或FreeRTOS，内存占用小，易于移植，降低试错成本。
参考硬件厂商：检查芯片SDK是否推荐特定RTOS（如STM32支持ThreadX，国产MCU支持RT-Thread），利用现成资源加速开发。
咨询社区：在GitHub或论坛（如FreeRTOS论坛、RT-Thread社区）描述项目需求，获取选型建议。

附录：主流嵌入式 RTOS 列表

国际主流 RTOS

开源类

FreeRTOS
由 Richard Barry 创建，是目前应用广泛的免费开源 RTOS。特点是源码公开、可移植、可裁减、调度策略灵活，能方便移植到多种单片机。遵循 MISRA - C 标准规范代码，具备堆栈溢出检测等功能。广泛用于智能家居、工业自动化、医疗设备、物联网等领域
Nuttx
首个版本于 2007 年发布，是高度可定制的开源 RTOS ，采用模块化设计，核心由不同组件构成。支持从 8 位到 64 位的微控制器环境，遵循 Posix 和 ANSI 标准，小米的物联网嵌入式软件平台 Vela 就基于 NuttX 打造。
Zephyr
2016 年由英特尔、新思科技、恩智浦半导体等公司发起的开源 RTOS 项目，现由 Linux 基金会管理。最初代码来自风河（其 VxWorks 在工业和航空航天领域影响力大），具备低功耗、支持多种硬件平台等特性，适用于物联网设备开发。
RTEMS
开源、支持多处理器，兼容POSIX标准，适用于复杂实时场景。
ThreadX
ThreadX（现为 Eclipse ThreadX）自2023年11月起由微软捐赠给Eclipse基金会，并以 MIT许可证开源。ThreadX RTOS以其高效、小巧和可靠著称，具备以下关键特性：轻量级设计，小内存占用，核心代码占用仅 2KB ROM，堆栈需求低至 1KB RAM。快速上下文切换，亚微秒级上下文切换速度，优化实时性能。通过多项安全认证。模块化生态。垮平台，支持主流 32/64 位微处理器。

商业类

VxWorks
由美国 WindRiver 公司 1983 年设计开发，是硬实时操作系统。具有高性能内核 Wind，实时性好且可裁减，有友好开发调试环境、较好兼容性，支持多开发和运行环境。在航空航天、国防、工业自动化等对实时性和可靠性要求极高领域应用广泛，如 KUKA、ABB 机器人控制。
QNX
诞生于 1980 年，是商用的遵从 POSIX 规范的类 Unix 嵌入式实时操作系统，现属黑莓公司。核心仅提供进程调度、进程间通信、底层网络通信和中断处理 4 种服务，进程在独立地址空间运行。是全球首款通过 ISO 26262 ASIL level D 安全认证的车载操作系统，在汽车电子、医疗设备等行业常用。
uC/OS（uC/OS II）
商业RTOS（有免费版本），Micrium开发，适合中小型项目。简单易用，代码紧凑。应用嵌入式设备、消费电子。
*RTX*
ARM 公司的嵌入式实时操作系统，使用标准 C 结构编写，运用 RealView 编译器编译。不仅是实时内核，还具备丰富中间层组件，免费且代码开放。适用于 ARM 和 Cortex - M 设备，支持时间片、抢占式和合作式调度。
eCOS
基于 GNU 的 RTOS ，含 TCP/IP 和文件系统，其内核可配置且用 C++ 书写。曾由 Redhat 拥有，现由 eCOcentric 维护，在消费电子等领域有应用。
embOS
具备多任务管理、实时性好等特点，提供多种通信和同步机制，可用于工业控制、汽车电子等领域。

国产主流 RTOS

RT-Thread
开源、轻量级、组件丰富，支持多种芯片架构（如ARM、RISC-V）。社区活跃，文档完善，提供中间件（如网络协议栈、文件系统），支持国产芯片如全志、兆易创新。应用：物联网、智能家居、工业控制、消费电子。
SylixOS
开源、微内核架构，强调高可靠性与实时性，支持多核处理器。自主研发，符合POSIX标准，支持国产CPU（如飞腾、龙芯），适用于安全关键场景。应用：航空航天、轨道交通、电力系统。
Huawei LiteOS
开源、轻量级，专为物联网设计，低功耗、小内存占用。华为生态支持，与鸿蒙系统（HarmonyOS）兼容，适合资源受限设备。应用：智能穿戴、智慧城市、物联网终端。
AliOS Things
开源，阿里巴巴开发，针对物联网设备，支持多种通信协议。与阿里云无缝集成，支持RISC-V等架构，生态丰富。应用：智能家居、智慧城市、工业物联网。
KylinOS (麒麟 RTOS)
商业RTOS，基于银河麒麟操作系统，强调安全性与自主可控。支持国产芯片（如龙芯、飞腾），满足高安全等级需求，广泛用于政府与军工领域。应用：国防、政务、工业控制。
TencentOS tiny
开源、轻量级，腾讯开发，针对物联网和嵌入式设备。低功耗，支持多种国产MCU，与腾讯云生态结合。应用：智能设备、物联网终端。
OpenHarmony（开放鸿蒙）
开源，华为主导，分布式架构，兼具RTOS与通用OS特性。支持多种设备类型，适配国产芯片，社区发展迅速。应用：智能终端、物联网、汽车电子。