为什么我要考虑在我的嵌入式项目中使用 RTOS？

发布于 2024-09-16 21:51:03 字数 996 浏览 11 评论 0原文

首先介绍一下我的问题的背景和具体情况：

在我工作的公司，我们工作的平台目前是 Microchip PIC32 系列，使用 MPLAB IDE 作为我们的开发环境。此前，我们还为同一应用的 Microchip dsPIC 和 TI MSP 系列编写了固件。固件非常简单，因为代码分为三个主要模块：设备控制、数据采样和用户通信（通常是用户 PC）。设备控制是通过 GPIO 总线线路和至少一个需要 SPI 或 I2C 控制的部分的某种组合来实现的。数据采样由中断驱动，使用定时器模块来维持采样频率，并使用更多 SPI/I2C 和 GPIO 总线来控制采样硬件（即 ADC）。目前，用户通信是使用 Microchip 应用框架通过 USB 实现的。

现在的问题是：鉴于我上面所描述的内容，我在什么时候会考虑为我的项目使用 RTOS？目前，我正在考虑将这些可能的触发点作为使用 RTOS 的原因：

代码复杂性？代码库架构/组织仍然足够小，我可以保留所有细节在我脑海中。
多任务/线程？通过中断对模块执行进行时间切片目前足以满足多任务处理的需要。
测试？目前，我们没有对硬件冒烟测试进行太多正式测试或验证（我希望在不久的将来纠正这一点）。
通信？我们目前使用自定义数据包格式和协议，该协议几乎仅执行 START、STOP、SEND DATA 命令，数据为二进制 blob。
项目范围？在不久的将来，我们有可能会开展一个项目，将我们的设备集成到更大的系统中，目标是将该系统大规模推广生产。目前，我们所有的项目都是实验原型，大约一个月的快速周转，一次生产一到两个单位。

您认为我还应该考虑哪些其他要点？根据您的经验，是什么说服（或迫使）您考虑使用 RTOS，而不是仅在基本运行时上运行代码？有关 RTOS 设计/编程的其他资源的指针也非常受欢迎。

原文

First the background, specifics of my question will follow:

At the company that I work at the platform we work on is currently the Microchip PIC32 family using the MPLAB IDE as our development environment. Previously we've also written firmware for the Microchip dsPIC and TI MSP families for this same application.
The firmware is pretty straightforward in that the code is split into three main modules: device control, data sampling, and user communication (usually a user PC). Device control is achieved via some combination of GPIO bus lines and at least one part needing SPI or I2C control. Data sampling is interrupt driven using a Timer module to maintain sample frequency and more SPI/I2C and GPIO bus lines to control the sampling hardware (ie. ADC). User communication is currently implemented via USB using the Microchip App Framework.

So now the question: given what I've described above, at what point would I consider employing an RTOS for my project? Currently I'm thinking of these possible trigger points as reasons to use an RTOS:

Code complexity? The code base architecture/organization is still small enough that I can keep all the details in my head.
Multitasking/Threading? Time-slicing the module execution via interrupts suffices for now for multitasking.
Testing? Currently we don't do much formal testing or verification past the HW smoke test (something I hope to rectify in the near future).
Communication? We currently use a custom packet format and a protocol that pretty much only does START, STOP, SEND DATA commands with data being a binary blob.
Project scope? There is a possibility in the near future that we'll be getting a project to integrate our device into a larger system with the goal of taking that system to mass production. Currently all our projects have been experimental prototypes with quick turn-around of about a month, producing one or two units at a time.

What other points do you think I should consider? In your experience what convinced (or forced) you to consider using an RTOS vs just running your code on the base runtime? Pointers to additional resources about designing/programming for an RTOS is also much appreciated.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

没企图 2024-09-23 21:51:03

您可能想要使用 RTOS 的原因有很多。他们是多种多样的很难说它们在多大程度上适用于您的情况。（注：我倾向于这样想：RTOS意味着硬实时，意味着抢占式内核...）

速率单调分析 (RMA)< /strong> - 如果您想使用速率单调分析来确保您的时间截止日期如果您
满足实时期限 -即使不使用 RMA，通过基于优先级的抢占式 RTOS，您的调度程序也可以帮助确保满足最后期限。矛盾的是，由于内核中的关键部分，通常会屏蔽中断
管理复杂性 - 当然，RTOS（或大多数操作系统风格）可以帮助解决这个问题。通过允许项目分解为独立的线程或进程，并使用消息队列、互斥体、信号量、事件标志等操作系统服务来进行通信和通信。同步，您的项目（根据我的经验和观点）变得更易于管理。我倾向于从事较大的项目，大多数人都了解保护共享资源的概念，因此不会发生很多新手错误。但要注意，一旦您采用多线程方法，事情可能会变得更加复杂，直到您完全解决问题为止。
使用第 3 方软件包 - 许多 RTOS 提供其他软件组件，例如协议栈、文件系统、设备驱动程序、GUI 软件包、引导加载程序和其他中间件，可帮助您更快地构建应用程序成为几乎更多的“集成商”而不是 DIY 商店。
测试 - 是的，当然，您可以将每个控制线程视为具有定义良好的接口的可测试组件，特别是如果使用一致的方法（例如始终在单个线程中阻塞）放在消息队列中）。当然，这并不能替代单元、集成、系统等测试。
鲁棒性/容错 - RTOS 还可以为处理器的 MMU 提供支持（在您的 PIC 情况下，我认为这不适用）。这允许每个线程（或进程）在自己的受保护空间中运行；线程/进程不能“深入”彼此的内存并践踏它。甚至设备区域 (MMIO) 也可能禁止某些（或全部）线程访问。严格来说，您不需要 RTOS 来利用处理器的 MMU（或 MPU），但这两者可以很好地配合使用。

一般来说，当我可以使用 RTOS（或某种类型的抢占式多任务处理程序）进行开发时，结果往往会更干净、更模块化、更良好且更易于维护。当我有选择时，我会使用其中一个。

请注意，多线程开发有一定的学习曲线。如果您是 RTOS/多线程开发新手，您可能会对选择 RTOS，抢占的危险和抢占式多任务处理简介。

最后，即使您没有寻求建议...除了众多的商业 RTOS 之外，还有免费产品 ( FreeRTOS 是最受欢迎的操作系统之一），以及量子平台是一个基于活动对象概念的事件驱动框架，其中包括抢占式核心。有大量选择，但我发现拥有源代码（即使RTOS 不是免费的）是有利的，尤其是。调试时。

There are many many reasons you might want to use an RTOS. They are varied & the degree to which they apply to your situation is hard to say. (Note: I tend to think this way: RTOS implies hard real time which implies preemptive kernel...)

Rate Monotonic Analysis (RMA) - if you want to use Rate Monotonic Analysis to ensure your timing deadlines will be met, you must use a pre-emptive scheduler
Meet real-time deadlines - even without using RMA, with a priority-based pre-emptive RTOS, your scheduler can help ensure deadlines are met. Paradoxically, an RTOS will typically increase interrupt latency due to critical sections in the kernel where interrupts are usually masked
Manage complexity -- definitely, an RTOS (or most OS flavors) can help with this. By allowing the project to be decomposed into independent threads or processes, and using OS services such as message queues, mutexes, semaphores, event flags, etc. to communicate & synchronize, your project (in my experience & opinion) becomes more manageable. I tend to work on larger projects, where most people understand the concept of protecting shared resources, so a lot of the rookie mistakes don't happen. But beware, once you go to a multi-threaded approach, things can become more complex until you wrap your head around the issues.
Use of 3rd-party packages - many RTOSs offer other software components, such as protocol stacks, file systems, device drivers, GUI packages, bootloaders, and other middleware that help you build an application faster by becoming almost more of an "integrator" than a DIY shop.
Testing - yes, definitely, you can think of each thread of control as a testable component with a well-defined interface, especially if a consistent approach is used (such as always blocking in a single place on a message queue). Of course, this is not a substitute for unit, integration, system, etc. testing.
Robustness / fault tolerance - an RTOS may also provide support for the processor's MMU (in your PIC case, I don't think that applies). This allows each thread (or process) to run in its own protected space; threads / processes cannot "dip into" each others' memory and stomp on it. Even device regions (MMIO) might be off limits to some (or all) threads. Strictly speaking, you don't need an RTOS to exploit a processor's MMU (or MPU), but the 2 work very well hand-in-hand.

Generally, when I can develop with an RTOS (or some type of preemptive multi-tasker), the result tends to be cleaner, more modular, more well-behaved and more maintainable. When I have the option, I use one.

Be aware that multi-threaded development has a bit of a learning curve. If you're new to RTOS/multithreaded development, you might be interested in some articles on Choosing an RTOS, The Perils of Preemption and An Introduction to Preemptive Multitasking.

Lastly, even though you didn't ask for recommendations... In addition to the many numerous commercial RTOSs, there are free offerings (FreeRTOS being one of the most popular), and the Quantum Platform is an event-driven framework based on the concept of active objects which includes a preemptive kernel. There are plenty of choices, but I've found that having the source code (even if the RTOS isn't free) is advantageous, esp. when debugging.

回复收藏 0 原文