Embedded 上下文切换时间-RTO和处理器的角色

在确定上下文切换时间时，RTO起主要作用还是处理器起主要作用？在确定上下文切换时间时，这两个主要参与者之间的份额百分比是多少

---

关于uC/OS-II实时操作系统，有人能说得出来吗？

我想说，两者都很重要，但其实并没有那么简单：

实际的上下文切换时间只是执行切换所需的指令周期数的问题，就像软件中的任何东西一样，它可能被有效地编码，也可能没有。另一方面，在所有其他条件相同的情况下，具有大寄存器集的处理器将需要更多的指令周期来保存上下文；但是拥有一个大的寄存器集可能会使其他代码更加高效

处理器还可以具有直接支持快速上下文切换的体系结构。例如，低8bit 8051有四个重复的寄存器组；因此，上下文切换比寄存器组切换（只要不超过四个线程）稍多一些，并且考虑到硅实验室以100IP的速度生产基于8051的设备，这可能非常快

更复杂的处理器和操作系统可能会使用MMU来提供线程内存保护，这是额外的上下文切换开销，但其好处可能会超过这一点。当然，这样的处理器通常也有较高的时钟频率，这有助于提高性能

因此，总的来说，处理器速度、处理器体系结构、RTOS实现的质量以及RTOS提供的功能都可能影响上下文切换时间。但最终，改善切换时间的最简单方法几乎肯定是增加时钟频率

---

虽然有更多的净空是很好的，如果上下文切换时间是你的项目在任何有信誉的RTOS上的一个成败问题，你应该考虑你的硬件或设计的适用性。您应该以最小化上下文切换的设计为目标。例如，如果ADC转换需要6us，而上下文切换需要20us，那么您最好是忙等待，而不是使用转换完成中断；最好使用DMA传输，尽可能避免在单个数据项上进行上下文切换。

uC/OS-II RTOS是用C编写的，有一些非常特定的部分（可能在汇编中）用于处理器特定的处理。上下文切换将是非常特定于处理器的部分

---

因此，上下文切换时间将在很大程度上取决于所选处理器以及用于使uC/OS-II适应该处理器的特定部分。我相信所有的源代码都是可用的，所以您应该能够看到上下文切换需要多少源代码。我还认为uC/OS-II具有回调功能，可以让您添加一些性能度量代码。

仅就Clifford所说的内容而言，上下文切换时间还取决于触发上下文切换的条件，因此主要取决于基准测试

根据RTOS的实现，在某些情况下，可以直接切换到第一个等待进程，完全绕过调度程序

当然，这在一些基准测试中起到了巨大的推动作用

例如，我们制作了一些基准测试，用于测量传递信号和切换到高优先级进程所需的开销（以µs为单位），这会改变特定的内核配置和目标体系结构：

---

@Alexandre:修复-谢谢。您当然可以自己编辑它。我喜欢这里传达的繁忙等待使用场景。繁忙等待的有趣用法。但是，根据Simon的回答，我觉得它在很大程度上取决于处理器，因为它还决定RTOS的实现。我认为，如果处理器支持较差，那么RTOS无法改善它。@S.Man:uC/OS-II的调度程序在每个优先级上只允许一个任务，因此不支持循环调度。这通常是足够的，并且可能会导致更快的上下文切换时间，而支持每个优先级的循环/多个任务的RTO则需要更快的上下文切换时间。在这种情况下，对于同一个处理器，RTOS实现非常重要——因此答案是“两者都有”。+1用于解决问题的uC/OS-II部分，并提供准确的引导信息。