嵌入式 C 应用程序中实时内核的微调度程序？
Micro scheduler for real-time kernel in embedded C applications?
我正在处理时间关键型应用程序，其中微秒很重要。我对使用非裸机方法（我所有项目通用的某种框架或基础基础）开发我的应用程序的更方便的方法感兴趣。
RTX、Xenomai、Micrium 或 VXWorks 等被认为是实时的操作系统在我看来（或在电子工程师看来）并不是真正实时的。所以我更喜欢谈论软实时和硬实时应用程序。 硬实时 应用程序具有可接受的小于 100 ns 的抖动和 100..500 微秒的热拍（滴答计时器）。
在大量阅读操作系统之后，我意识到典型的滴答时间是 1 到 10 毫秒，每个滴答只能执行一个任务。因此，这些任务通常需要不止一个滴答才能完成，大多数可用的操作系统或微内核都是这种情况。
对于我的应用程序，典型任务的持续时间为 10..100 微秒，只有少数例外情况可以持续超过一个滴答声。所以任何实时操作系统都不能满足我的要求。这就是为什么其他工程师仍然不考虑操作系统、微内核或纳米内核的原因，因为他们的工作方式与他们的需求相差太远。我仍然想挣扎一下，在我的情况下，我现在意识到我必须考虑一种我从未听说过（并且可能还不存在）的新操作系统类别。我们称这个类别为 nano-kernel 或 subtick-scheduler
在这样梦寐以求的内核中，我会发现：
- 2种任务：
- 抢占式任务（即运行在自己的内存中space）
- 非抢占式任务（在内核 space 中 运行 并且必须在一个滴答内完成。
- 确定性内核调度程序（ISR 后达到理论零秒抖动的固定持续时间）
- 能够运行 每次 tick 执行多个任务
为了更好地理解我在寻找什么，我在下面制作了这张代表两种类型或内核的图。第一种表示是传统内核。任务在每次滴答时执行，它可能会通过调用完整上下文切换的系统调用来中断内核。
第二张图显示了一个子节拍内核调度程序，其中多个任务可以共享同一个节拍中断。 任务 1 被召唤时具有最大执行时间值，因此需要 2 个滴答才能完成。 任务 2 设置为低优先级，因此它会在完成时消耗每个 tick 的剩余时间。 任务 3 是非抢占式的，因此它在内核 space 上运行，从而节省了一些宝贵的上下文切换时间。
可用的操作系统，如 RTOS、RTAI、VxWorks 或 µC/OS 不是完全实时的，不适合嵌入式硬实时应用程序，例如运动控制，典型的周期将持续不超过 50 到 500 微秒。通过分析我的需求，我为我的调度程序找到了不同的拓扑结构，多个任务可以在同一个滴答中断下执行。显然我不是唯一有这种需求的人，我的问题可能只是一种 X-Y 问题。所以换句话说，我并不是真的在看我真正在寻找的东西。
在这个（相当）长的介绍之后我可以提出我的问题：
除了所有内容都围绕一个主中断顺序写入的原始裸机方法之外，还有什么可以满足我的要求的现有架构或框架？如果存在这种 framework/design 模式，它会被称为什么？
抱歉，但首先，让我说你的整个 post 是完全错误的，表明完全不了解抢占式 RTOS 的工作原理。
After lots of readings about operating systems I realized that typical tick-time is 1 to 10 milliseconds and only one task can be executed each tick.
这是完全错误的。
实际上，RTOS 中的节拍频率仅决定两件事：
- 超时、休眠等问题的解决，
- 循环调度引起的上下文切换（两个或多个具有相同优先级的线程在很长一段时间内同时"runnable"。
在单个滴答期间 - 通常持续 1-10 毫秒，但您通常可以将其配置为您喜欢的任何时间 - 调度程序可以进行数百或数千次上下文切换。或者 none。当事件到达并唤醒具有足够高优先级的线程时，上下文切换将立即发生，而不是在下一个滴答时发生。事件可以由线程发起（post发送信号量，向另一个线程发送消息，...），中断（post发送信号量，向队列发送消息，... .) 或由调度程序（过期超时或类似的事情）。
还有没有系统时钟的 RTOS - 这些被称为 "tickless"。在那里你可以在纳秒范围内解决超时问题。
That is the reason why other engineers still not consider operating system, micro or nano kernels because the way they work is too far from their needs.
实际上这就是为什么这些 "engineers" 应该阅读一些东西而不是假装什么都知道并寻求 "innovative" 解决不存在的问题的原因。这是完全错误的。
The first representation is the traditional kernel. A task executes at each tick and it may interrupt the kernel with a system call that invoke a full context switch.
这不是 RTOS 的功能，而是您编写应用程序的方式 - 如果高优先级任务不断地做某事，那么低优先级任务将 NOT 得到任何机会运行。但这只是因为你分配了错误的优先级。
除非你使用协同RTOS，但如果你有这么高的要求，你为什么要这样做？
The second diagram shows a sub-tick kernel scheduler where multiple tasks may share the same tick interrupt.
这正是 每个 抢占式 RTOS 的工作方式。
Available operating systems such as RTOS, RTAI, VxWorks or µC/OS are not fully real-time and are not suitable for embedded hard real-time applications such as motion-control where a typical cycle would last no more than 50 to 500 microseconds.
完全错误。在每个已知的 RTOS 中，使用具有 100MHz 时钟范围的芯片将响应时间降低到几微秒 (1-3us) 不是问题。所以你实际上可以 运行 "jobs" 短至 10us 而没有太多开销。您甚至可以 "jobs" 短至 10ns，但这样开销会非常高...
What could be a good existing architecture or framework that can fulfill my requirements other than a naive bare-metal approach where everything is written sequentially around one master interrupt? If this kind of framework/design pattern exists what would it be called?
这种模式称为抢占式 RTOS。请注意，RTOS 中的线程 NOT 在 "tick interrupt" 中执行。它们在标准 "thread" 上下文中执行，tick 中断仅用于将一个线程的上下文切换到另一个线程。
您在 post 中描述的是 "cooperative" RTOS，它 NOT 抢占线程。您可以在资源极其有限且时序要求低的系统中使用它。在所有其他情况下，您使用抢占式 RTOS，它能够立即.
处理事件
我正在处理时间关键型应用程序，其中微秒很重要。我对使用非裸机方法（我所有项目通用的某种框架或基础基础）开发我的应用程序的更方便的方法感兴趣。
RTX、Xenomai、Micrium 或 VXWorks 等被认为是实时的操作系统在我看来（或在电子工程师看来）并不是真正实时的。所以我更喜欢谈论软实时和硬实时应用程序。 硬实时 应用程序具有可接受的小于 100 ns 的抖动和 100..500 微秒的热拍（滴答计时器）。
在大量阅读操作系统之后，我意识到典型的滴答时间是 1 到 10 毫秒，每个滴答只能执行一个任务。因此，这些任务通常需要不止一个滴答才能完成，大多数可用的操作系统或微内核都是这种情况。
对于我的应用程序，典型任务的持续时间为 10..100 微秒，只有少数例外情况可以持续超过一个滴答声。所以任何实时操作系统都不能满足我的要求。这就是为什么其他工程师仍然不考虑操作系统、微内核或纳米内核的原因，因为他们的工作方式与他们的需求相差太远。我仍然想挣扎一下，在我的情况下，我现在意识到我必须考虑一种我从未听说过（并且可能还不存在）的新操作系统类别。我们称这个类别为 nano-kernel 或 subtick-scheduler
在这样梦寐以求的内核中，我会发现：
- 2种任务：
- 抢占式任务（即运行在自己的内存中space）
- 非抢占式任务（在内核 space 中 运行 并且必须在一个滴答内完成。
- 确定性内核调度程序（ISR 后达到理论零秒抖动的固定持续时间）
- 能够运行 每次 tick 执行多个任务
为了更好地理解我在寻找什么，我在下面制作了这张代表两种类型或内核的图。第一种表示是传统内核。任务在每次滴答时执行，它可能会通过调用完整上下文切换的系统调用来中断内核。
第二张图显示了一个子节拍内核调度程序，其中多个任务可以共享同一个节拍中断。 任务 1 被召唤时具有最大执行时间值，因此需要 2 个滴答才能完成。 任务 2 设置为低优先级，因此它会在完成时消耗每个 tick 的剩余时间。 任务 3 是非抢占式的，因此它在内核 space 上运行，从而节省了一些宝贵的上下文切换时间。
可用的操作系统，如 RTOS、RTAI、VxWorks 或 µC/OS 不是完全实时的，不适合嵌入式硬实时应用程序，例如运动控制，典型的周期将持续不超过 50 到 500 微秒。通过分析我的需求，我为我的调度程序找到了不同的拓扑结构，多个任务可以在同一个滴答中断下执行。显然我不是唯一有这种需求的人，我的问题可能只是一种 X-Y 问题。所以换句话说，我并不是真的在看我真正在寻找的东西。
在这个（相当）长的介绍之后我可以提出我的问题：
除了所有内容都围绕一个主中断顺序写入的原始裸机方法之外，还有什么可以满足我的要求的现有架构或框架？如果存在这种 framework/design 模式，它会被称为什么？
抱歉，但首先，让我说你的整个 post 是完全错误的，表明完全不了解抢占式 RTOS 的工作原理。
After lots of readings about operating systems I realized that typical tick-time is 1 to 10 milliseconds and only one task can be executed each tick.
这是完全错误的。
实际上，RTOS 中的节拍频率仅决定两件事：
- 超时、休眠等问题的解决，
- 循环调度引起的上下文切换（两个或多个具有相同优先级的线程在很长一段时间内同时"runnable"。
在单个滴答期间 - 通常持续 1-10 毫秒，但您通常可以将其配置为您喜欢的任何时间 - 调度程序可以进行数百或数千次上下文切换。或者 none。当事件到达并唤醒具有足够高优先级的线程时，上下文切换将立即发生，而不是在下一个滴答时发生。事件可以由线程发起（post发送信号量，向另一个线程发送消息，...），中断（post发送信号量，向队列发送消息，... .) 或由调度程序（过期超时或类似的事情）。
还有没有系统时钟的 RTOS - 这些被称为 "tickless"。在那里你可以在纳秒范围内解决超时问题。
That is the reason why other engineers still not consider operating system, micro or nano kernels because the way they work is too far from their needs.
实际上这就是为什么这些 "engineers" 应该阅读一些东西而不是假装什么都知道并寻求 "innovative" 解决不存在的问题的原因。这是完全错误的。
The first representation is the traditional kernel. A task executes at each tick and it may interrupt the kernel with a system call that invoke a full context switch.
这不是 RTOS 的功能，而是您编写应用程序的方式 - 如果高优先级任务不断地做某事，那么低优先级任务将 NOT 得到任何机会运行。但这只是因为你分配了错误的优先级。
除非你使用协同RTOS，但如果你有这么高的要求，你为什么要这样做？
The second diagram shows a sub-tick kernel scheduler where multiple tasks may share the same tick interrupt.
这正是 每个 抢占式 RTOS 的工作方式。
Available operating systems such as RTOS, RTAI, VxWorks or µC/OS are not fully real-time and are not suitable for embedded hard real-time applications such as motion-control where a typical cycle would last no more than 50 to 500 microseconds.
完全错误。在每个已知的 RTOS 中，使用具有 100MHz 时钟范围的芯片将响应时间降低到几微秒 (1-3us) 不是问题。所以你实际上可以 运行 "jobs" 短至 10us 而没有太多开销。您甚至可以 "jobs" 短至 10ns，但这样开销会非常高...
What could be a good existing architecture or framework that can fulfill my requirements other than a naive bare-metal approach where everything is written sequentially around one master interrupt? If this kind of framework/design pattern exists what would it be called?
这种模式称为抢占式 RTOS。请注意，RTOS 中的线程 NOT 在 "tick interrupt" 中执行。它们在标准 "thread" 上下文中执行，tick 中断仅用于将一个线程的上下文切换到另一个线程。
您在 post 中描述的是 "cooperative" RTOS，它 NOT 抢占线程。您可以在资源极其有限且时序要求低的系统中使用它。在所有其他情况下，您使用抢占式 RTOS，它能够立即.
处理事件