嵌入式C应用中实时内核的微调度器？

Question

我正在处理时间紧迫的应用程序，其中微秒很重要。我感兴趣的是一种更方便的方法来开发我的应用程序，使用一种非金属方法(某种框架或基本基础，用于我的所有项目)。

考虑过的实时操作系统，如RTX、Xenomai、Micrium或VXWorks，在我的条件下(或在电子工程师的条件下)并不是真正的实时。所以我更喜欢谈论软实时和硬实时应用。硬实时应用程序的抖动小于100 ns，热拍为100..500微秒(滴答定时器).

在阅读了大量关于操作系统的资料之后，我意识到，典型的滴答时间是1到10毫秒，每个滴答只能执行一项任务。因此，这些任务通常需要更多的时间才能完成，这是大多数可用的操作系统或微内核的情况。

对于我的应用程序来说，一个典型的任务的持续时间是10..100微秒，很少有例外，可以持续超过一个滴答。所以任何实时操作系统都不能满足我的要求。这就是为什么其他工程师仍然没有考虑操作系统，微型或纳米内核，因为他们的工作方式离他们的需要太远了。我仍然想挣扎一下，在我的例子中，我现在意识到我必须考虑一个我从未听说过的新的操作系统类别(而且它可能还不存在)。让我们把这个类别称为纳米内核或子调度程序。

在这些梦寐以求的内核中，我会发现：

• 2种任务类型：
  • 抢占式任务(在它们自己的内存空间中运行)
  • 非抢占性任务(在内核空间中运行，并且必须在少于一个滴答的时间内完成)。

​

• 确定性内核调度器(在ISR之后固定持续时间以达到理论上的零秒抖动)
• 每个滴答运行多个任务的能力

为了更好地理解我正在寻找的东西，我在下面的图中表示了这两种类型或内核。第一种表示是传统的内核。任务在每个滴答处执行，它可能会通过调用完整上下文开关的系统调用来中断内核。

第二个图表显示了一个子刻度内核调度器，其中多个任务可能共享相同的刻度中断。使用最大执行时间值调用了Task1，因此它需要两个滴答才能完成。Task 2设置为低优先级，因此在完成时会消耗每个滴答的剩余时间。Task3具有非抢占性，因此它在内核空间上运行，节省了一些宝贵的上下文切换时间。

​

​

可用的操作系统，如实时操作系统、RTAI、VxWorks或C/OS都不是完全实时的，也不适合嵌入式硬实时应用程序，例如运动控制，在这种情况下，一个典型的周期将不超过50到500微秒。通过分析我的需求，我在不同的拓扑上登陆，因为我的调度程序是多个任务，可以在相同的刻度中断下执行。显然，我不是唯一有这种需要的人，我的问题可能只是一个X问题。所以不同的说，我并不是真的在看我真正想要的东西。

经过这个(漂亮的)长的导言，我可以提出我的问题：

除了一种天真的裸金属方法之外，还有什么好的现有架构或框架可以满足我的需求呢?在这种方法中，所有的东西都是围绕一个主中断顺序编写的？如果这种框架/设计模式存在，它会被称为什么？

Answer 1

对不起，但首先，让我说，你的整个帖子是完全错误的，显示完全缺乏了解如何抢占的RTOS的工作。

在阅读了大量关于操作系统的资料之后，我意识到，典型的滴答时间是1到10毫秒，每个滴答只能执行一项任务。

，这是完全错误的，

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

1. 解决超时、睡觉等问题，
2. 由循环调度引起的上下文切换(其中具有相同优先级的两个或多个线程在长时间内同时“可运行”。

在单个滴答(通常持续1-10毫秒，但你通常可以将它配置成任何你想要的东西)期间，调度程序可以完成数百或数千个上下文切换。或者一个都没有。当事件到达并唤醒具有足够高优先级的线程时，上下文切换将发生immediately，，而不是下一个勾号。事件可以由线程发起(发送信号量，向另一个线程发送消息，.)，中断(发送信号量，向队列发送消息，.)或者通过调度程序(过期的超时或类似的事情)。

还有没有系统滴答的RTOSes --它们被称为“无滴答”。在这里，您可以在纳秒范围内获得超时的分辨率。

这就是为什么其他工程师仍然没有考虑操作系统，微型或纳米内核，因为他们的工作方式离他们的需要太远了。

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

第一种表示是传统的内核。任务在每个滴答处执行，它可能会通过调用完整上下文开关的系统调用来中断内核。

这不是RTOS的特性，而是您编写应用程序的方式--如果一个高优先级的任务一直在执行，那么优先级较低的任务将没有任何机会运行。但这仅仅是因为你分配了错误的优先级。

除非你使用合作的实时操作系统，但如果你有这么高的要求，你为什么要这么做？

第二个图表显示了一个子刻度内核调度器，其中多个任务可能共享相同的刻度中断。

这正是每个抢占式实时操作系统的工作方式。

可用的操作系统，如实时操作系统、RTAI、VxWorks或C/OS都不是完全实时的，也不适合嵌入式硬实时应用程序，例如运动控制，在这种情况下，一个典型的周期将不超过50到500微秒。

完全错了。在每个已知的实时操作系统中，用一个时钟在100 the范围内的芯片将响应时间降低到1微秒(1~3US)并不是问题。因此，您实际上可以运行“作业”，它的长度只有10 as，而不需要太多的开销。你甚至可以有短到10纳秒的“工作”，但是开销会很高.

除了一种天真的裸金属方法之外，还有什么好的现有架构或框架可以满足我的需求呢?在这种方法中，所有的东西都是围绕一个主中断顺序编写的？如果这种框架/设计模式存在，它会被称为什么？

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

您在文章中描述的是一个“合作”的RTOS，它不会抢先线程。您可以在资源极其有限且时间要求较低的系统中使用该功能。在所有其他情况下，您都使用抢占式的实时操作系统，它能够处理事件immediately.。