RTOS的排班原则是什么？针对这个问题，本文详细介绍了相应的分析和解答，希望能帮助更多想要解决这个问题的小伙伴找到更简单易行的方法。
我们的微信推送系列，就是为了帮助你快速对操作系统有一个感性的认识。当然，让人们更好地记住一件复杂的事情，就是找另一件简单的事情来解释它。然而，这种解释方式完全不符合教育应有的严谨逻辑。因此，让我们收回这个不科学的论点，用科学的方法论来表达我们需要阐述的内容。
(1)自己写一个调度算法。
很久以前，我大概记得那是我大二的时候，我开始自己写一个调度算法。它的功能很简单，就是两个“任务”分时交替执行，用定时器来确定这两个任务的运行时间。当时我很高兴地告诉世界，我已经完成了一个“内核”的框架。
现在想来，上面的行为真的是可笑的无知和满足。因为这个算法的实现非常简单。简要说明其原理，即建立两个指向函数的指针变量，然后建立两个函数，用上面两个变量指向它们。定时器开始计时，假设周期为10ms，那么每10ms只需要切换两个变量。这样，如果宏观一点，可以看到两个任务同时运行。
我们再来分析一下上面的事情。听起来很简单，但经不起仔细推敲。它们当然不符合操作系统的任何特性。首先，如果你每个任务的执行时间都小于10ms，那就可以了。如果超过分时分配(10ms)后强制定时器切换，目前还没有完成的数据会完全丢失，没有保存的空间。其次，它的任务不能动态建立和回收。有很多很多的缺点。这是我大三时突然意识到的事情。所以到现在为止，我都不喜欢在主功能中使用定时器生成计数值，根据计数值切换运行功能。为什么呢？因为当你在裸机编程的时候，尤其是某个函数中有大量的通信等待操作的时候，你不能保证每个函数的运行时间刚好小于等于你设置的时间。所以总会出现一些任务根本无法执行的现象。
不幸的是，后来工作后，我发现许多电子工程师都是这样处理他们程序的流程的。
(二)操作系统调度算法原理
我开始研究操作系统，当时自信地用自己的“内核”做了几个项目后，做了一次长距离的Modbus高速通信，因为这个函数中有一个函数CRC校验失败，等待重传。然而，由于高速数据流和长距离，高频信号失真严重，导致误码率较高。因此，这个函数被频繁调用，但事实证明，这个函数很难完全运行。分析了很久的原因后，我终于发现这个函数的执行时间远远超过了我分配给它的运行时间，所以我的调度算法强迫它在完成之前被中断。而且因为没有数据存储机制，整个功能只有执行一半后才能销毁。后来工作之余，我也遇到了其他这样做的工程师，劝他们修改，但还是不肯听，最后导致了严重的错误。从那以后，我宁愿当到最后也不愿用这种方式。
而一个成熟的操作系统内核，其调度算法会在中断当前任务后保存数据。
我们称当前正在运行的任务为“运行状态”，而尚未运行的任务称为“非运行状态”。但是关于“非运行状态”，这只是一个统称，其中包含了很多子状态。我们稍后会详细解释“非运作状态”的具体分类。这里需要注意的是，在我们课程的逻辑中，为了简化操作系统模型，所有特定的非运行状态都是聚合的。在一些高级操作系统中，这个问题需要讨论。
在最基本的分时操作系统中，假设所有任务的优先级都是统一的，时间到了会自动轮询。到时候操作系统会有一个机制来保存还没有完成的正在运行的任务的数据，可以推送到栈中。具体的操作过程是将数据保存在寄存器中，这有点类似于中断函数的调用。然后回收可以回收的内存。然后，为下一个要执行的任务分配内存，最后，执行下一个要执行的任务。到了第一个未完成任务的时候，它会为其重新分配内存，然后取出之前的数据继续执行。这是整个大概的过程。
关于RTOS的日程安排原则问题的答案，我希望在这里分享。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/133186.html
