裸机、RTOS、Linux不是技术路线:是智能硬件的生死线

架构不是高级词，而是故障发生时你有没有退路。

很多团队做智能硬件，第一版样机跑通后就兴奋了：传感器能读，电机能转，数据能上云，App 能控制。然后他们以为产品快成功了。实际上，真正的噩梦刚刚开始。样机能跑，不代表能量产；实验室稳定，不代表现场稳定；一个任务正常，不代表十个任务并发正常。

嵌入式架构选型最容易被低估。很多人把它当成“技术偏好”：有人喜欢裸机，有人喜欢 RTOS，有人喜欢 Linux。我的观点很直接：裸机、RTOS、Linux不是谁高级谁低级，而是谁更匹配你的复杂度、成本、功耗和团队能力。 选错架构，短期看是开发慢，长期看是维护灾难。

一、裸机不是落后，裸机怕的是复杂度失控

裸机最大的优点是简单、资源占用低、启动快、成本低。对一个功能单一、时序明确、任务数量少的设备来说，裸机完全可以是最优解。比如简单传感器采集、单电机控制、低功耗唤醒上报、无复杂网络交互的控制板。

但裸机的边界也很明显：当你开始同时处理通信、传感器、日志、OTA、按键、显示、低功耗、异常恢复时，主循环会变成一团乱麻。你会看到一堆 flag，一堆状态机，一堆中断回调，最后每个人都不敢改代码。表面上没有操作系统，实际上你在手写一个更差的操作系统。

裸机架构要成功，必须有纪律：中断里只做最短处理；耗时任务放到主循环；所有外设都有状态机；通信协议有缓冲区和超时机制；低功耗唤醒路径独立设计；异常日志能保留。裸机不是不需要架构，裸机更需要克制。

二、RTOS不是万能药，它解决的是并发秩序

RTOS 的价值不是“看起来专业”，而是让复杂任务有秩序。FreeRTOS 这类 RTOS 面向 MCU 和小型微处理器，强调小内存占用、实时调度和丰富内核能力。Zephyr 则进一步提供设备树、驱动模型、网络栈、安全能力和多架构生态。CMSIS-RTOS2 这种接口标准，也是在解决不同 RTOS 之间 API 复用和组件集成问题。

当产品出现这些特征时，RTOS 基本就应该进入候选：多个外设并发；通信和控制要隔离；网络协议复杂；需要 OTA；需要日志；需要低功耗管理；需要长期维护。RTOS 可以把系统拆成通信任务、采集任务、控制任务、日志任务、升级任务、看门狗任务，让故障边界更清楚。

但 RTOS 也会制造新的坑。优先级设置不合理，会导致高优先级任务饿死低优先级任务；队列长度不合理，会导致消息丢失；互斥锁用错，会死锁；栈大小估错，会随机崩溃；ISR 与任务通信设计不好，会出现难复现 bug。RTOS 不是让系统自动稳定，而是给你一套稳定的工具。工具用错，事故更隐蔽。

三、Linux不是“性能强”，Linux是生态强

很多人一看到带屏幕、摄像头、复杂网络，就想上 Linux。这个判断通常没错，但理由不能只是“Linux 强”。Linux 的真正优势是生态：文件系统、网络协议栈、进程隔离、驱动生态、日志系统、安全机制、容器化能力、图形能力、调试工具都成熟。

如果你的设备需要复杂 UI、音视频、边缘计算、多进程隔离、复杂协议网关、数据库、本地 Web 管理界面，那么 Linux 很可能是正解。但 Linux 的代价也明显：启动慢、功耗高、BOM 高、系统裁剪复杂、掉电保护复杂、安全攻击面大、运维要求高。

更现实的问题是：团队有没有 Linux 能力？会不会做 systemd 服务管理？会不会做只读根文件系统？会不会处理异常断电导致的文件损坏？会不会做安全升级？会不会做日志轮转？如果不会，Linux 不是救命药，是放大器。

四、选型不要问“用什么”，要问“怎么死”

我建议用一种残酷但有效的方法做架构选型：先假设设备会死，然后问它怎么死。

网络断了怎么办？传感器卡死怎么办？升级一半断电怎么办？Flash 写满怎么办？主任务阻塞怎么办？日志爆了怎么办？电源瞬断怎么办？用户乱按怎么办？现场干扰怎么办？

如果这些问题都能用简单状态机解决，裸机可以。如果这些问题需要多个任务并发隔离，RTOS 更合适。如果这些问题涉及复杂网络、文件、UI、多进程、第三方库，Linux 更合适。

五、推荐架构模板

六、架构落地：三层隔离

无论裸机、RTOS 还是 Linux，都建议做三层隔离。

第一层是硬件抽象层。GPIO、I2C、SPI、UART、ADC、Flash、网络模组都要有统一接口，不要让业务代码到处写寄存器或 AT 指令。

第二层是服务层。把网络、存储、日志、升级、配置、时间同步做成服务。业务层只调用服务，不关心底层细节。

第三层是业务层。业务状态机只表达产品逻辑，不处理驱动细节，也不直接操作底层资源。

这个结构会让代码变慢一点吗？可能会。但它会让系统可维护、可替换、可测试。量产产品最怕的不是多写几行代码，而是半年后没人敢改。

结尾：架构选型选的是团队未来

嵌入式架构不是为了炫技，而是为了让产品在复杂现场活下去。裸机不是原始，RTOS不是高级，Linux也不是万能。真正专业的判断是：在当前成本、功耗、功能、团队能力下，选择最小但足够强的架构。

下一篇，我们聊文件系统。很多设备不是死在网络，也不是死在硬件，而是死在一次看似普通的掉电写 Flash。

参考资料

• FreeRTOS 官方资料：面向微控制器和小型微处理器，强调小内存占用、实时内核与多架构支持。
• Zephyr Project 官方资料：可扩展 RTOS，支持多硬件架构，面向资源受限设备并强调安全。
• Arm CMSIS-RTOS2 官方资料：为 Arm Cortex 处理器上的 RTOS 内核提供通用接口，便于组件复用和集成。