【问题标题】:Does it make sense to mix an RTOS and cyclic executive?混合 RTOS 和循环执行程序是否有意义?
【发布时间】:2010-09-12 00:47:48
【问题描述】:

在一个小型嵌入式系统项目中,我们有一些代码希望在线程中运行,因此我们选择在嵌入式 RTOS (eCos) 之上构建。

以前,我们在 main() 中使用了一个循环执行程序,它驱动每个作为状态机实现的任务。对于某些任务,我们遇到了需要将任务分解为许多细粒度状态的问题,从而使代码更加复杂。

当切换到 RTOS 时,我们发现如果我们将每个单独的任务分配给它自己的线程,每个线程堆栈的内存使用量会迅速增加。 (我们只有 64k 并且需要用于通信缓冲区的内存)

我们正在考虑为我们的通信任务使用一个线程,并为循环执行程序使用另一个线程。循环执行器将驱动其他逻辑任务。

像这样混合 RTOS 和循环执行是否有意义?

【问题讨论】:

    标签: multithreading embedded rtos


    【解决方案1】:

    这是一个完全有效的设计。
    在我们的一个产品中,我们使用了类似的设计,其中异步 I/O 通道(TCP/IP,2 个串行流)在它们自己的任务中,我们有一个“主要”任务负责多个功能领域.

    将任务视为简单的分区机制,可让您简化设计。

    【讨论】:

      【解决方案2】:

      是的,在一个运行多个“任务”的操作系统线程中拥有一个循环执行程序是有意义的。事实上,除非两个任务与调度需求冲突(一个需要阻塞,一个优先级高于另一个,低优先级的一个需要很长时间才能执行等),否则我建议将它们放在同一个线程中。

      在您使用没有内存保护的轻量级 RTOS 的情况下尤其如此:单独的线程并不比一个线程更安全(地址空间没有 MMU 保护),实际上它们可能更危险因为对并发保护的需求更大。即使您的 IPC 方案稳健且不易被程序员误用,它的开销通常也不为零,因此避免使用它可以提高性能。

      【讨论】:

        【解决方案3】:

        如果你look at FreeRTOS,他们实际上在一个任务中运行另一个调度程序,有点:)

        为了呼应其他人,设计中没有任何问题。如果有明确的方式来表达某事,那么您的任务(某些)没有理由不能成为状态机。

        【讨论】:

          【解决方案4】:

          这是一个有效的设计,但我认为我完全错过了拥有操作系统的原因。

          您打算使用操作系统的哪些功能?

          从可用信息看来,您最终会将任务的复杂性转移到新的主循环中。

          【讨论】:

          • 抢占式线程能力使我们能够避免在通信任务中构建过于复杂的状态机。通过为通信部分设置一个线程,代码非常简单。如果我们在每个点将其分解为当前具有 sleep(1000) 类型块的状态,则代码基本上将是非常小的状态的意大利面条代码混乱。这是可以做到的,但是,我们宁愿保持代码干净和可维护。其他状态机的范围从简单到有些复杂(一个有大约 15 个状态)。通信状态机将更加协调
          猜你喜欢
          • 1970-01-01
          • 2019-01-13
          • 2010-10-24
          • 2022-01-15
          • 1970-01-01
          • 2015-05-10
          • 1970-01-01
          • 2016-11-18
          • 1970-01-01
          相关资源
          最近更新 更多