传统实时操作系统

FreeRTOS

FreeRTOS 运行条件

主频: < 10 MHz
内存: ~0.5 KB - 2 KB
Flash占用:~4 KB - 9 KB

FreeRTOS发展史

2003 年，当时的嵌入式操作系统市场大多被 VxWorks、ThreadX、QNX 等昂贵的商业系统霸占。对于那些资源极小（几 KB RAM）的单片机来说，缺乏一个真正轻量、好用且免费的开源操作系统。

在航空航天和工业控制领域有着丰富经验的软件工程师 Richard Barry 决定自己动手。他创立了 Real Time Engineers Ltd.，并在 2003 年发布了 FreeRTOS 的第一个版本。
FreeRTOS的核心竞争力:

1. 极度精简： 核心代码基本上只有三个 C 语言文件（tasks.c、queue.c、list.c），非常容易看懂。
2. 高可移植性： Richard 刻意把与 CPU 架构相关的代码（汇编部分）和核心逻辑完全剥离，这使得 FreeRTOS 能极其容易地移植到各种乱七八糟的单片机上。
3. 聪明的开源协议： 早期采用了修改版的 GPL 协议。它强制你如果修改了 FreeRTOS 内核就必须开源，但允许你的业务应用代码闭源。这彻底打消了商业公司白嫖时“代码被强制开源”的恐惧。

随着越来越多的芯片原厂（如 ST、NXP、Microchip）在他们的官方 SDK 里默认集成 FreeRTOS，它迎来了爆发式增长，成为了单片机领域的“隐形霸主”。后来为了能够让开源的FreeRTOS能够有钱发展下去, 理查德授权 WITTENSTEIN 公司推出了 OpenRTOS（其实就是 FreeRTOS 的商业收费版，买的是服务和免责）, 后来把 FreeRTOS 的代码重写、严密测试并送去认证, 以符合医疗、汽车和航空航天领域的高安全认证标注，推出了高价的 SafeRTOS.
2017 年末，AWS 宣布全面接管 FreeRTOS 项目, 创始人入职 AWS, AWS 在纯净的 FreeRTOS 内核之上，暴力塞入了一整套物联网组件（包括 OTA 升级、加密库、MQTT 协议栈、Wi-Fi 抽象层等），让单片机“开箱即用”地直连 AWS IoT 云.

Azure RTOS ( ThreadX )

运行条件:

主频:  <10 MHz
内存: 1 KB
Flash占用: 2 KB

在 1990 年代初，比尔·拉米开发了一款非常著名的商业 RTOS 叫做 Nucleus（后来卖给了 Mentor Graphics）。但他对 Nucleus 的架构并不满意，觉得它还不够快、不够小。

1996 年，他离开老东家，创立了 Express Logic 公司，并从零开始用极其硬核的 C 语言写出了一个全新的操作系统——ThreadX。

它的核心杀手锏：皮内核 (Picokernel) 架构
当时其他 RTOS 采用的都是微内核（Microkernel），而 ThreadX 创造了“皮内核”的概念。它的代码高度模块化，像搭积木一样，如果你不用某个功能，它连一行多余的汇编代码都不会被编译进去。这让它能在 2KB 的 Flash 和 1KB 的 RAM 中实现极速的上下文切换，且中断响应速度在业内几乎没有对手。

凭借着极其变态的性能、完美的免版税商业授权模式（按项目买断），以及全套通过了最高级别安全认证（航空级 DO-178B、汽车级 ISO 26262、医疗级 FDA 等）的代码，ThreadX 迎来了长达 20 年的疯狂扩张。

在这个阶段，它不靠开源出名，而是靠直接搞定全球最顶级的芯片原厂：

高通 (Qualcomm) 的御用系统： 高通把 ThreadX 直接烧录进了它所有的基带芯片（Modem）里。这意味着全球绝大多数的 4G/5G 手机，只要处理底层射频和通信，跑的都是 ThreadX。

惠普 (HP) 的全线打印机： 数以亿计的惠普打印机主控跑的是 ThreadX。

树莓派 (Raspberry Pi) 的幕后大佬： 很多人以为树莓派跑的是 Linux，但实际上，树莓派上电后的第一秒，是它内部的 VideoCore GPU 先启动，而这个 GPU 跑的就是 ThreadX！ThreadX 启动后，才会去加载并引导 Linux 跑在 ARM 核心上。

在这个阶段，ThreadX 的全球部署量突破了 62 亿台，是世界上装机量最大的 RTOS 之一。

时间来到 2017 年，亚马逊 (AWS) 霸气收购了 FreeRTOS，试图从底层单片机端直接垄断物联网（IoT）的数据入口。

这让云服务市场的万年老二 微软 (Microsoft) 极其焦虑。微软的 Azure 云平台急需一个能在端侧与 Amazon FreeRTOS 抗衡的武器。微软看了一圈，普通的开源系统看不上，直接把目光锁定了当时工业界最强、装机量最大的商业 RTOS——ThreadX。

2019 年 4 月，微软豪掷千金，全资收购了 Express Logic。

微软将 ThreadX 以及它配套的牛逼组件（文件系统 FileX、网络栈 NetX、图形界面 GUIX）全部打包，改名为 Azure RTOS。

微软的策略是：如果你使用 Azure 云服务，或者使用 ST、NXP 等合作厂商的特定芯片，你可以免费使用 Azure RTOS。
微软收购后的几年里，发现了一个残酷的现实：现在的开发者已经被 FreeRTOS 和 Linux 惯坏了，哪怕是“部分免费”或者“附带条件的免费”，大家也不愿意用。 开发者更愿意选择完全纯粹的开源系统（如 Zephyr 或 FreeRTOS），导致 Azure RTOS 在新兴的开源物联网生态中一直被边缘化。

2023 年 11 月，微软做出了一个震惊整个嵌入式圈子的决定：

微软宣布将 Azure RTOS 完整捐赠给开源非营利组织 Eclipse 基金会。

系统正式更名为 Eclipse ThreadX。

最震撼的是授权协议： 它全面改用了极其宽松的 MIT 协议！

这意味着，曾经只有波音公司、高通、惠普花几十上百万美元才能买到的，经过人类最高级别医疗和航空安全认证的顶级 RTOS 源码，现在完全免费、毫无保留地开放给了全世界的每一个普通开发者。你哪怕用它做产品卖了几个亿，也不需要给微软或任何人交一分钱。
我们再去审视 ThreadX（Azure RTOS），它的标签已经变成了：工业界被验证得最充分、性能最强悍、全家桶组件极其完善的免费开源系统。

对于学习者和开发者来说，这是这个时代最大的红利。如果你已经掌握了 FreeRTOS 的基础，完全可以去尝试把玩一下 Eclipse ThreadX，去感受一下当年价值百万美元的商业内核代码.

μC/OS-II / III

μC/OS-II / III运行条件:

主频:  10 MHz
内存: 1.5 KB
Flash占用: 2.5 KB

μC/OS-II / III 发展史

在嵌入式操作系统的世界里，μC/OS 享有极其崇高的地位。它曾是无数老一辈嵌入式工程师的启蒙恩师，被称为“代码写得最像艺术品的 RTOS”
1992 年, 当时的 Jean J. Labrosse 是一名词名极其严谨的软件工程师。他发现在开发嵌入式设备时，市面上的商业 RTOS（如 VxWorks）极其昂贵，而且全都是闭源的黑盒，出了 Bug 根本无从查起. 于是，他决定自己写一个。他不仅写了代码，还做了一件极其伟大的事：他把每一行代码的原理、数据结构的流转，写成了一本厚厚的书——《MicroC/OS: The Real-Time Kernel》
它拥有两项核心优势:

1. 极致的代码规范： Labrosse 患有严重的“代码洁癖”。μC/OS 的源码有着极其变态的对齐规范、完善的注释、清晰的变量命名（前缀法）。
2. 教科书式的传播： 由于附带了一本极其详尽的原理书籍，全世界的高校（包括中国几乎所有的理工科大学）瞬间把它作为了“嵌入式操作系统”这门课的官方教材。一整代的中国嵌入式工程师，都是看着《嵌入式实时操作系统 μC/OS-II》这本书入行的。

1998 年，Labrosse 成立了 Micrium 公司，推出了极其著名的 μC/OS-II.
在这个阶段，μC/OS-II 走上了一条与 FreeRTOS 完全不同的道路：追求极致的确定性和安全性。

为了保证系统绝对不会崩溃，μC/OS-II 做出了一个非常硬核的限制：不支持时间片轮转调度。 它要求系统里的每一个任务都必须拥有绝对唯一的优先级（最多支持 64 或 256 个任务）。高优先级任务没执行完，低优先级任务哪怕饿死也得等着。

满级安全认证： 这种严苛的确定性，让它极其顺利地通过了美国联邦航空管理局（FAA）的 DO-178B 最高级别认证，以及医疗、核工业的安全认证。

商业模式的巅峰与隐患：
在这个时期，可以免费下载它的源码来学习（Source-available），但如果要把产品卖钱，必须向 Micrium 缴纳高昂的商业授权费。在那个大家都习惯花钱买软件的年代，Micrium 赚得盆满钵满。

随着硬件性能的提升，原来 μC/OS-II 的很多硬性限制开始让人觉得不爽了。于是 2009 年，Micrium 推出了大版本更新的 μC/OS-III。

技术的巅峰： μC/OS-III 终于支持了同优先级任务的时间片轮转（Round-Robin），任务数量不再受限，中断处理机制也变得更加现代和高效。

但此时，危机已经悄然降临：
物联网（IoT）时代爆发了。成千上万的初创公司和智能硬件厂商需要一个 RTOS。他们面对两个选择：

μC/OS-III： 源码极其优美，但一旦量产，法务就会收到 Micrium 几十万元人民币的律师函。

FreeRTOS： 源码虽然没那么漂亮，但完全免费，而且 MIT 协议允许你随便拿去商用。

结果显而易见，商业市场的逐利性让 FreeRTOS 呈摧枯拉朽之势占领了绝大多数新项目，而 μC/OS 被彻底边缘化到了军工、航空等极其不差钱的传统老旧领域。
眼看市场份额被 FreeRTOS（尤其是后来被亚马逊收购后）和 RT-Thread 等免费开源项目疯狂蚕食，固守收费模式的 Micrium 终于撑不住了。

2016 年卖身： 著名的芯片原厂 Silicon Labs（芯科科技） 全资收购了 Micrium 公司。Labrosse 也随之加入了 Silicon Labs。

2020 年痛苦的断臂求生： Silicon Labs 发现即使自己收购了，开发者依然因为版权问题不愿意用。于是，官方做出了一个迟到太久的决定：将 μC/OS-II 和 μC/OS-III 的所有代码（包括网络、文件系统等全家桶）彻底免费开源（遵循 Apache 2.0 协议）！

如今的归宿： Silicon Labs 后来将这个开源项目的维护权交给了 Weston Embedded Solutions 公司（由前 Micrium 核心工程师组成），并将其重新包装命名为 Cesium RTOS（但这名字几乎没人认，大家还是习惯叫它 μC/OS）.
一定要读一遍它的源码！ 它的价值已经从“干活的工具”升华成了“艺术品展览馆”。如果想知道什么是真正的 MISRA-C 规范，什么是“没有任何废话和冗余”的 C 语言内核设计，花一两个星期去阅读一下 μC/OS-II 的核心源码（也就几千行），你的 C 语言内功和对操作系统的理解，会得到一次脱胎换骨的升华。

VxWorks

VxWorks运行条件

早期的 VxWorks 5.x 或现代的 Microkernel 配置文件
主频:  32 MHz
内存: 100-256 KB
Flash占用: 200-500 KB

VxWorks 6.x / 7.x 标准版, 现代全功能架构配置
必须要有MMU
主频:  200MHz
内存:  8-16MB
Flash占用: 8-16MB

响应延迟是 Linux 的几十分之一

VxWorks 发展史

VxWorks 绝对是嵌入式实时操作系统（RTOS）界的“劳斯莱斯”和“终极硬核工业霸主”。它是人类历史上第一款登上火星的商用操作系统，代表着人类软件工程在“高可靠性”和“硬实时性”上的最高水准。
VxWorks 背后的开发商是 风河系统公司（Wind River Systems）。它的历史，几乎就是一部人类尖端工业和航空航天的计算机控制史。

1981 年，Jerry Fiddler 和 David Wilner 在美国伯克利的一个车库里创立了风河公司。最初，他们根本没想过做操作系统，而是接一些外包项目，为当时其他公司的系统写一些调试工具（Debugger）和底层驱动。
因为他们发现当时的系统都太难调试了，于是顺手写了一套极其好用的实时内核来辅助自己测试。渐渐地，客户发现这套“测试内核”比他们买的正式系统还要稳定、响应还要快。于是，在 1987 年，风河正式将这款内核打包，命名为 VxWorks 推向市场。

90 年代是 VxWorks 封神的时代。由于其极端的稳定性和低延迟，它迅速占领了对价格极度不敏感的军工和航空航天市场。

火星救援的封神之战 (1997)： NASA 的“火星探路者号”登陆火星后，由于优先级反转（Priority Inversion）引发了系统频繁重启。地球上的工程师通过复现 Bug，向火星发送了一段 C 语言代码，直接通过 VxWorks 强大的动态链接能力在火星上打了一个热补丁，拯救了价值数亿美元的探测器。这一战让 VxWorks 在全球一战成名。

除了火星车，波音 787 客机、阿帕奇武装直升机、爱国者导弹防御系统、甚至宝马的高端车载系统，全都被 VxWorks 拿下。
进入 2000 年后，随着硬件复杂化，VxWorks 在 2004 年发布了划时代的 VxWorks 6.0。

它引入了基于 MMU 的内存保护机制（RTP），彻底解决了传统 RTOS 指针越界导致系统崩溃的死穴。

2009 年，芯片巨头 Intel 以 8.84 亿美元全资收购了风河公司。Intel 的算盘是想借助 VxWorks 统治未来的物联网和边缘计算市场。
在 Intel 旗下，VxWorks 发布了 VxWorks 7 版本，架构被彻底组件化和高度解耦，甚至支持了 OCI 容器（类似 Docker）的运行。

但随着 Linux 的生态越来越繁荣，商业闭源的 VxWorks 在消费电子和通用物联网市场受到了巨大冲击。资本也随之调整：

2018 年： Intel 发现风河并没有帮其卖出更多的 x86 芯片，将其出售给了私募股权公司 TPG Capital。

2022 年： 著名的汽车零部件巨头 安波福（Aptiv）以 43 亿美元的惊人天价收购了风河公司。

今天的 VxWorks：
今天的 VxWorks 依然稳坐在工业金字塔的塔尖。它不仅支持传统的 C/C++，还率先在 RTOS 领域官方引入了 Rust 语言支持以追求极致的内存安全。虽然普通开发者很少有机会接触到它（一套开发授权加源码往往需要数十万到上百万人民币），但当乘坐高铁、飞机，或者仰望深空探测器时，那个在底层以微秒级精度精准调度着一切的“幽灵”，依然是 VxWorks

现代 IoT 物联网操作系统

Zephyr OS

Zephyr OS运行条件

(仅内核)
主频:  32 MHz
内存: 8 KB
Flash占用: 8-12 KB

(带低功耗蓝牙)
主频:  48 MHz
内存: 32-64 KB
Flash占用: 128-256 KB

Zephyr OS 发展史

Zephyr 的名字是在 2016 年才出现的，但它的内核技术底子却极其深厚，直接继承自“军工霸主”——风河系统（Wind River）。Intel 在 2009 年收购了风河公司。到了 2014-2015 年，Intel 想要大举进军物联网市场. 为了给这些资源受限的 IoT 设备提供操作系统，风河公司基于自己深厚的技术积累，开发了一个极小体积的微内核，内部代号为 Viper。后来 Intel 将其包装成了面向云端 IoT 的商业操作系统 Wind River Rocket. Intel 决定把这个由顶级 RTOS 团队写出来的内核彻底开源, 2016 年 2 月，是一个历史性的时刻。Linux 基金会正式宣布接管这个由 Intel 捐赠的项目，并将其命名为 Zephyr Project.
为什么巨头们要联合？
当时，如果你是一个写蓝牙或 Wi-Fi 协议栈的开发者，你会极其痛苦：你需要为 FreeRTOS 写一遍代码，为 uC/OS 写一遍，为 RT-Thread 写一遍。
因此，Intel、NXP（恩智浦）、Synopsys（新思科技）以及 Linaro（ARM 生态的推手） 作为创始成员，决定联合打造一个“单片机界的 Linux”。

极度中立： 因为挂在 Linux 基金会名下，Zephyr 不属于任何一家特定的芯片厂，所有代码的合并都要经过极其严格的同行评审（Code Review）。这让所有的芯片原厂（如 TI、ST、Silicon Labs）都放下了戒心，开始积极向里面贡献代码。

2018 - 2019年, Zephyr 社区做出了一个违背当时单片机开发常理的决定：强行引入 Linux 的构建思想。
习惯了 Keil 的老工程师打开 Zephyr 源码时直接崩溃了，因为里面没有他们熟悉的 .uvprojx 工程文件，而是充满了他们看不懂的宏大架构：

1. 引入 Device Tree (设备树)： 过去单片机工程师在 C 语言里写长篇大论的寄存器初始化代码。Zephyr 引入了 Linux 的设备树，硬件引脚被抽象成了一份 .dts 文本文件。换芯片？直接换个文本文件就行，业务代码一行不用改。
2. 引入 Kconfig： 摒弃了 FreeRTOSConfig.h 这种手动改宏定义的方式，变成了图形化的配置菜单。想要开启蓝牙？敲一行指令，在弹出的菜单里打个勾即可。
3. 引入 CMake 与 West： 摒弃了特定 IDE，引入了基于 Python 的元工具 west，它能自动帮你从 Github 上拉取庞大的依赖库（如 mbedTLS 加密库、LVGL 图形库）。

Zephyr 从一个简单的“库”，彻底变成了一个庞大的全栈应用开发框架。让 Zephyr 真正走向神坛，并在商业上取得压倒性成功的，是一家挪威的公司：Nordic Semiconductor（北欧半导体）。

Nordic 的豪赌： Nordic 是全球低功耗蓝牙（BLE）芯片绝对的霸主（其 nRF52 系列占据了全球大半江山）。2020 年左右，Nordic 做出了一个极其疯狂的决定：彻底放弃自家维护了多年的、极度成功的裸机版蓝牙协议栈（SoftDevice），全面转向 Zephyr。

nRF Connect SDK 的诞生： Nordic 推出了基于 Zephyr 深度定制的官方 SDK（nCS）。这意味着，全球数以十万计的蓝牙智能硬件开发者，不管你愿不愿意，只要你想用 Nordic 最新的芯片，你就必须去学 Zephyr、学设备树、学 CMake。

最强蓝牙协议栈： 由于 Nordic 的全力投入，Zephyr 拥有了目前全球开源界最完善、通过认证最多、支持最新特性（如蓝牙 5.3、LE Audio 蓝牙音频）的开源蓝牙协议栈。

今天的 Zephyr，已经不仅仅是一个 RTOS，它代表着嵌入式单片机软件工程的现代化。

RT-Thread

RT-Thread运行条件

RT-Thread Nano 版
主频:  <10 MHz
内存:  32 KB
Flash占用: 1 KB

RT-Thread 标准版
主频:  32-48 MHz
内存:  2.5 KB
Flash占用: 5-10 KB

RT-Thread 发展史

它是目前国内唯一能和国际顶级 RTOS 掰手腕、甚至在很多物联网场景下形成碾压之势的国产开源操作系统。
2006 年。当时的熊谱翔还是上海贝尔的一名软件工程师。和所有有追求的极客一样，他对当时的单片机开发环境充满了抱怨：

1. μC/OS 虽然好，但闭源收费，拿来做产品心里不踏实；
2. FreeRTOS 虽然免费，但它真的“只是一个内核”，想要加个文件系统、网络协议栈，全得自己到处去“捡垃圾”拼凑，痛苦不堪.

最初的杀手锏：FinSH 控制台
在那个大家还在用 Keil 连着 ST-Link 极其枯燥地单步调试的年代，熊谱翔在这个只有几十 KB 的系统里，硬生生塞进去了一个类似 Linux 终端的命令行工具——FinSH。
只要插上一根串口线，你就能在电脑的黑框框里敲入 list_thread() 查看所有任务状态，甚至直接输入 C 语言表达式来控制硬件！这种“降维打击”般的调试体验，瞬间在国内极客圈里圈了一大波粉。

2006-2015长达近十年的时间里，RT-Thread 并没有成立公司，纯粹是靠熊谱翔和网络上一群志同道合的国内顶尖黑客（比如著名的初创成员“Grissiom”、“一江秋水”等）用爱发电维护的。
在这个阶段，他们做出了一个极其伟大的架构决定：彻底拥抱 Linux 的设计哲学。

1. 引入设备驱动框架 (Device Framework)： 他们把单片机上乱七八糟的串口、SPI、I2C 硬件，全部抽象成了类似 Linux 的标准设备节点（open, read, write, close）。底层硬件怎么换，上层业务代码完全不用改。
2. 引入包管理器： 开发了类似 Linux 的配置工具。

这段时间的 RT-Thread，在小圈子里被奉为神作，被称为“披着单片机外衣的微型 Linux”。但因为没有商业推广，很多大厂根本不敢用这个“网友开发的系统”。

2017 年是个转折点，物联网（IoT）大爆发。这个时候的设备不仅要控制硬件，还要连 Wi-Fi、连云、跑蓝牙、搞加密。传统的 FreeRTOS 根本扛不住这么复杂的组件管理。

资本市场敏锐地发现了 RT-Thread 这个宝藏。

成立公司与融资： 熊谱翔正式辞职，成立了上海睿赛德物联网科技有限公司，并迅速拿到了风险投资。RT-Thread 终于从“民间游击队”变成了“正规军”。

Env 工具与软件包生态： 官方推出了极其强大的 Env 构建工具（基于 Python 和 Kconfig）。开发者就像在 Linux 下用 apt-get 一样，在菜单里敲个回车，阿里云的 SDK、腾讯云的组件、MQTT 协议栈就会自动下载并配置进工程里。

绝地反击的 Nano 版： 为了打压 FreeRTOS，官方把系统里庞大的组件全部砍掉，抽出了一个只有 2.5KB 大小的 RT-Thread Nano，直接杀进了 FreeRTOS 最核心的低端单片机腹地。

借助中国极其庞大的智能家电和消费电子产业链，RT-Thread 的装机量呈火箭级攀升，彻底坐稳了国产物联网 OS 的第一把交椅。

2020 - 至今, 当统治了 Cortex-M 单片机市场后，RT-Thread 发现了一个新的痛点：现在的带屏设备（比如智能音箱、带屏网关）需要极快的开机速度，跑 Linux 太慢（要十几秒），跑传统 RTOS 又没有内存隔离（容易死机）。

于是，RT-Thread 推出了它的终极武器：RT-Thread Smart（混合微内核）。

它专门针对带有 MMU 的高端芯片（如 Cortex-A 系列）设计。

它拥有和 Linux 一样的用户态和内核态隔离，某个 App 崩溃了绝对不会影响系统。

但它的启动速度比 Linux 快几十倍（几百毫秒即可启动画面），并且保持了微秒级的硬实时响应。

如今，在很多国产的车规级芯片、安防摄像头芯片和智能家居中枢里，RT-Thread Smart 正在悄无声息地替换掉原本臃肿的 Linux 系统。

从一个程序员在出租屋里敲下的第一行代码，到如今拥有海量软件包、支持上百款国产芯片、年装机量数以亿计的庞大生态，RT-Thread 证明了中国开源力量的强大。

OpenHarmony

OpenHarmony运行条件

轻量系统（Mini System）
主频:  >10 MHz
内存: 10 KB
Flash占用: 256 KB

小型系统（Small System）
主频:  200 MHz
内存: 1 MB
Flash占用: 8MB

标准系统（Standard System）
主频:   1 GHz
内存: 128 MB
Flash占用:  128 MB

OpenHarmony 发展史

首先搞明白两个点: 鸿蒙（HarmonyOS） ≠ 开源鸿蒙（OpenHarmony）

• OpenHarmony： 是华为捐赠出去的开源底座（由开放原子开源基金会管理）。它就像是毛坯房，任何公司（甚至包括小米、OPPO）都可以免费拿去用，去改。
• HarmonyOS（华为鸿蒙）： 是华为基于 OpenHarmony 这个毛坯房，自己精装修出来的商业版系统，里面加了华为自己的云服务、专属UI和闭源高级特性，专供华为手机/平板使用。

早在 2012 年左右, 为了防患于未然, 华为内部成立了极度保密的操作系统研发团队，开始研发一套面向未来的微内核架构（这就是后来的 LiteOS 和鸿蒙内核的雏形）。当时它的主要目标甚至不是手机，而是面向未来物联网的 5G 工业设备。在内部，它一直被当作一个“最好永远不要被用到”的备胎。
2019 年 5 月 16 日， 美国将华为列入“实体清单”, 华为在海外的手机销量瞬间遭遇毁灭性打击。2019 年 8 月，华为正式对外发布 HarmonyOS 1.0。当时的 1.0 版本非常初级，只能用在华为的“智慧屏”（电视）上，根本上不了手机。很多人嘲笑它是“PPT系统”或者“安卓套壳”。但这实际上是底层系统替换必然经历的阵痛，因为当时的鸿蒙还没有手机生态。
2020 年和 2021 年，华为将鸿蒙系统最核心的基础设施代码（微内核、分布式框架、软总线等），分批次无偿捐赠给了国家工信部主导的“开放原子开源基金会”。
OpenHarmony 展现出了它与 Android 最根本的区别——分布式软总线。搭载了 OpenHarmony 的手机和烤箱碰一下，手机屏幕上直接弹出烤箱的控制界面，设备之间互为外设。这种体验在当时的 IoT 业界是降维打击。
2023 - 至今, 虽然 OpenHarmony 在物联网设备上高歌猛进，但在手机端，早期的华为 HarmonyOS 为了照顾用户体验，不得不内置了一套 AOSP（安卓开源项目）代码，用来兼容运行安卓的 APK 应用. 2023 年底，HarmonyOS NEXT（星河版）发布： 华为宣布，下一代系统将彻底剔除所有 Android 代码，不再兼容任何安卓 APK. OpenHarmony 的底层内核经过这几年的迭代，也完全去除了 Linux 的历史包袱，在流畅度和内存管理上，官方宣称比传统系统提升了 30%。

ESP-IDF

ESP-IDF运行条件

(带 Wi-Fi)
主频:  80 - 160 MHz
内存: 50 KB
Flash占用:  1 MB

ESP-IDF 发展史

ESP-IDF 背后的公司是中国的乐鑫科技（Espressif）。在物联网（IoT）圈子里，乐鑫有着极其特殊的地位：它明明是一家卖实体芯片的公司，但全世界的极客和工程师却把它当成一家“伟大的开源软件公司”来膜拜。
在讲 ESP-IDF 之前，必须提它的前传——ESP8266。
2014 年之前，如果你想给单片机加上 Wi-Fi 功能，买一块高通或 TI（德州仪器）的 Wi-Fi 模块，大概需要 20 到 40 美元，而且原厂的技术手册像防贼一样，必须签极其严格的保密协议（NDA）才给你看。
2014 年底，乐鑫推出了 ESP8266 芯片，价格直接杀到了 2 美元！
全世界的创客（Maker）圈瞬间被引爆了。但当时的软件开发极其痛苦，乐鑫官方提供的是一个叫 Non-OS SDK 的东西，没有操作系统，全靠写满屏的 Callback（回调函数）来处理网络数据，代码极其丑陋且极易崩溃。
这时候，奇迹发生了：因为芯片太便宜，全球的开源极客自发地给乐鑫写代码。 有人给它写了 NodeMCU（用 Lua 语言写单片机），有人把它移植到了 Arduino IDE 里。乐鑫的高层（创始人张瑞安）极其敏锐地发现：开源生态，比闭源卖硬件牛逼一万倍！
2016 年，乐鑫推出了真正震惊全球工业界的王炸芯片：ESP32。
它不仅有 Wi-Fi，还加入了蓝牙，而且是双核的！主频高达 240MHz。

在这个强大的硬件面前，以前那种乱七八糟的 SDK 根本压榨不出它的性能。于是，乐鑫决定推倒重来，直接从零构建一个庞大的、现代化的、工业级的软件框架，并正式命名为 ESP-IDF (Espressif IoT Development Framework)。

ESP-IDF 最初的几个神级设计：

白嫖并魔改 FreeRTOS： 既然双核太难管理，乐鑫直接拿开源的 FreeRTOS 开刀，魔改出了一个支持 SMP（对称多处理）的版本。开发者写代码感觉还是在用 FreeRTOS，但底层系统会自动把任务分配给两个 CPU 核心同时跑。

彻底拥抱开源社区： 乐鑫把 ESP-IDF 所有的源码全部放在 GitHub 上。你发现 Bug？直接提 PR（Pull Request），乐鑫的官方工程师就在 GitHub 上用英语和全世界的极客实时对喷、修 Bug。这种开放度在传统的芯片原厂（如 ST、NXP）看来简直不可理喻。

早期的 ESP-IDF (v3.x 及以前) 使用的是老旧的 GNU Make 系统。随着 ESP-IDF 越来越庞大（加入了 HTTPS、各种云服务 SDK、庞大的蓝牙协议栈），编译一次居然要花十几分钟，Makefile 文件乱得像意大利面条。
拥抱 CMake 与 Ninja： 从 v4.0 开始，ESP-IDF 痛下决心，彻底废弃 Makefile，全面转向 CMake 和 Ninja 构建系统。
杀手锏 idf.py 诞生： 乐鑫开发了一个基于 Python 的命令行神器 idf.py。
开发者不再需要去点 IDE 里的各种菜单，在终端里敲下 idf.py menuconfig，就会弹出一个类似 Linux 内核配置的图形菜单；敲下 idf.py build flash monitor，系统就会自动完成极速增量编译、自动复位烧录、并打开串口监视器。一气呵成，无比丝滑。
这套极其现代的工具链，让习惯了 Linux 开发的后端程序员能够毫无阻力地跨界来写单片机代码。
随着乐鑫的芯片产品线越来越多（比如主打超低功耗的 ESP32-S2，加入 AI 向量指令的 S3，以及彻底转向 RISC-V 架构的 C3、C6 芯片），ESP-IDF 展现出了它最恐怖的架构威力。
架构的无感跨越： 对于开发者来说，你在 ESP-IDF 里写的一段连接 Wi-Fi 和 MQTT 服务器的 C 语言代码，不管底层的芯片是双核的 Xtensa 架构（ESP32），还是单核的 RISC-V 架构（ESP32-C3），你的业务代码一行都不用改！ ESP-IDF 的底层架构完美屏蔽了这些硬件差异。
组件注册表 (IDF Component Registry)： 最近几年，乐鑫又搞出了类似 Node.js 里的 npm 一样的包管理器。你需要驱动一个墨水屏？只需要在配置文件里写一行依赖，ESP-IDF 在编译时就会自动从云端把这个驱动源码拉取下来并编译进你的项目里。
传统的芯片公司（比如 ST 意法半导体）的逻辑是：我卖给你硅片，顺便送你一点能跑起来的软件代码（比如 HAL 库）。
而乐鑫的逻辑是：我做出了世界上最好用的开源物联网软件框架（ESP-IDF），为了让这款软件跑起来，你顺便买一块我的芯片吧。
ESP-IDF 证明了一个真理：在物联网时代，优秀的软件工具链和繁荣的开源生态，才是芯片公司最宽广的护城河。 它硬生生地把全球物联网 Wi-Fi 芯片的开发标准，拉到了中国人制定的框架体系内。

高端微内核及宏内核操作系统

Embedded Linux

极简裁剪
主频:  200 MHz
内存: 8 - 16 MB
Flash占用:  4 - 8 MB

带 Qt 界面
主频:  500 MHz
内存: 64 - 128 MB
Flash占用:  16 - 32 MB

Embedded Linux 发展史

早期的 Linux 是个庞然大物，只能跑在笨重的 386 电脑或服务器上。当时的嵌入式世界是 VxWorks 和 WinCE 的天下. 但总有一群闲不住的极客觉得：“只要这东西有 CPU，我就要让它跑 Linux”. 当时要把 Linux 塞进非 x86 架构（如 ARM、PowerPC）的板子里，简直是人间噩梦。你必须在一台 PC 上，手动编译编译器（gcc）、链接器（binutils）、C 库（glibc），再编译内核，过程极其极其痛苦，被称为“刀耕火种”的年代。极客们硬生生抠掉了 Linux 的 MMU 依赖代码，搞出了 uClinux，把它塞进了单片机里。紧接着，2003 年爆发了一个标志性事件：网络巨头 Linksys 发布了经典的 WRT54G 路由器。极客们发现它的固件竟然是基于 Linux 的，于是逼迫 Linksys 开源了代码。这就是后来统治全球智能路由器的 OpenWrt 系统的起源。Linux 正式在嵌入式网络设备中撕开了一道口子。
2000年代中 - 2010年, 随着 ARM Cortex-A 系列芯片的崛起（比如早期的智能手机和 MP4 播放器），硬件终于有足够的 RAM 和 MMU 来跑完整的 Linux 了. 但新的灾难出现了：“依赖地狱”。如果你想在板子上跑一个带图形界面的应用，你需要编译几十个第三方库。只要一个库的版本不对，整个系统就崩溃。为了解决这个大麻烦，嵌入式 Linux 迎来了它的工业化革命: Buildroot 诞生： 这是一个极其暴力的工具。它把成百上千个开源软件的编译规则写成了脚本，你只需要像配置内核一样弹出一个 menuconfig 菜单，勾选你需要的软件，敲下 make，去喝杯咖啡。回来时，它已经帮你把交叉编译器、文件系统镜像、所有应用软件全自动编译打包好了。消费电子的全面沦陷： 依靠这种自动化的构建工具，机顶盒、智能电视、车载多媒体、早期的按键智能手机，几乎全军覆没，全部换上了免费、强大的嵌入式 Linux。
也是在这个时期，Google 基于 Linux 内核搞出了一个超级怪兽——Android。
随着工业、汽车和物联网进入深水区，大厂们（Intel、TI、NXP）发现 Buildroot 虽然简单，但太死板了。如果一家公司有 10 种不同的硬件产品，想要维护一套统一的代码基线极其困难。
于是，Linux 基金会再次出手，联合各大巨头推出了嵌入式 Linux 史上最庞大、最复杂的工程：Yocto Project。
Yocto 根本不是一个操作系统，它是一个“用来制造定制化 Linux 操作系统的工厂”。它采用了极其先进的“分层（Layer）”架构。芯片原厂（如 NXP）提供底层驱动层（BSP Layer），UI 公司提供图形层，你自己写业务层。像搭高阶乐高一样组合。现在，任何一家正规的芯片原厂发布带 MMU 的芯片，如果不提供 Yocto 支持，根本没有大公司会买。
2020年代 - 至今, 虽然嵌入式 Linux 统治了多媒体、网络和界面，但长久以来，它一直有一个被 VxWorks 等传统 RTOS 嘲笑的致命弱点：它不是硬实时的。 如果用 Linux 去控制机械臂或者汽车刹车，系统偶尔卡顿个几毫秒，可能就会机毁人亡。全球顶尖的内核黑客花了近 20 年的时间，开发了 PREEMPT_RT 实时补丁。它将 Linux 内部极其复杂的自旋锁和中断机制彻底改造，硬生生把一个宏内核变成了具备微秒级确定性响应的实时系统。最近几年，这个补丁终于被合并到了 Linux 官方主线内核中。如今，在自动驾驶（如特斯拉的系统底层）、高端工业机器人、SpaceX 猎鹰九号火箭的控制节点里，带有实时补丁的嵌入式 Linux 正在势如破竹地替代 QNX 和 VxWorks。因为它不仅现在有了“实时性”，它还附带了整个地球上最庞大的开源 AI 框架、计算机视觉库和网络安全协议栈。

QNX

主频:  500 MHz
内存:  32 MB
Flash占用:  64 MB

QNX 发展史

在今天的智能驾驶和汽车数字座舱领域，QNX 拥有着近乎令人绝望的绝对垄断地位（市场份额常年高达 70% 以上）。无论是保时捷、奔驰，还是蔚来、小鹏，只要是带有高级辅助驾驶和多屏互动的汽车，底层绝对离不开它。
1980 年，加拿大的滑铁卢大学里有两名极客学生。他们在上操作系统课时，对当时主流的宏内核（比如早期的 UNIX）非常不满意，觉得把所有东西都塞进内核里太臃肿、太容易崩溃了。于是，他们决定自己写一个真正的微内核（Microkernel）操作系统。最初它被命名为 QUNIX（Quick UNIX），后来因为商标版权问题，去掉了两个字母，正式改名为 QNX。QNX 展现出了微内核极其恐怖的压缩能力。在 90 年代末，QNX 推出过一个震惊全球的 Demo：一张 1.44MB 的 3.5 英寸软盘。就这一小张软盘，里面塞进了一个完整的 QNX 实时操作系统、一个支持鼠标的图形用户界面（Photon microGUI）、一个 TCP/IP 网络协议栈，甚至还有一个网页浏览器！把这张软盘插进电脑，开机几秒钟就能直接上网。这在当时简直是神仙级别的代码艺术。在学术界一直有个著名的争论（比如著名的 Linus 与 Tanenbaum 之争）：大家都承认微内核安全（系统服务全在用户态运行，崩溃了互不影响），但普遍认为微内核由于进程间频繁通信，速度太慢。

但 QNX 的工程师通过极其硬核的汇编级优化和独创的“消息传递（Message Passing）”机制，硬生生把微内核的性能做到了比很多宏内核还要快，并且拥有微秒级的硬实时响应。

凭借着“绝对不会蓝屏死机”的稳定性和极快的响应速度，QNX 在这个阶段拿下了全球最高端的工业控制市场：

• 思科（Cisco）的核心路由器，跑的是它。
• 全球无数的核电站控制台、高速公路交通灯中枢系统，跑的是它。
• 通用电气的高端医疗核磁共振设备，底层依然是它。

2010 年，智能手机市场正在被苹果 iOS 和安卓疯狂瓜分。昔日的手机霸主黑莓（BlackBerry / RIM 公司）被打得节节败退。黑莓原本的手机系统太老旧了，急需一个强大的现代操作系统来救命。于是，黑莓斥巨资全资收购了 QNX 软件系统公司。

黑莓基于 QNX，倾尽全公司之力开发了惊艳的 BlackBerry 10 (BB10) 操作系统，并推出了手机和 PlayBook 平板电脑。
技术上的胜利： 从纯技术角度看，基于 QNX 微内核的 BB10 系统极其先进。它的多任务切换丝滑无比，你可以一边播着 1080P 高清视频，一边毫无卡顿地进行其他复杂操作。
生态的毁灭： 但是，操作系统的战争从来不是纯技术的战争。iOS 和安卓已经构筑了极其恐怖的 App 生态壁垒。BB10 根本没有开发者愿意给它写软件，系统里甚至连个好用的微信和支付宝都没有。
最终，黑莓在智能手机大战中彻底败北，退出了手机硬件市场。QNX 似乎也要跟着这艘大船一起沉没了。
正当大家以为 QNX 已经凉透的时候，时代的列车拐了一个大弯——汽车智能化（造车新势力）爆发了。

汽车厂商突然发现，未来的汽车其实就是一台“装着四个轮子的大电脑”。这台大电脑需要一块超级中控屏，需要放音乐、看导航、甚至打游戏。
但是，汽车对绝对安全性（Safety）的要求是苛刻到变态的。

这时候，QNX 的微内核架构展现出了降维打击般的优势，它完美解决了汽车厂商面临的最大死局：
如果你用 Linux/Android 跑车机： 它的生态虽然好，但它是宏内核。如果副驾驶看爱奇艺时某个 App 导致系统内核内存溢出（Kernel Panic），整个系统就会死机重启。如果这时候仪表盘死机了，甚至影响到了底盘刹车控制，那是会出人命的！
QNX 的绝对隔离： 在 QNX 系统下，每一个 App、每一个驱动（哪怕是网卡驱动、图形驱动）都运行在独立的受 MMU 保护的沙盒空间里。就算中控屏上的安卓虚拟机死机了、崩溃了，底层负责显示车速仪表盘和控制车辆 ADAS（高级辅助驾驶）的 QNX 核心进程依然能够极其稳定地运行，毫不受影响。
凭借着这种极端的安全隔离能力，以及早就拿满的最高级别汽车功能安全认证（ISO 26262 ASIL-D），QNX 迎来了它的黄金时代。

其他嵌入式操作系统

INTEGRITY

纯闭源商业软件。
它是美国 Green Hills Software（绿山软件）的镇山之宝。如果你觉得 VxWorks 和 QNX 已经足够高端了，那 INTEGRITY 就是“变态级的高端”。它的核心卖点是其采用了极其苛刻的数学验证模型，通过了美国军方最高安全级别（EAL6+）。F-22、F-35 战斗机，以及波音 787 的核心飞控，跑的全是它。普通开发者不仅看不到源码，甚至连它的官方技术文档都很难在网上搜到。

AUTOSAR Classic OS

标准是公开的，代码是闭源垄断的

AUTOSAR 不是一套写好的操作系统代码，而是一本“厚达几万页的规则书（标准规范）”。宝马、大众、丰田等车企聚在一起定下了这个规矩。
但如果你想在车上跑这个 OS，你必须去买德国 Vector（维克多）或者 EB（Elektrobit）等几大工具链寡头写好的代码。这些代码是绝对闭源的，而且不是按行卖，是配合着极其复杂的上位机配置工具一起卖，一套动辄上百万人民币。

Micro-ITRON

接口标准免费，代码有开源也有闭源。

它由日本的坂村健教授在 1984 年发起（TRON 计划）。它规定了操作系统的 API 长什么样，任何人都可以按这个 API 规范自己写底层代码。

在日本，有像 TOPPERS 这样完全免费开源的 ITRON 实现；但大厂（如瑞萨电子、索尼）通常会在自己内部维护一套极度优化过的闭源版本。

NuttX

NuttX 由 Gregory Nutt 在 2007 年创立（现在已经捐赠给了 Apache 基金会）。它的核心设计哲学极其纯粹，只有一句话：在单片机上，100% 还原 Linux 的开发体验。
它不是“类似” Linux，它是严格遵守 POSIX 标准。这意味着，你在 Linux 下写的标准 C 语言程序（比如用 pthread 创建线程，用 open/read/write 读写文件，用 socket 写网络通信），几乎一行代码都不用改，就能直接在只有几百 KB 内存的 NuttX 单片机上编译运行！

• 虚拟文件系统 (VFS)： 在 NuttX 里，一切皆文件（和 Linux 完全一样）。点亮一个 LED 灯，就是向 /dev/led 这个文件写入数据。
• 统治无人机与音频领域： 全球最著名的开源无人机飞控系统 PX4，其底层操作系统就是固定的 NuttX。另外，索尼（Sony）的很多高端蓝牙耳机、MP3，以及小米的大量 IoT 模组，底层跑的全是 NuttX。

Keil RTX / CMSIS-RTOS

搞单片机的人绝对绕不开 Keil MDK 这个宇宙第一 IDE。RTX 就是 Keil 公司自己写的免版税 RTOS。后来 ARM 把 Keil 收购了，RTX 就顺理成章变成了 ARM 的“亲儿子”。
但 ARM 发现市场上的 RTOS 太多了（FreeRTOS, uC/OS 等），大家 API 都不一样。为了统一天下，ARM 推出了 CMSIS-RTOS 标准。
CMSIS-RTOS 不是操作系统，它是一层“API 翻译官”。 ARM 规定了一套标准的函数名（比如 osThreadCreate）。可以底层跑 RTX，也可以跑 FreeRTOS，只要套上 CMSIS-RTOS 这层壳，应用代码就永远不需要改了。
零配置开箱即用： 如果在 Keil 里点两下鼠标，勾选上 RTX 库，它能直接和底层的 Cortex-M 芯片的硬件定时器（SysTick）完美融合，几乎不需要写任何移植代码。

TI-RTOS

德州仪器（TI）是全球模拟芯片和 DSP（数字信号处理器）的绝对王者。TI-RTOS 的前身叫做 DSP/BIOS，它是专门为了压榨 TI 自家那些跑着极速算法的 DSP 芯片而生的。配合 TI 自家的 Code Composer Studio (CCS) 开发环境，TI-RTOS 拥有一套被称为 ROV (Runtime Object View) 和 UIA 的神级性能分析工具。可以极其直观地看到 CPU 每微秒在干什么，哪个任务占了多少周期。功耗管理的王： 在 TI 的低功耗蓝牙（CC2640）和 Wi-Fi 芯片（CC3200）里，TI-RTOS 的电源管理（Power Manager）深度绑定了硅片底层的晶体管，能把休眠功耗压榨到极致。
极其封闭，极其强大。如果不用 TI 的芯片，这辈子都不会碰它；但如果在做高端工业变频器或无线传感器，用了 TI 的芯片，那不用它简直是暴殄天物。

MQX

曾经名震天下的工业级系统，如今已被官方战略性放弃。MQX 最早由 ARC 公司开发，后来被芯片巨头 飞思卡尔（Freescale，现已并入 NXP 恩智浦） 花重金买断。在 2010 年代初，只要你用飞思卡尔大名鼎鼎的 Kinetis 系列（基于 Cortex-M4）芯片，官方绝对强推 MQX。它是当时少有的、能够提供极其完善的全家桶（RTOS + TCP/IP 协议栈 + USB 协议栈 + 文件系统）且对飞思卡尔用户完全免费的系统。代码极其健壮，在医疗和电网设备中备受推崇。由于 NXP 和飞思卡尔合并后，市场格局大变。NXP 发现维护一个私有系统的成本太高了，于是全面转向了开源的 FreeRTOS 和 Zephyr。现在的 MQX 基本处于“只维护不更新”的遗产状态，新项目已经不推荐使用了。

Mbed OS

2014 年左右，物联网大爆发。ARM 官方想亲自下场，一统物联网江湖。于是他们倾注了大量心血推出了 Mbed OS。
它的理念在当时惊为天人：用 C++ 面向对象的思想来写单片机！极其优雅的 C++ API： 以前点个灯要配置一堆寄存器，在 Mbed 里，你只需要写 DigitalOut myled(LED1); myled = 1; 就这么简单，就像在写 Arduino，但底层却是企业级的 OS。全栈云原生： 它不仅是个 OS，ARM 还在上面绑定了强大的 TLS 加密库（mbedTLS，现在的行业标杆）和设备管理云平台（Pelion）。缺点是太臃肿, C++ 的面向对象和层层封装，导致编译出来的体积大得惊人。几十 KB Flash 的廉价单片机根本跑不动，必须上高端 MCU。这是一个带着贵族气息的实验。虽然它培养了一大批高端开发者，并且留下了 mbedTLS 这个伟大的加密库遗产，但作为一个通用 OS，它已经被更务实的 FreeRTOS 和更底层的 Zephyr 给边缘化了。ARM 官方也已经大幅缩减了对它的投入。

RTEMS

它是一个完全开源的、支持 POSIX 标准的硬实时系统。因为它的容错机制做得极好，而且免费，欧洲航天局（ESA）极其爱用它。甚至连目前人类最昂贵的玩具——詹姆斯·韦伯太空望远镜（JWST），其核心科学仪器模块跑的也是 RTEMS。

seL4

它是人类历史上第一个（也是目前唯一一个）从数学上被完全证明“没有 Bug”的通用微内核操作系统。由澳大利亚的 NICTA 实验室开发（现已开源）。传统的 OS 靠测试来找 Bug，而 seL4 靠数学推导。工程师把 C 语言内核代码转化成了数学逻辑定理，用计算机自动证明了它“绝不会出现缓冲区溢出、绝不会有空指针异常、绝对隔离”。如果你要在单片机上做一个防御黑客的终极安全加密狗，seL4 是神级选择。

Contiki 与 TinyOS

在 ESP-IDF 和 Zephyr 诞生之前，2000 年代初的“无线传感器网络（WSN）”极其贫瘠。
这两个开源系统专为那些只有 2KB RAM 的极弱芯片设计，目标是靠一节纽扣电池跑好几年。Contiki 独创了一种叫“Protothreads（极简线程）”的技术，用 C 语言宏定义硬生生模拟出了多任务调度，内存开销只有几字节！虽然现在它们已经被现代 RTOS 边缘化，但其代码思想依然让很多老极客叹为观止。

Tock OS

这是最近几年在硅谷和极客圈里最火的嵌入式 OS 之一，它背后的支持者包括 Google 和斯坦福大学。
它的特殊之处在于——它绝大部分内核代码是用 Rust 语言写的。
整个嵌入式世界苦 C 语言久矣（无尽的野指针和内存泄漏）。Tock OS 利用 Rust 的“所有权机制”，在编译阶段就杀死了大部分内存错误。它允许你在单片机上安全地运行不受信任的第三方 App（就像手机一样），而不用担心单片机死机。

PikeOS

德国 SYSGO 公司开发的纯闭源微内核虚拟化操作系统。它是 VxWorks 和 QNX 在欧洲大陆最强硬的死敌。法国的空客客机（Airbus）、欧洲的高铁和地铁网络，底层的控制系统大量采用了 PikeOS。它同时通过了航空航天、汽车和铁路的全球最高安全认证。

ROS / ROS 2

ROS（Robot Operating System）其实是一个“伪操作系统（Meta-OS）”。它不能直接跑在裸机上，它必须像寄生虫一样跑在 Ubuntu（Linux）或者 RTOS 之上。

为什么必须提它？ 如果去搞大疆的无人机开发、研发波士顿动力的机器狗、甚至去做百度的自动驾驶（Apollo），会发现底层的驱动全是 Linux 写的，但是上面所有的雷达数据流、摄像头视觉算法、机械臂运动学控制，全部是用 ROS 串联起来的。
ROS 2 更是引入了极其硬核的 DDS（数据分发服务）工业级通信中间件，让机器人内部的各个传感器像蜂群一样高效通信。在机器人圈子，不会 Linux 还能活，不会 ROS 寸步难行。谷歌已经通过 OTA 悄悄地把全球数百万台 Google Nest Hub（智能带屏音箱）的底层系统，从 Linux 偷偷替换成了 Fuchsia OS。

Huawei LiteOS

在 OpenHarmony 诞生之前，华为真正用来打天下的 IoT 功臣。鸿蒙的轻量版底层叫 LiteOS-M。但其实 Huawei LiteOS 作为一个独立的开源 RTOS 已经存在很多年了。
它的装机量极其恐怖，但看不见。因为全中国几千万个智能水表、智能燃气表、共享单车的智能锁，只要里面用了华为海思的 NB-IoT（窄带物联网）芯片，出厂自带的底层系统全都是 LiteOS。它把超低功耗和蜂窝网络连接做到了极致。

Fuchsia OS (底层微内核 Zircon)

谷歌为了彻底摆脱 Linux 历史包袱而倾全公司之力打造的“未来系统”。大家都知道安卓是基于 Linux 内核的。但 Linux 太重了，而且有 GPL 开源协议的“传染性”限制。于是谷歌在 2016 年极其低调地开启了 Fuchsia 项目。它根本没用 Linux，而是从零手写了一个名为 Zircon 的纯微内核。它的野心和华为的 OpenHarmony 极其相似：用一个系统统管所有的智能家居、穿戴设备、甚至未来的手机和电脑。

AliOS Things / TencentOS tiny

阿里云和腾讯云为了让智能硬件厂商（比如卖智能插座、卖温湿度计的公司）把数据传到自己的云服务器上，干脆自己下场写了开源操作系统。
AliOS Things 和 TencentOS tiny 的本质，就是把 FreeRTOS 或极简内核拿过来，死死地绑定上支付宝/微信的支付组件、自家的云端对接 SDK 和 OTA 升级模块。

ChibiOS/RT

它由一位意大利的工程师开发。如果说 RT-Thread 的特点是组件丰富，那 ChibiOS 的特点就是“快到离谱”。它的上下文切换速度和中断响应延迟，在很多独立测试中碾压了 FreeRTOS。
因此，它被大量用在对时间要求极其苛刻的场景：比如开源的高速 3D 打印机固件、自平衡机器人、以及对刷新率要求极高的高级客制化机械键盘里。

Cisco IOS

Internetwork Operating System（互联网操作系统）。
中国电信、联通的机房里，那些价值几百万的超大型核心路由器和交换机，跑的很可能就是它。它是思科（Cisco）的闭源私有系统，从 1980 年代一直进化到现在，可以说是整个地球互联网基础设施的软件基石。

划分低端物联网 OS 和高端复杂 OS 的两大核心边界

1. MMU（内存管理单元）
2. RAM（运行内存）的容量

对于linux和QNX而言, MMU负责实现虚拟内存映射的基础实现, 没有MMU, linux系统就无法实现多用户, 多进程的隔离机制

其实MMU也并非一定要存在, 为了弥补linux系统对MMU的依赖, linux社区重写的linux内核, 替换了所有对MMU依赖的代码, 发展出了NOMMU的特性. 极限情况下, 在仅有2M的RAM的开发板上, 没有MMU, 也可以运行linux, 只是速度慢如蜗牛.

操作系统的四大支柱

1. CPU 调度与时间片管理
2. 内存管理
3. 任务间通信与同步 (IPC)
4. 中断处理（外部刺激反应机制）