用于嵌入式C应用程序中实时内核的Micro Scheduler？

Question

我正在处理微秒级的时间紧迫的应用程序。 我对使用非裸机方法（我的所有项目共有的某种框架或基础）开发应用程序的更便捷方法感兴趣。

在我的条款（或根据电子工程师的条款）下，RTX，Xenomai，Micrium或VXWorks之类的实时操作系统并不是真正的实时操作系统。 所以我更喜欢谈论软实时和硬实时应用程序。 硬实时应用程序具有小于100 ns的可接受抖动，以及100..500微秒（节拍计时器）的热跳动。

经过大量有关操作系统的阅读后，我意识到典型的滴答时间是1到10毫秒，每个滴答只能执行一个任务。 因此，完成任务通常不只需要花费一个刻度，而大多数可用的操作系统或微内核就是这种情况。

对于我的应用程序，典型任务的持续时间为10..100微秒，很少有例外，可以持续超过一个刻度。 因此，任何实时操作系统都无法满足我的要求。 这就是为什么其他工程师仍然不考虑操作系统，微型或纳米内核的原因，因为它们的工作方式与他们的需求相距太远。 我仍然想挣扎一点，以我为例，我现在意识到我必须考虑一个我从未听说过（也许还不存在）的新型操作系统。 我们称这个类别为nano-kernel或subtick-scheduler

在这些梦想的内核中，我会发现：

• 2种任务：
  • 抢占式任务（在其自己的内存空间中运行）
  • 非抢占式任务（在内核空间中运行，并且必须在不到一刻的时间内完成。
• 确定性内核调度程序（ISR之后达到理论零秒抖动的固定持续时间）
• 能够在每笔交易中运行多个任务

为了更好地理解我要寻找的内容，我在下面给出了表示两种类型或内核的图。 第一种表示形式是传统内核。 任务在每个滴答处执行，并且可能通过调用完整上下文切换的系统调用来中断内核。

第二张图显示了一个子滴答内核调度程序，其中多个任务可以共享同一滴答中断。 任务1具有最大执行时间值，因此需要2个滴答声才能完成。 任务2的优先级较低，因此完成时会消耗每个滴答的剩余时间。 任务3是非抢占式的，因此它在内核空间上运行，从而节省了一些宝贵的上下文切换时间。

可用的操作系统（例如RTOS，RTAI，VxWorks或µC / OS）不是完全实时的，因此不适用于嵌入式硬实时应用（例如运动控制），在这些应用中，典型周期可持续不超过50到500微秒。 通过分析我的需求，我将调度程序放在了不同的拓扑上，可以在同一滴答中断下执行多个任务。 显然，我不是唯一有这种需求的人，我的问题可能仅仅是XY问题。 因此换句话说，我并不是真正在寻找我真正想要的东西。

在这篇（漂亮的）长篇介绍之后，我可以提出我的问题：

除了天真的裸机方法（围绕所有主中断顺序写入所有内容）的天真裸机方法之外，还有什么可以满足我的要求的良好现有架构或框架？ 如果存在这种框架/设计模式，那将被称为什么？

Answer 1

抱歉，但首先，我要说您的整个帖子是完全错误的，并且完全不了解抢占式RTOS的工作原理。

经过大量有关操作系统的阅读后，我意识到典型的滴答时间是1到10毫秒，每个滴答只能执行一个任务。

这是完全错误的。

实际上，RTOS中的滴答频率仅决定两件事：

1. 解决超时，睡眠等问题，
2. 循环调度（其中具有相同优先级的两个或多个线程在较长时间内可同时“运行”）的循环切换。

在一个滴答声中（通常持续1到10毫秒，但通常可以将其配置为自己喜欢的时间），调度程序可以执行数百或数千个上下文切换。 还是没有。 当事件到达并唤醒具有足够高优先级的线程时，上下文切换将立即发生，而不是在下一个滴答声中发生。 事件可以由线程（发布信号量，向另一个线程发送消息，...），中断（发布信号量，向队列发送消息，...），调度程序（超时或超时）发起。像这样的东西）。

也有没有系统刻度的RTOS，它们称为“无刻度”。 在那里，您可以确定的超时分辨率为纳秒级。

这就是为什么其他工程师仍然不考虑操作系统，微型或纳米内核的原因，因为它们的工作方式与他们的需求相距太远。

实际上，这就是为什么这些“工程师”应该阅读一些东西，而不是假装自己了解一切并为不存在的问题寻求“创新”解决方案的原因。 这是完全错误的。

第一种表示形式是传统内核。 任务在每个滴答处执行，并且可能通过调用完整上下文切换的系统调用来中断内核。

这不是RTOS的功能，而是您编写应用程序的方式-如果高优先级任务不断在做某事，那么低优先级任务将不会有运行的机会。 但这仅仅是因为您分配了错误的优先级。

除非您使用协作RTOS，否则如果您有如此高的要求，为什么要这么做？

第二张图显示了一个子滴答内核调度程序，其中多个任务可以共享同一滴答中断。

这正是每个抢占式RTOS的工作方式。

可用的操作系统（例如RTOS，RTAI，VxWorks或µC / OS）不是完全实时的，因此不适用于嵌入式硬实时应用（例如运动控制），在这些应用中，典型周期可持续不超过50到500微秒。

完全错误。 在每个已知的RTOS中，使用时钟频率在100MHz范围内的芯片将响应时间降至1微秒（1-3us）都不是问题。 因此，您实际上可以运行短至10us的“作业”而无需太多开销。 您甚至可以将“作业”缩短至10ns，但是这样的开销将非常高...

除了天真的裸机方法（围绕所有主中断顺序写入所有内容）的天真裸机方法之外，还有什么可以满足我的要求的良好现有架构或框架？ 如果存在这种框架/设计模式，那将被称为什么？

这种模式称为抢占式RTOS。 请注意，RTOS中的线程不会在“滴答中断”中执行。 它们在标准的“线程”上下文中执行，而滴答中断仅用于将一个线程的上下文切换到另一个线程。

你在你的岗位描述是“合作” RTOS， 不抢占线程。 您可以在资源极其有限且时序要求较低的系统中使用它。 在其他所有情况下，您都可以使用抢占式RTOS，它能够立即处理事件。