程序员经验分享-hwhale

物联网应用选择 RTOS 还是 Linux？

2023-05-16

物联网应用选择 RTOS 还是 Linux

Linux VS RTOS，我该选哪个？

引言

在开发设备或系统时，您需要做出的最早和最关键的决定之一就是决定它将运行哪种类型的操作系统。

操作系统是基于特定硬件的大型系统级软件，是一个包含了资源管理、线程\进程调度、线程\进程间通信与同步等组件的集合。

Linux 通常是许多设备和项目的默认操作系统选择，比如 Android 智能手机、智能电视到游戏机和汽车很多设备都使用 Linux 系统。
RTOS（Real-time operating system, RTOS）也很常见，一些小型网关、智能手表、医疗器械或者玩具会选择 RTOS 作为设备的操作系统。

Linux

Linux是一个通用操作系统（General Purpose Operating System, GPOS）;它在嵌入式系统中的应用通常包含外设驱动支持、文件系统、网络连接和 UI 支持。所有这些东西都可以在RTOS中提供（或者裁剪掉这部分功能），但通常支持范围不大，或者需要额外的成本或集成工作。

当然 Linux 的这些功能都需要大量的软硬件资源的支持，而 RTOS 需要的资源则少得多，这也对应了需要的钱的多少。
另一个重要的因素是 Linux 不是实时的。RTOS 提供调度保证，以确保确定性行为以及及时响应事件和中断。

RTOS

RTOS 不同于 Linux 等传统操作系统，因为它对外部事件提供确定性的硬实时响应（规定的很小的时间内，高优先级的任务必须得到执行，否则自爆）。另一方面，传统操作系统提供非确定性的软实时响应。在实践中，这意味着RTOS软件可以为有限数量的预定任务提供高实时性响应的处理（比传统操作系统快得多），而传统 Linux 操作系统在处理大量不同任务方面更有效。

比较

LinuxRTOS
实时性软实时，Linux 有许多调度选项，包括实时调度程序，但这充其量是“软”实时，实时Linux中的典型延迟将在几十或几百微秒左右，像Linux这样的通用操作系统（GPOS）通常使用循环等优先级分时调度程序，在许多进程中“公平”地分配时间。因此，运行处理的越多，它们越忙（使用更多的可用时间片），它的响应就越慢。硬实时，典型的RTOS实时内核可以实现从零到几微秒的延迟（最坏情况下，不是平均时间）。RTOS通常具有基于抢占优先级的调度程序，因此优先级最高的就绪任务无论如何都会立即运行，并将继续运行，直到它挂起自身或更高优先级的任务准备就绪。注意，并不是说把程序放到 RTOS 中，程序就会自动变得实时了，开发者必须适当地分配优先级，以确保所有任务每次都按时运行。通常，具有最短和最确定性运行时的任务应具有最高优先级。
资源需求最初Linux是为台式PC开发的（基于x86处理器架构）。需要大量的CPU资源，可能是>200MIPS，32位处理器，理想情况下需要带MMU，4Mb的ROM和16MB的RAM来启动（可能需要几秒钟），它通常无法在 8 位或 16 位 MCU 上运行，并且需要更多的板载 RAM 用于 Linux 内核。例如，基于ARM Cortex-M架构的MCU，通常只有几百千字节的RAM，Linux无法在这些芯片上运行。RTOS可以在几毫秒内启动，在8位以上的微控制器上运行不到10Kb。一个非常简单的设置，运行两个任务，一个调度程序，一个通信队列和一个8位架构上的信号量，需要的 RAM 可能在 200字节左右
安全性高，Linux 使用适当的进程分离，其中应用程序无法访问其他进程或内核本身使用的内存。较高
开发友好度代码抽象做的好，方便移植。支持众多软硬件驱动程序，调试和性能分析工具更多更完善支持有限的性能分析的 debug 工具，代码兼容性一般
开发理解难度基于 Linux 的系统中的引导加载程序、内核和根文件系统至少比基于 RTOS 的设计复杂几个数量级。低
设备体积较大较小
低功耗功耗较高。并且了解其功耗控制方法比较难功耗低，提供简单有效的功耗控制方法
成本Linux系统的物料清单（BOM）起价约为20美元左右单芯片微控制器的BOM可能只有3美元左右
硬件驱动程序Linux是现成的硬件驱动程序的统治者，如今许多芯片供应商只提供Linux驱动程序。如果您正在使用的硬件驱动很多很复杂，那么使用现成的 Linux 驱动程序可以大大加快速度支持的硬件驱动有限
选型建议在实时性的细粒度级别上显得不足。但是，在开发友好度方面，开发环境要友好得多，特别是对于那些不深入了解低层代码的人。如果您需要大量内存来完成手头的任务，例如GPS系统所需的大型数据库，那么Linux的额外内存将不是问题。如果您的响应时间基于人类感知（延迟超过 100 毫秒也可以满足需求）， 那么相对较低的实时性性能不是问题。RTOS 只能同时运行少量的任务，尤其是对实时性要求高的少量的任务。代码少得多，复杂性要低得多，出错的可能性要小得多，因此您可以更好地控制整个系统的运行方式。廉价的硬件、快速的响应和愿意做艰苦的开发是 RTOS 的终点，互补的方面指向 Linux。

总结

1）关于物联网应用选择 Linux 还是 RTOS，首先是简单的答案：如果您有实时需求，您应该使用（顾名思义）RTOS。
2）除此之外，一切都取决于您的实际要求（成本、功能）。这也实际上取决于开发人员习惯了什么。配置 Linux 可能非常具有挑战性，有时简单的 RTOS 会更容易。
（谢谢点赞或收藏）

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

物联网应用选择 RTOS 还是 Linux？ 的相关文章

随机推荐

  • 最优化的基本概念

    最优化的基本概念 连续和离散优化问题无约束和约束优化问题随机和确定性优化问题线性和非线性规划问题凸和非凸优化问题全局和局部最优解优化算法 一般来说 xff0c 最优化算法研究可以分为 xff1a 构造最优化模型 确定最优化问题的类型和设计算

  • [RISCV]为RISC-V移植FreeRTOS系列之一 -- 目录结构

    前言 写这篇文章的时候 xff0c 我基本已经完成了这项工作了 xff0c 花了一周的时间来把freertos porting到Andes公司的N25 riscv core上 xff0c 本来其实是想支持国产的RT Thread xff0c

  • [RISCV]为RISC-V移植FreeRTOS系列之三 -- 时基

    前言 书接上回 xff0c 上回说到我们已经做好了准备 xff0c 所谓万事具备 xff0c 就差一场东风 xff0c 而能吹动FreeRTOS这条大船的是什么呢 xff1f 没错 xff0c 聪明的你已经猜到了 xff0c 是时基 有过其

  • [RISCV]为RISC-V移植FreeRTOS系列之四 -- 中断与trap handler

    前言 上回说到了我们已经把系统的心跳动起来了 xff0c 但是这里面还有一个问题 xff0c 我们都知道timer中断 xff0c 中断的trap怎么来的呢 这回就来解决这个事情 作者 xff1a wangyijieonline 链接 xf

  • [RTOS]uCOS、FreeRTOS、RTThread、RTX等RTOS的对比之特点

    最近正好又重新回顾了一下这几款OS xff0c 心里一直有个疑问 xff0c 明明这几款RTOS是这么像 xff0c 为什么还要搞出这么多个来呢 xff0c 最后的结论就是 xff0c 管他呢 xff0c 反正哪个用的顺手用哪个 本篇博客就

  • git submodule

    此文已由作者张磊薪授权网易云社区发布 欢迎访问网易云社区 xff0c 了解更多网易技术产品运营经验 前言 submodule 目前对 git 仓库拆分的已有实现之一 环境 git version 2 7 4 windows 1 准备工作 首

  • FreeRTOS 通信方式

    文章目录 一 消息队列二 信号量三 互斥量四 事件五 通知 一 消息队列 消息队列是一种常用于任务间通信的数据结构 xff0c 队列可以在任务与任务间 中断和任务间传递信息 读写队列均支持超时机制 1 创建队列 QueueHandle t

  • 芯片、模组、开发板的区别与联系-结合ESP32浅谈

    1 从外形说起 xff1a 1 1芯片 没错 xff0c 这块黑色的小硅片就是 芯片 本体 xff08 通常比大拇指还小 xff0c 内部集成了实现特定功能的硬件集成电路 xff09 1 2模组 由上述芯片研发的模组是这样的 xff1a 从

  • 一文读懂局域网、广域网、WLAN、WiFi的联系与区别

    1 引言 最近总有小伙伴问我 xff0c 广域网 局域网的区别与联系 WLAN与WiFi的关系 xff0c 遂写此文 xff0c 以作解答 2 广域网与局域网 广域网 xff08 Wide Area Network xff09 xff0c

  • RTOS 和裸机系统的异同-基于 ESP32 学习双核 FreeRTOS 的使用

    Learning FreeRTOS with esp32 什么是 RTOS 其本质上是运行在小型嵌入式设备上的特殊软件 系统软件 如同手机的安卓系统软件 windows 系统软件 RTOS VS 裸机系统 传统的裸机系统 xff08 无操作

  • u盘打开之后就只有一个快捷方式

    我今天也出现了这种问题 xff0c 百度一下发 现都解决不了 xff0c 然后自己尝试了一个新的方法 xff1a 其实还有一个又简单又好用又快捷的方法就是 1 只要你记得你的U盘里的任何一个文件或者文件夹的名称 xff0c 2 然后搜索U盘

  • FreeRTOS 删除任务

    FreeRTOS 删除任务 概述 任务的删除使用的 API 为 xff1a void vTaskDelete TaskHandle t xTask 任务删除主要是两种情况 xff1a 自删除 xff0c 即在任务本身的 TaskCode 中

  • 使用 stream buffer 传递数据

    使用 stream buffer 传递数据 概述 如前所述 xff0c 队列虽然提供了任务之间传递数据的功能 xff0c 但没有对通知机制进行优化 xff0c 即不方便实现多次采集不同长度的数据 xff0c 然后触发一次通知接收的机制 特性

  • 使用 message buffer 传递数据

    使用 message buffer 传递数据 概述 MessageBuffer xff0c 即消息缓冲区 xff0c 是在流式缓冲区的基础上实现的针对离散消息的专用通信组件 xff0c 其进一步针对 消息 进行设计改进 在 StreamBu

  • FreeRTOS 任务间通信与同步总结

    FreeRTOS 任务任务同步与数据传递 xff08 通信 xff09 总结 概述 本章主要介绍了 RTOS 系统中数据传递的机制 根据数据传递的目的 xff0c 可以分为同步 消息通信两种 其中同步是指协调程序运行的先后顺序 xff0c

  • RTOS 中 Task 之间资源共享示例

    RTOS 中 Task 之间资源共享示例 什么是共享资源 大型项目往往需要创建多个任务 xff0c 任务之间协同合作完成一个大型的功能 在前述的章节中 xff0c 我们讲述了任务间的同步与通信 xff0c 但合作与竞争总是相辅相成的 任务

  • RTOS共享资源保护-优先级反转与解决策略

    RTOS 中的优先级反转与解决策略 概述 上节讲述了可以使用二值信号量实现任务 任务之间的共享资源的保护 二值信号量的确完成了保护共享资源的任务 但在一些情况下 这种策略会带来副作用 即优先级反转 优先级反转是如何产生的 理想情况下 按照我

  • RTOS 驱动开发篇-通过 RTOS 组件实现按键驱动-优化1

    RTOS 驱动开发篇 通过 RTOS 组件实现按键驱动 优化1 概述 一个好的驱动程序需要数据关系清晰 代码可复用性高 并且便于维护 如在 RTOS 驱动开发篇 通过 RTOS 组件实现按键驱动1 中所述的那样 当前的按键驱动代码只是为了让

  • RTOS 驱动开发篇-通过 RTOS 组件实现按键驱动-优化2

    RTOS 驱动开发篇 通过 RTOS 组件实现按键驱动 优化2 概述 一个好的驱动程序需要数据关系清晰 代码可复用性高 并且便于维护 如在 RTOS 驱动开发篇 通过 RTOS 组件实现按键驱动1 中所述的那样 基础版本的按键驱动代码只是为

  • 物联网应用选择 RTOS 还是 Linux？

    物联网应用选择 RTOS 还是 Linux Linux VS RTOS xff0c 我该选哪个 xff1f 引言 在开发设备或系统时 xff0c 您需要做出的最早和最关键的决定之一就是决定它将运行哪种类型的操作系统 操作系统是基于特定硬件的

热门标签