在一个小型嵌入式系统项目中，我们有一些希望在线程中运行的代码，因此我们选择在嵌入式 RTOS (eCos) 之上构建。
以前，我们在 main() 中使用了一个循环执行程序，它驱动每个任务都实现为状态机。对于某些任务，我们遇到了需要将任务分解为许多细粒度状态的问题，从而使代码更加复杂。
当切换到 RTOS 时，我们发现如果我们将每个单独的任务分配给它自己的线程，每个线程堆栈的内存使用量会迅速增加。（我们只有 64k 并且需要用于通信缓冲区的内存）
我们正在考虑为我们的通信任务使用一个线程，并为循环执行程序使用另一个线程。循环执行器将驱动其他逻辑任务。
像这样混合 RTOS 和循环执行是否有意义？
这是一个完全有效的设计。
在我们的一个产品中，我们使用了类似的设计，其中异步 I/O 通道（TCP/IP，2 个串行流）在它们自己的任务中，我们有一个“主要”任务负责多个功能领域.
将任务视为简单的分区机制，可让您简化设计。
是的，在一个运行多个“任务”的操作系统线程中拥有一个循环执行程序是有意义的。事实上，除非两个任务与调度需求冲突（一个需要阻塞，一个优先级高于另一个，低优先级的一个需要很长时间才能执行等），否则我建议将它们放在同一个线程中。
在您使用没有内存保护的轻量级 RTOS 的情况下尤其如此：单独的线程并不比一个线程更安全（没有地址空间的 MMU 保护），事实上它们可能更危险，因为对并发保护的需求更大。即使您的 IPC 方案是健壮的并且不易被程序员误用，它的开销通常也不为零，因此避免使用它可以带来性能提升。
如果您查看 FreeRTOS，它们实际上在任务中运行另一个调度程序，有点:)
为了呼应其他人，设计中没有任何问题。如果有明确的方式来表达某种东西，那么没有理由（某些）你的任务不能成为状态机。
这是一个有效的设计，但我认为我完全错过了拥有操作系统的原因。
您打算使用操作系统的哪些功能？
从可用信息看来，您最终会将任务的复杂性转移到新的主循环中。