嵌入式RTOS到底“实时”在哪？

原创电子工程世界 2024-12-06 08:04 155浏览 0评论 0点赞

STM32玩转机械手：边缘AI开发的实战课！ 技术前沿：ADMT4000多圈传感器技术剖析与应用实践

古人云：“天时、地利、人和，缺一不可”。嵌入式RTOS（Real Time Operating System，实时操作系统）便借风起势，在最近几年大放异彩。

嵌入式MCU，早已脱离主频只有8MHz的时代，当下嵌入式主控芯片里面，主频已经可以高达600MHz，而普通MCU也可以轻松运行在64MHz。不止主频有质的飞跃，而且Arm Cortex-M系列的MCU，其在内核设计初期亦添加了支持RTOS的原生内核指令。

不过，虽然说RTOS叫“实时操作系统”，真的实时（Real-time）吗？这里的实时又指代什么？最近，EEWorld论坛的工程师围绕RTOS这一话题，进行了一次讨论，话题包括RTOS能做什么，实时性指的是是什么，根据实时性RTOS分为几种，自己对于RTOS的理解是什么。（原帖地址：https://www.eeworld.com.cn/a0a54CC）

付斌｜编辑

电子工程世界（ID：EEworldbbs）｜出品

搞清裸机、RTOS、GPOS

想要搞清楚RTOS的“实时”，先要明白目前嵌入式领域三种开发形式——裸机开发（Bare Metal）、RTOS、GPOS（General-Purpose Operating System，通用操作系统），其主要特点如下：

裸机：裸机系统不使用操作系统。相反，应用程序代码直接在硬件上运行，无需操作系统支持，代码可以直接与硬件交互并访问硬件。裸机开发在资源受限的场景效果非常好，比如8位、16位MCU，或者只有32KB闪存、2KB RAM时。当然，资源很丰富时候也可以采用裸机开发，就比如系统拥有高度的实时要求。目前，EEWorld论坛便拥有许多青睐于在裸机上开发的工程师。

RTOS：顾名思义，旨在为实时应用程序提供服务，这些应用程序提供可预测的执行时间和时间敏感型应用程序，其的关键特征在于响应性和确定性。相比裸机，RTOS更方便。要使用RTOS，系统应至少拥有 64 KB闪存、4 KB RAM和80 MHz或更高的处理器时钟。

RTOS通常用于比裸机更复杂时序要求的系统，通常需处理TCP/IP、MQTT、USB、Wi-Fi 等通信堆栈时管理实时需求。虽然裸机也能开发这种系统，但RTOS可以简化设计，加快上市时间，并使软件维护更容易。RTOS的另外关键点在于软件开发添加的功能，如务管理、任务同步、调度和任务间通信。RTOS允许考虑相互抢占的任务，从而允许更复杂的应用程序设计。

GPOS：主要包括Linux、Windows等，旨在运行各种软件应用程序。这些操作系统专为用户交互而设计，提供某种界面，无论是命令行界面（CLI）还是图形用户界面（GUI），旨在运行多个应用程序（通常具有多线程），并提供其他优势，例如资源/文件管理和设备驱动程序。用户交互通常是 GPOS 设计的主要关注点，因此一些延迟是可以接受的。同时，硬件也通常是32位以上处理器，主频达到200MHz以上，闪存达到数兆。

因为Linux本身比较复杂，所以也诞生了介于RTOS和Linux之间的实时Linux（如Ubuntu的实时Linux）。实时Linux的核心概念是“抢占”，也就是中断当前执行线程，立即处理优先级较高的事件。RTOS和实时Linux之间的选择取决于系统特定延迟要求，以及对开销和资源效率的需求。虽然实时Linux为许多场景提供了强大的解决方案，但在某些关键的嵌入式系统中，专用 RTOS可能仍然更可取。如果项目需要在实时需求和运行各种应用程序的灵活性之间取得平衡，那么实时Linux将提供更通用的解决方案。

RTOS不能做什么

从裸机到RTOS，实际上工程师会存在许多困惑，EEWorld论坛中，工程师jorya_txj就曾用自己过去的经历，诉说自己对于RTOS的理解：

他表示，目前接触了几位从裸机转向RTOS的人士，接触了一些项目，有一些感想，对于不了解RTOS的人，可能感觉这个东西很神秘，能解决任何裸奔解决不了的事情，可事情往往不是这样的。

裸奔只做一件事情是最有效率的，如果干一件事情裸奔都很吃力，rtos解决不了硬件负债的事情，相反使用rtos会更差。举例说明，假设系统有一个20us频率的中断在cortex-m3 上面，中断内最大耗时10us。那中断内留给rtos的只有10us了，这10us内还需要调用rtos的队列发送api。虽然有的系统能响应20us中断，但是保证不了10us内能完成api的调用以及出中断处理。即使能保证，外面任务的执行效率将会很差很差。

绝大部分的RTOS做不了1us以内的中断响应。也就是说中断发生了之后，需要1us就能处理用户的中断函数。

上面两个例子只能从硬件设计上去着手，从根本上去解决这个问题。比如第一个问题可以采用专用的芯片或者控制器去降低中断的频率。第二个问题可以采用FPGA去完成精确地定时等等。

RTOS更像一个军队管理决策者，而不是一个冲锋在前面的勇士。一个系统越趋向复杂RTOS的优势越大，一个系统越趋向简单，ROTS越无用武之地。RTOS很多时候不是救命稻草,硬件设计的问题还是需要硬件设计去解决，不能侥幸带到软件这边去解决，即使软件侥幸能解决这一次，下一次可能又解决不了了，不具备通用性。

关于实时，工程师的疑问

EEWorld论坛上，资深工程师辛昕曾发帖专门讨论过这样的问题——“实时”到底是什么。

当有人问他，“实时”到底是啥时，他一股脑地回答道：“就是反应快呗，比如打开网页，最好是1ms都不要等......”但得来的回应是连实时是啥都不懂。实际上，实时性是指在规定的时间内响应，而不是说什么越快越好。

根据响应时间在微秒、毫秒和秒级的不同，系统的实时性响应分为三种，RTOS属于硬实时：

第一种是硬实时（Hard real-time），是对即时的事件作出反应，绝对不能错过事件处理时限，任何错过的最后期限视为系统故障。就是接近我们平素谈到的RTOS的及时响应，它不是强调反映有多快，而是要在规定的死限时间之前完成就可以了。
第二种是软实时（Soft real-time），是允许经常错过最后期限，只要任务及时执行，它们的结果就会继续有价值。接近WINDOWS、Linux桌面版这类常用系统，软实时是指统计意义上的实时，一般整体吞吐量大或整体响应速度快，但不能保证特定的任务在指定的时间内完成。
第三种是准实时（Firm real-time），即使系统未能满足最后期限，可能不止一次（即对于多个请求），系统也不会被视为失败。此外，一旦特定请求的截止日期已过，对请求的响应（对查询的答复、任务的结果等）将毫无价值（在截止日期之后结果的有用性为零）。

其他工程师则对实时也有自己理解。他们认为，实时就是系统对事件的响应时间能满足需求，这样就可以看作是实时，因为事件总是能够在限定的时间内得到响应处理。具体的说，每一个事件的响应时间，跟现实时间是确定关系。在正常工作环境中，不会出现不确定，这样的系统就叫做实时系统。

所以，可以说，所谓的实时，并非真的实时。知名嵌入式工程师StrongerHuang也同样写过：严格来说，RTOS也不是实时响应并处理紧急的事情，只是在很短时间（一般ms级别）就做出了响应，给人感觉就是实时在响应。

比如说，RTOS实时响应的重要配置系统滴答（SysTick），按理来说，系统滴答值（节拍）越大响应越快，但系统调度也需要占用时间，所以，滴答值也不是越大越好。再比如，用中断就能做到实时响应，但硬件中断只能做出一个“紧急通知”，不能做出（耗时的）执行动作。

另据其他工程师分享，RTOS的实时是指时间可控，能在某个需求时间窗口内执行完成。而不是指立刻执行，所以RTOS是实时操作系统。硬件中断退出后立即执行高优先级任务，所以优先级配置合理的话，能在us甚至ns级响应。其实写得好得裸机响应跟RTOS差不多，但RTOS最大的优势在于任务调度，当功能复杂时可以通过操作系统调度而不用担心任务冲突。

RTOS的四种分类

实际上，RTOS本身也会按响应级别分为四种类型，它们用于不同类型的嵌入式系统：

1.硬实时操作系统（Hard RTOS）：硬实时操作系统广泛用于负责处理关键任务和要求精确时间限制的嵌入式解决方案。这意味着某些事件必须在预定的时刻执行，而不是早或晚一秒执行，因为这会导致严重问题甚至对系统造成物理损坏。案例包括汽车巡航控制和铁路信号系统。

2. 软实时操作系统（Soft RTOS）：软实时操作系统适用于嵌入式系统，其中缺少预定义的时间限制不会严重影响相关流程和整体系统运行。它允许设置执行特定任务的时间截止日期，但错过这些截止日期不会停止系统运行。例如机上娱乐和语音聊天应用程序。

3. 准实时操作系统（Firm RTOS）：准实时操作系统是硬RTOS和软RTOS的中间地带，其工作原理如下：使用准RTOS时，系统任务可能会错过最后期限，而不会对流程和系统运行产生影响。然而，可以错过的任务数量是有限的，如果它们超过允许的数量，将导致严重的系统错误和延迟。例子包括机器人装配线和电信网络。

4. 确定性实时操作系统（Deterministic RTOS）：确定性实时操作系统与时序必须始终精确的嵌入式系统完美匹配。这种类型的实时嵌入式编程允许预测执行不同优先级和复杂性的任务所需的时间。确定性调度将使我们能够设置准确执行关键任务的时间框架。它使嵌入式系统运行可预测、稳定可靠。