将 RTOS 和循环执行程序混合在一起有意义吗？
在一个小型嵌入式系统项目中，我们有一些代码希望在线程中运行，因此我们选择在嵌入式 RTOS (eCos) 之上构建。
之前，我们在 main() 中使用了循环执行程序来驱动每个作为状态机实现的任务。 对于某些任务，我们遇到了需要将任务分解为许多细粒度状态的问题，从而使代码变得格外复杂。
当切换到 RTOS 时，我们发现如果我们为每个单独的任务提供其自己的线程，则每个线程堆栈的内存使用量会快速增加。 （我们只有 64k 并且需要用于通信缓冲区的内存）
我们正在考虑使用一个线程来执行我们的通信任务，并使用另一个线程来执行循环执行。 循环执行程序将驱动其他逻辑任务。
像这样混合 RTOS 和循环执行程序有意义吗？
On a small embedded system project we have some code which we would like to run in a thread so we are electing to build in top of an embedded RTOS (eCos).
Previously, we have used a cyclic executive in main() that drove tasks each implemented as a state machine. For some tasks we encountered problems where the task would need to be broken up into many fine grained states thus making the code extra complex.
When switching to an RTOS we found the memory usage for each thread's stack adds up quickly if we give each separate task it's own thread. (we only have 64k and need the memory for our communications buffers)
We are considering using a tread for our communications task and an other thread for a cyclic executive. The cyclic executive will drive the other logical tasks.
Does it make sense to mix an RTOS and cyclic executive like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是一个完全有效的设计。
在我们的一款产品中，我们使用了类似的设计，其中异步 I/O 通道（TCP/IP、2 个串行流）处于各自的任务中，并且我们有一个“主要”任务，该任务将负责多个功能领域。
将任务视为一种简单的分区机制，可以让您简化设计。
This is a perfectly valid design.
In one of our product, we used a similar design, where the asynchronous I/O channels (TCP/IP, 2 serial streams) were in their own tasks and we had a "main" task which would be responsible for multiple areas of functionality.
Think of tasks as simply a partitioning mechanism that allows you to simplify your design.
是的，在一个运行多个“任务”的操作系统线程中拥有一个循环执行程序是有意义的。 事实上，除非两个任务与调度需求发生冲突（一个需要阻塞，一个比另一个任务的优先级更高，而低优先级的任务需要很长时间才能执行，等等），我建议将它们放在同一个线程中。
在您使用没有内存保护的轻量级 RTOS 的情况下尤其如此：单独的线程并不比一个线程更安全（没有地址空间的 MMU 保护），事实上它们可能更危险，因为更需要并发保护。 即使您的 IPC 方案很强大并且不易被程序员误用，它的开销通常也不为零，因此避免需要它可以带来性能提升。
Yes, having a cyclic executive in one OS thread running multiple 'tasks' can make sense. In fact unless two tasks conflict with scheduling needs (one needs to block, one is higher priority than the other and the low-priority one takes a long time to execute, etc.), I'd recommend putting them in the same thread.
This is especially true in the case where you are using a light-weight RTOS with no memory protection: separate threads aren't any safer than one thread (no MMU protection of address spaces), in fact they are potentially more dangerous because of the greater need for concurrency protection. Even if your IPC scheme is robust and not susceptible to misuse by programmers, it's overhead is usually non-zero, so avoiding the need for it can result in performance gains.
如果您查看 FreeRTOS，它们实际上在任务中运行另一个调度程序，有点:)
并且回应其他人，设计听起来没有什么问题。 如果有明确的方式来表达某种东西，那么你的（某些）任务就没有理由不能成为状态机。
If you look at FreeRTOS, they actually run another scheduler in a task, sort of :)
And to echo others, nothing sounds wrong in the design. No reason (some of) your tasks can't be state machines if there's a clear way to express something that way.
这是一个有效的设计，但我认为我根本错过了拥有操作系统的原因。
您计划使用操作系统的哪些功能？
从可用的信息来看，您似乎最终会将任务的复杂性转移到新的主循环中。
It is a valid design, but I think I missed the reason for having the OS at all.
What facilities of the OS are you planning to use?
From the information available it seems that you will end up moving the complexity of the tasks to your new main loop.