FreeRTOS入门-概念介绍
原创 thatway 那路谈OS与SoC嵌入式软件 2022-09-03 18:15
FreeRTOS入门-概念介绍
开始前，先抛出一个问题：**我们为什么需要操作系统**
？比如你使用计算器进行加减乘除等运算，人按键输入，最后计算器液晶屏显示结果，这只是一个单任务的操作，并且人的速度很慢，计算器大部分时间都在
空闲等人
。如果一个计算器连出来10个键盘，让10个人同时使用，这个时候就需要一个操作系统来
协调
，这么看来操作系统首先需要一个
调度器
，如上图，这样多个任务就可以同时运行了，其次还需要对各个任务需要的硬件资源进行管理，比如硬盘
、内存
、网卡
，另外还需要支持任务间的**通信**
。如下图，传统操作系统的五大模块：
- 1. 操作系统分类
操作系统一般可分为三种基本类型，即批处理系统、分时系统和实时系统。另外其他扩展的网络操作系统、分布式操作系统、嵌入式操作系统等。
1.1 批处理操作系统
就是把任务汇总
到一块，按顺序排好，然后让计算机一个一个处理，这样计算机一次处理一批任务
，空闲的时间就比较少了。其实就是把调度的工作让人干了，汇总任务是需要人工做的，没有调度这感觉不是操作系统，这现在已经不存在了，在计算机发展的早期还有。1.2 分时操作系统
所谓分时技术就是把处理器的运行时间分成很短的时间片
，按时间片轮流把处理器分配给各联机作业使用。若某个作业在分配给它的时间片内不能完成其计算，则该作业暂时停止运行，把处理器让给其他作业使用，等待下一轮再继续运行。由于计算机速度很快，作业运行轮转得很快，给每个用户的感觉好像是自己独占一台计算机
。例如个人电脑里面的Windows、Linux，手机里面的安卓等都是分时操作系统，也是我们说的普通操作系统。
- 1.3 实时操作系统
实时操作系统
(RealTimeOperatingSystem
，RTOS
)
是指使计算机能及时
响应外部事件的请求在规定的严格时间内完成对该事件的处理，并控制所有实时设备和实时任务协调一致地工作的操作系统。实时操作系统从调度器算法
，到中
断响应系统
，到消息传递机制
等所有的核心算法时间复杂度都是
O
（
1
），它表示系统的响应速度不依赖于系统任务的多少，负载的轻重，而只依赖于优先级的设计，就算当前系统满负荷运行，优先级高的事件发生后，系统还将会在指定的时间内立即响应事件。
这里的时间限制可以分为两种情况：如果某个动作必须绝对地在规定的时刻（或规定的时间范围）发生，则称为**硬实时系统**
。例如，飞行器的飞行自动控制系统，这类系统必须提供绝对保证，让某个特定的动作在规定的时间内完成。如果能够接受偶尔违反时间规定，并且不会引起任何永久性的损害，则称为软实时系统
，如飞机订票系统、银行管理系统。
我们**AUTOSAR****CP**
里面的RTOS就需要硬实时的操作系统。因为对于汽车的控制是需要及时的，不然可能造成事故，正所谓：人命关天
。
1.4 其他操作系统
随着
计算机体系结构
的发展，又出现了许多种操作系统，它们是嵌人式操作系统、个人操作系统、网络操作系统和分布式操作系统。网络操作系统
把计算机网络中的各台计算机有机地结合起来，提供一种统一、经济而有效的使用各台计算机的方法，实现各个计算机之间的互相传送数据。分布式计算机系统
是由多台计算机组成并满足下列条件的系统：系统中任意两台计算机通过通信方式交换信息；系统中的每一台计算机都具有同等的地位，即没有主机也没有从机；每台计算机上的资源为所有用户共享；系统中的任意若千台计算机都可以构成一个子系统，并且还能重构；任何工作都可以分布在几台计算机上，由它们并行工作、协同完成。
最后汇总一个图：
2. OSEK OS
OSEK OS是一个为满足汽车电子可靠性、实时性、成本敏感性
等需求而打造的实时单核操作系统(RTAOS)。具备以下基本特性以及基本系统服务：
**AUTOSAR OS**
是基于OSEK OS继承发展而来，所以上述的OSEK OS的基本特点在AUTOSAR OS都能够得到满足，所以AUTOSAR OS是向后兼容
的，也就意味着在OSEK OS上能够运行的应用程序同样也可以在AUTOSAR OS上运行。
AUTOSAR OS继承OSEK OS，在OSEK OS的基础上又特别明确了AUTOSAR OS至少需要提供的系统服务如下：
基于优先级
的调度；及时的中断处理
的能力；中断优先级必定高于task；
通过StartOS（） 与StartOSHook（）来创建启动接口；
通过ShutdownOS() 与ShutdownOSHook来创建关机接口；
能够在OSEK OS中跑的APP自然也能够在AUTOSAR OS运行，但同时Autosar os也同时限制了OSEK OS的一些基本使用；
3. AUTOSAR OS
3.1 AUTOSAR OS基本对象
AUTOSAR OS总共包含以下6大基本对象：**Counter，Alarm，Schedule Table，Task，ISRs，Resource**
。
这6个基本对象必须归属于一个OS **Application**
，可以简单理解为OS Application是上述6大基本对象的容器，而归属于同一OS Application的基本对象则可以互相访问，来自其他OS Application的基本对象则需要通过配置来限制性访问。
3.2 Task
大家在面试的时候被经常问到的一个问题就是**进程和线程的区别**
，最典型的回答就是进程是系统资源分配的最小单位
，比如分配了内存地址空间、寄存器、独占的虚拟CPU等，线程是CPU调度的最小单位
，线程享用父进程的系统资源，但是自己又可以异步的去执行。
可惜在RTOS里面由于要求实时性，这种异步执行需要等待的机制需要被砍掉，首先没有了线程的概念。那么**进程**
就是对应RTOS里面的Application
，并且这个Application的资源都是独占的
，不进程一样跟其他进程共享的。例如独占一个真实的CPU，这里也叫做MCU，因为性能没那么强悍，但是很稳定。有例如独占一块真实的内存区域，也就是说其资源是启动前就静态分配好的
，不跟其他Application共享的，这里就是静态系统
的概念。
而传统操作系统里面的进程就是**动态系统**
，动态系统资源共享降低了实时性和安全性来提升资源利用率，在AUTOSAR AP
中的微内核OS
中会用到，主要支持一些对安全实时性要求不高的应用。
接下来说本章节的**TASK**
，可以理解为一个for循环
，顺序一遍一遍的去执行的列表中的任务。这些任务组成了一个Application。
AUTOSAR OS中存在两种任务：
基本任务
(Basic Task)和扩展任务
（Extended Task）。
基本任务则存在以下三种状态：
运行状态
(Running)：处于运行状态的任务可能被高优先级任务或者中断抢占从而进入就绪状态，且同一Core中任何时刻只会存在一个任务处于运行状态，任务运
行结束后则将自己挂起进入阻塞状态；
就绪状态
(Ready):处于就绪状态的任务由调度器决定是否启动进入运行状态，且该状态时任务切换至运行状态的前提；
阻塞状态
(Suspend):处于阻塞状态的任务是被动的，可以由API函数或Alarm激活进入就绪状态；
扩展任务与之相比，则多了一个等待状态(Waiting),解释如下：
等待状态
(Waiting)：当任务的运行需要等待某一或某些事件被置位时，任务进入就绪状态。
基本任务与扩展任务的状态机切换如下图所示：
基本任务的代码示例如下：
#include “OS.h”
TASK(BasicTask)
{
...
/*User Code*/
...
TerminateTask();
}
扩展任务的代码示例如下
#include “OS.h”
TASK(ExtendedTask)
{
for(; ;)
{
WaitEvent(Event1);
/*Perform some actions in specific condition*/
ClearEvent(Event1);
}
}
Task调度策略
AUTOSAR OS可根据各个任务的可抢占属性配置，来提供不同的调度策略，调度策略可分为以下三种：
完全抢占式
：OS所有任务均是可抢占类型；
非抢占式
：OS中所有任务均是不可抢占的；
混合抢占式
：OS部分任务是可抢占类型，部分任务是不可抢占类型；
3.3 Counter
Counter概念的引入是为了实现对**硬件计数器**
以及软件计数器
的管理，为Alarm与Schedule table提供支持。即多个Alarm可以共用一个Counter，一个Schedule Table只能由一个Counter来驱动。Counter按照AUTOSAR定义可分为以下两种：
Hardware Counter:该Counter的增加由硬件外设驱动，如Gpt或者timer等；
Software Counter：该Counter的增加通过调用API函数IncrementCounter来实现，且每次只能增加1；
基本原则：优先使用Hardware Counter，因为可以根据Task的激活状况来减少无意义的时钟中断；
3.4 Alarm
在计数器的基础上，AUTOSAR OS为应用软件提供了**闹钟机制**
，多个闹钟可以连接一个Counter，当到达Alarm所对应的计数器设定值时，则可以激活一个任务，设定一个event
，调用callback或者增加计数器等功能，但只能是一对一。
不能像Schedule Table那样，能够在Expiry point同时设定多个Task或者多个Event，这也是为什么引入Schedule Table的原因。
一个软件Counter +多个Alarm队列就可以实现静态定义的任务激活机制。 但随着Schedule Table的引入，因此一般建议能用Schedule Table就不要用Alarm。
3.5 Schedule Table
如上Alarm所述，当计数器的计数值依次达到各个Alarm设定的计数值时，各个Alarm被触发，但很难保证各个Alarm有特定的时间间隔，且每个Alarm只能激活一个Task或者Event，所以需要多个Alarm来协作实现在同一时刻触发多个Task或者Event，因此Schedule
Table应运而生！
Schedule Table会定义一系列终结点(Expiry Point)，且每个调度表都有一个以Tick为单位的持续时间
(Duration)。每个终结点则是以Tick为单位的距离起始点的偏移量(Offset)，在每个终结点可以实现多个Task或者Event的设置。
与报警器类似，一个调度表只能由一个Counter驱动，同时调度表存在以下两种调度方式：
单次执行(Single-Shot): 调度表启动之后 只运行一次，到达调度表终点则终止，即每个终结点只运行一次；
循环执行(Repeating): 调度表启动后可反复执行，到达调度表终点后重头开始执行，则每个终结点会被周期性的执行，一般情况下激活任务采用此模式。
如下图10所示，较为清晰了描述了调度表中Expiry Point与Task，Event激活之间的时序关系。
如下图所示，则较为清晰的表现了Counter，Schedule Table以及Alarm三者之间的关系。
3.6 ISRs
在AUTOSAR中定义了两类中断服务程序(Interrupt Service Routine)为：
一类中断
(Category
I)与二类中断
(Category)。
两者之间的区别定义如下：
Categoty I
：此类中断服务程序不能够使用OS提供的系统服务，当中断执行完成之后则会重新跳转至产生中断的地方继续执行，不会影响到任务的执行，因此占用系统资源较少。
Category II
：该类中断则可以调用OS系统服务，如激活任务或者设置事件等。
在AUTOSAR OS中，中断的优先级始终高于任务的优先级，即最低优先级的中断都可以打断最高优先级的任务，即使该任务不可抢占也不例外。因此，中断服务子程序的执行时间不宜过长，否则会影响到整个系统的实时性。
3.7 Resource Management
Resouce作为OS调度过程中一个十分重要的对象，Resource管理就显得尤为重要。资源管理就是为了
协调具有不同优先级的多个任务或者中断对共享内存（如内存或者硬件等）的并发访问
。
不过幸运的是AUTOSAR OS采用上述的**优先级**
天花板模式来避免任务优先级反转以及死锁问题的发生，即资源的上限优先级必须高于所有该资源的任务以及中断的优先级，但是应低于不访问该资源的任务的最低优先级。
其中为了保护共享资源而提出的锁机制-**自旋锁**
(Spin Lock)。该自旋锁一般用于多核操作系统解决资源互斥的问题。当内核控制必须访问共享数据结构或进入临界区是，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋所的保持者已经释放了该锁，从而达到某共享资源的互斥作用。
4. AS代码中的RTOS
AS代码：
https://github.com/thatway1989/as
里面是有RTOS的，是作者自己写的一个叫做askar
，同时里面还有FreeRTOS
等十个左右的RTOS，下次文章再介绍。
一些关于AUTOSAR的资料，公众号留言：autosar资料
，即可获取链接。
后记：
最比较忙近停更了一段时间，但是公众号的事一直在心里。9月是
开学季
，也是学习的好时节，接下来再接再厉，先写一系列OS入门
的文章，直接介绍五六种OS的入门资料，绝对
够猛够有料
，敬请期待。
参考资料：