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

在我的条款(或根据电子工程师的条款)下，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微秒。通过分析我的需求，我将调度程序放在了不同的拓扑上，可以在同一滴答中断下执行多个任务。显然，我不是唯一有这种需求的人，我的问题可能只是一种X-Y问题。因此换句话说，我并不是真正在寻找我真正想要的东西。

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

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

抱歉，但首先，我要说您的整个帖子是完全错误的，并且完全不了解抢占式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中的滴答频率仅决定两件事：

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

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

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.

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

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

除非您使用协作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微秒(1-3us)都不是问题。因此，您实际上可以运行短至10us的"作业"而没有太多的开销。您甚至可以将"作业"缩短到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中的线程不会在"滴答中断"中执行。它们在标准的"线程"上下文中执行，而滴答中断仅用于将一个线程的上下文切换到另一个线程。

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