用于嵌入式C应用程序中实时内核的Micro Scheduler? [英] Micro scheduler for real-time kernel in embedded C applications?
问题描述
我正在处理微秒级的时间紧迫的应用程序.我对使用非裸机方法(我的所有项目共有的某种框架或基础)开发应用程序的更便捷方法感兴趣.
I am working with time-critical applications where the microsecond counts. I am interested to a more convenient way to develop my applications using a non bare-metal approach (some kind of framework or base foundation common to all my projects).
在我看来(或根据电子工程师的说法)，RTX，Xenomai，Micrium或VXWorks之类的实时操作系统并不是真正的实时操作系统.因此，我更喜欢谈论 soft-real-time 和 hard-real-time 应用程序. 硬实时应用程序具有小于100 ns的可接受抖动，并且热跳动为100..500微秒(滴答计时器).
A considered real-time operating system such as RTX, Xenomai, Micrium or VXWorks are not really real-time under my terms (or under the terms of electronic engineers). So I prefer to talk about soft-real-time and hard-real-time applications. An hard-real-time application has an acceptable jitter less than 100 ns and a heat-beat of 100..500 microseconds (tick timer).
经过大量有关操作系统的阅读后，我意识到典型的滴答时间是1到10毫秒，每个滴答只能执行一个任务.因此，完成任务通常不只需要花费一个刻度，而大多数可用的操作系统或微内核就是这种情况.
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. Therefore the tasks take usually much more than one tick to complete and this is the case of most available operating systems or micro kernels.
对于我的应用程序，典型任务的持续时间为10..100微秒，几乎没有例外，可以持续超过一个刻度.因此，任何实时操作系统都无法满足我的要求.这就是为什么其他工程师仍然不考虑操作系统，微型或纳米内核的原因，因为它们的工作方式与他们的需求相距太远.我仍然想挣扎一点，以我为例，我现在意识到我必须考虑一个我从未听说过(也许还不存在)的新类别的操作系统.我们将此类别称为 nano-kernel 或 subtick-scheduler
For my applications a typical task has a duration of 10..100 microseconds, with few exceptions that can last for more than one tick. So any real-time operating system cannot not fulfill my requirements. 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. I still want to struggle a bit and in my case I now realize I have to consider a new category of operating system that I never heard about (and that may not exist yet). Let's call this category nano-kernel or subtick-scheduler
在这样梦dream以求的内核中，我会发现:
In such dreamed kernels I would find:
- 2种任务:
- 抢占式任务(在其自己的内存空间中运行)
- 非抢占式任务(在内核空间中运行，并且必须在不到一刻的时间内完成.
- 2 types of tasks:
- Preemptive tasks (that run in their own memory space)
- Non-preemptive tasks (that run in the kernel space and must complete in less than one tick.
为了更好地理解我要寻找的内容，我在下面给出了表示两种类型或内核的图.第一种表示形式是传统内核.任务在每个滴答处执行，并且可能会通过系统调用来中断内核，该系统调用会调用完整的上下文切换.
For a better understanding of what I am looking for I made this figure below that represents the two types or kernels. 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.
第二张图显示了一个子滴答内核调度程序，其中多个任务可以共享相同的滴答中断. 任务1 被召唤了一个最大执行时间值，因此需要2个滴答声才能完成. 任务2 设置的优先级较低，因此完成时会消耗每个刻度的剩余时间. 任务3 是不可抢占的，因此它在内核空间上运行，从而节省了一些宝贵的上下文切换时间.
The second diagram shows a sub-tick kernel scheduler where multiple tasks may share the same tick interrupt. Task 1 was summoned with a maximum execution time value so it needs 2 ticks to complete. Task 2 is set with low priority, so it consumes the remaining time of each tick upon completion. Task 3 is non-preemptive so it operates on the kernel space which save some precious context switch time.
可用的操作系统(例如RTOS，RTAI，VxWorks或µC/OS)不是完全实时的，并且不适用于嵌入式硬实时应用(例如运动控制)，这些应用的典型循环持续时间不超过50到50毫秒. 500微秒.通过分析我的需求，我将调度程序放在了不同的拓扑上，可以在同一滴答中断下执行多个任务.显然，我不是唯一有这种需求的人，我的问题可能只是一种X-Y问题.因此换句话说，我并不是真正在寻找我真正想要的东西.
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. By analyzing my needs I land on different topology for my scheduler were multiple tasks can be executed under the same tick interrupt. Obviously I am not the only one with this kind of need and my problem might simply be a kind of X-Y problem. So said differently I am not really looking at what I am really looking for.
在(很长)简短的介绍之后，我可以提出我的问题:
After this (pretty) long introduction I can formulate my question:
除了朴素的裸机方法(围绕所有主中断顺序写入所有内容)的天真裸机方法之外，还有什么可以满足我的要求的良好现有架构或框架?如果存在这种框架/设计模式，那将被称为什么?
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的工作原理.
Sorry, but first of all, let me say that your entire post is completely wrong and shows complete lack of understanding how preemptive RTOS works.
经过大量有关操作系统的阅读后，我意识到典型的滴答时间是1到10毫秒，每个滴答只能执行一个任务.
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中的滴答频率仅决定两件事:
In reality, a tick frequency in RTOS determines only two things:
- 超时，睡眠等的解决方法，
- 由于循环调度而导致的上下文切换(其中两个或多个具有相同优先级的线程可以长时间同时运行".)
在单个滴答期间(通常持续1到10毫秒，但通常可以将其配置为任意时间)，调度程序可以执行数百或数千个上下文切换.还是没有.当事件到达并以足够高的优先级唤醒线程时，上下文切换将立即发生，而不是下一个滴答.事件可以由线程(发布信号量，向另一个线程发送消息，...)，中断(发布信号量，向队列发送消息，...)，调度程序(超时或超时)发起.诸如此类的东西.)
During a single tick - which typically lasts 1-10ms, but you can usually configure that to be whatever you like - scheduler can do hundreds or thousands of context switches. Or none. When an event arrives and wakes up a thread with sufficiently high priority, context switch will happen immediately, not with the next tick. An event can be originated by the thread (posting a semaphore, sending a message to another thread, ...), interrupt (posting a semaphore, sending a message to a queue, ...) or by the scheduler (expired timeout or things like that).
也有没有系统刻度的RTOS，它们被称为无刻度".在那里，超时分辨率可以达到纳秒级.
There are also RTOSes with no system ticks - these are called "tickless". There you can have resolution of timeouts in the range of nanoseconds.
这就是为什么其他工程师仍然不考虑操作系统，微内核或纳米内核的原因，因为它们的工作方式与他们的需求相距太远.
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.
实际上，这就是为什么这些工程师"应该读点东西，而不是假装什么都不懂，并为不存在的问题寻求创新"的解决方案，这是一个原因.这是完全错误的.
Actually this is a reason why these "engineers" should read something instead of pretending to know everything and seeking "innovative" solutions to non-existing problems. This is completely wrong.
第一个表示形式是传统内核.任务在每次执行时都会执行，并且可能会通过调用系统调用来中断内核，该调用会调用完整的上下文切换.
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的功能，而是您编写应用程序的方式-如果高优先级任务不断在做某事，那么低优先级任务将不有运行的机会.但这仅仅是因为您分配了错误的优先级.
This is not a feature of a RTOS, but the way you wrote your application - if a high priority task is constantly doing something, then lower priority tasks will NOT get any chance to run. But this is just because you assigned wrong priorities.
除非您使用协作式RTOS，但如果您有如此高的要求，为什么要这么做?
Unless you use cooperative RTOS, but if you have such high requirements, why would you do that?
第二张图显示了一个子滴答内核调度程序，其中多个任务可能共享同一滴答中断.
The second diagram shows a sub-tick kernel scheduler where multiple tasks may share the same tick interrupt.
这正是每个抢占式RTOS的工作方式.
This is exactly how EVERY preemptive RTOS works.
可用的操作系统(例如RTOS，RTAI，VxWorks或µC/OS)不是完全实时的，因此不适用于嵌入式硬实时应用(例如运动控制)，这些应用的典型周期可持续不超过50到200毫秒. 500微秒.
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，但随后的开销将非常高...
Completely wrong. In every known RTOS it is not a problem to get a response time down to single microseconds (1-3us) with a chip that has clock in the range of 100MHz. So you actually can run "jobs" which are as short as 10us without too much overhead. You can even have "jobs" as short as 10ns, but then the overhead will be pretty high...
除了朴素的裸机方法(围绕所有主中断顺序写入所有内容)的天真裸机方法之外，还有什么可以满足我的要求的良好现有架构或框架?如果存在这种框架/设计模式，那将被称为什么?
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 执行的.它们在标准的线程"上下文中执行，而滴答中断仅用于将一个线程的上下文切换到另一个线程.
This pattern is called preemptive RTOS. Do note that threads in RTOS are NOT executed in "tick interrupt". They are executed in standard "thread" context, and tick interrupt is only used to switch context of one thread to another.
您在帖子中描述的是一个合作的" RTOS，它 NOT 抢占了线程.您可以在资源极为有限且时序要求较低的系统中使用该功能.在其他所有情况下，您都可以使用抢占式RTOS，它能够立即处理事件.
What you described in your post is a "cooperative" RTOS, which does NOT preempt threads. You use that in systems with extremely limited resources and with low timing requirements. In every other case you use preemptive RTOS, which is capable of handling the events immediately.
这篇关于用于嵌入式C应用程序中实时内核的Micro Scheduler?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
