代码之家 › 专栏 › 技术社区 › spade78

为什么我会考虑在我的嵌入式项目中使用RTO?

firmware rtos embedded

spade78 · 技术社区 · 14 年前

首先,我的问题的背景和细节如下:

在我工作的平台公司,我们目前正在使用MPlab-ide作为开发环境的微芯片pic32系列。以前,我们还为这个应用程序编写了微芯片dspic和ti msp系列的固件。固件非常简单,因为代码分为三个主要模块:设备控制、数据采样和用户通信(通常是用户PC)。通过GPIO总线和至少一个需要SPI或I2C控制的部分的组合来实现设备控制。数据采样采用中断驱动,利用定时器模块来保持采样频率,通过更多的SPI/I2C和GPIO总线来控制采样硬件(即ADC)。用户通信目前是通过使用微芯片应用框架的USB实现的。

所以现在的问题是:考虑到我上面所描述的,在什么时候我会考虑为我的项目雇佣一个RTO?目前,我认为这些可能的触发点是使用RTOS的原因:

代码复杂性? 代码基础架构/组织仍然足够小,我可以将所有的细节放在脑子里。
多任务/线程? 通过中断对模块执行进行时间切片现在已经足够多任务处理了。
测试? 目前,我们没有做太多正式的测试或验证通过硬件烟雾测试(我希望在不久的将来纠正)。
沟通? 我们目前使用的是一种定制的包格式和一种协议,该协议几乎只执行启动、停止和发送数据命令,数据是二进制blob。
项目范围? 在不久的将来,我们有可能得到一个项目,将我们的设备集成到一个更大的系统中,目标是使该系统投入批量生产。目前,我们所有的项目都是实验性的原型,一个月的快速周转,一次生产一到两个单元。

你认为我还应该考虑什么?根据您的经验,是什么说服(或强迫)您考虑使用RTOS V,而仅仅是在基本运行时上运行代码?对于为RTOS设计/编程的额外资源,我们也非常感谢。

5 回复 | 直到 14 年前

Dan 14 年前

使用RTO的原因有很多。它们是多种多样的,很难说它们在多大程度上适用于您的情况。(注:我倾向于这样认为:RTOS 暗示很难实时暗示抢占内核…)

速率单调分析 -如果你想用 Rate Monotonic Analysis 为了确保您的时间期限得到满足,您必须使用先发制人的调度程序。
满足实时期限 -即使不使用基于优先级的抢占式RTO的RMA,调度程序也可以帮助确保满足最后期限。矛盾的是,RTO通常会增加 interrupt latency 由于 critical sections 在通常屏蔽中断的内核中
管理复杂性 --当然,RTOS(或大多数OS风格)可以帮助实现这一点。通过允许将项目分解为独立的线程或进程,并使用操作系统服务(如消息队列、互斥、信号量、事件标志等)进行通信和同步,您的项目(以我的经验和观点)变得更易于管理。我倾向于在更大的项目上工作,在那里大多数人都理解保护共享资源的概念,所以不会发生很多新手错误。但是要注意,一旦你采用了多线程的方法,事情可能会变得更加复杂,直到你全神贯注于这些问题。
使用第三方软件包 -许多RTOS提供其他软件组件,如协议栈、文件系统、设备驱动程序、GUI包、引导加载程序和其他中间件,这些组件通过成为比DIY商店更“集成者”来帮助您更快地构建应用程序。
测试 -是的,当然,您可以将每个控制线程视为具有定义良好的接口的可测试组件,特别是在使用一致方法(例如总是在消息队列的单个位置阻塞)的情况下。当然,这不是单元、集成、系统等测试的替代品。
鲁棒性/容错性 -RTOS还可以为处理器的MMU提供支持(在您的PIC中,我认为这不适用)。这允许每个线程(或进程)在自己的受保护空间中运行;线程/进程不能“浸入”彼此的内存并踩在上面。甚至设备区域(MMIO)也可能是某些(或所有)线程的禁区。严格地说,您不需要RTO来利用处理器的MMU(或MPU),但这两个操作非常好,而且是手牵手的。

通常,当我可以使用RTOS(或某种类型的抢占式多任务程序)进行开发时,结果往往更清晰、更模块化、更良好的行为和更可维护性。当我有选择的时候,我用一个。

请注意,多线程开发有一点学习曲线。如果您是RTOS/多线程开发的新手,您可能会对一些有关 Choosing an RTOS , The Perils of Preemption 和 An Introduction to Preemptive Multitasking .

最后,即使你没有提出建议…除了众多的商业RTOS外,还有免费的产品( FreeRTOS 是最受欢迎的一个),以及 Quantum Platform 是基于以下概念的事件驱动框架 active objects 其中包括抢占式内核。有 plenty of choices 但是我发现拥有源代码(即使RTO不是免费的)是有利的,尤其是在调试时。

Ilia 14 年前

RTOS,首先允许您组织 平行流 到一组任务中,它们之间具有定义良好的同步。

在我看来,非RTOS设计只适用于单流架构,其中所有的程序都是一个巨大的无限循环。如果你需要多流程——许多任务,并行运行——你最好使用RTO。如果没有RTOS,你将被迫在内部实现这个功能,重新发明轮子。

Doug Currie 14 年前

编码重用 --如果您使用RTOS API编写驱动程序/协议处理程序代码,它们可能更容易插入到未来的项目中。

调试 --一些IDE(如IAR Embedded Workbench)有插件,可以显示有关运行过程的实时数据,如任务CPU利用率和堆栈利用率。

waffleman 14 年前

通常,如果您有任何实时约束,就要使用RTO。如果您没有实时约束,那么常规操作系统就足够了。RTOS_S/OS_S提供运行时基础设施,如消息队列和任务处理。如果您只是在寻找可以降低复杂性、提供低级支持和测试帮助的代码,那么以下一些库可能会做到:

标准C/C++库
增强图书馆
可通过芯片制造商提供的库,可提供特定于硬件的支持
商业图书馆
开放源代码库

chrmue 14 年前

除了前面提到的要点外,如果您需要对

标准存储设备(SD、闪存、磁盘驱动器…)
标准通信硬件(以太网、USB、火线、RS232、I2C、SPI等)
标准通信协议(TCP-IP,…)

大多数RTOS都提供这些功能或可扩展以支持它们