前言

本人小白，最近学习了FreeRTOS操作系统，打算做一点记录。
学习的过程中虽然做了点练习，不过都是跟着例程来的，大部分没什么记录必要，本文更多的是零零散散地记录我在学习过程中的一些疑惑与个人见解，可能会有错误还请指出。
这只是一个初学者的简单学习记录，并没有全面系统的知识介绍，学习的话还是要看对应的教程啦。

使用到的工具及版本：
FreeRTOS：V9.0.0

STM32CubeMX版本：6.3.0
HAL库:STM32CubeF4 Firmware Package V1.26.2
MDK-ARM：V5.32.0.0
开发板：野火的霸天虎开发板V2（主控芯片是STM32F407ZGT6）

参考的资料：
野火的《FreeRTOS内核实现与应用开发实战》
FreeRTOS入门手册_中文
FreeRTOS官网提供的介绍。

FreeRTOS学习记录

本文对port部分（移植层面）源码的探究查看的是FreeRTOSv9.0.0\FreeRTOS\Source\portable\RVDS\ARM_CM4_MPU，这是我所使用的开发工具和硬件决定的。其他工具或者硬件上的实现可能不一样。

任务会在什么情况下切换？
1、我们自己编写的程序所引起的任务切换。比如我们自己调用taskYIELD()，或者我们调用的API函数里面包含了任务切换（这种时候往往是当前任务进入阻塞/挂起，又或者是有更高优先级的任务加入了就绪列表，API函数里面会在需要的时候去调用任务切换）。
2、 tick中断里面会触发任务切换。tick由内核的Systick产生，属于内核的定时器/计数器（其设计的本意可能就是供操作系统使用的，为操作系统提供时间度量，我猜的）。
注意： 抢占式调度上面两种情况都存在。协作式调度不存在第2种情况的切换（tick中断的切换），协作式调度中所有的切换都是“显式的”。
显而易见协作式调度比抢占式调度有着更高的CPU效率，毕竟不需要每个tick中断就跑去看看是不是要切换任务。但是它存在着高优先级中断可能得不到快速响应的风险，这取决于我们开发者的程序设计，得看我们是不是在合适的时机调用了任务切换，如果程序结构复杂的话我们可能得时时刻刻考虑是不是该在什么地方进行一次任务切换，这可太麻烦了，有的时候甚至不现实。
通过FreeRTOSConfig.h里面的configUSE_PREEMPTION（0是协作式调度，非0是抢占式调度）决定调度类型。
tick中断源码与任务切换源码
系统tick依赖于Cotex-M4的SysTick硬件中断资源，任务切换依赖于PendSV硬件中断资源（注：下图的SysTick及之前的中断是属于内核的，后面的是芯片厂商的）

来看看SysTick_Handler（systick中断函数）。

void SysTick_Handler(void)
{   #if (INCLUDE_xTaskGetSchedulerState  == 1 )if (xTaskGetSchedulerState() != taskSCHEDULER_NOT_STARTED){#endif  /* INCLUDE_xTaskGetSchedulerState */  xPortSysTickHandler();#if (INCLUDE_xTaskGetSchedulerState  == 1 )}#endif  /* INCLUDE_xTaskGetSchedulerState */
}

如果调度器此时压根还没开启，或者调用了vTaskEndScheduler( void )，那么这里的xPortSysTickHandler()并不会执行，系统节拍则不会增加（当然前提是宏INCLUDE_xTaskGetSchedulerState定义为1）。调度器如果挂起，系统时间依然会增加。
接下来看看xPortSysTickHandler()里面是啥。

void xPortSysTickHandler( void )
{/* The SysTick runs at the lowest interrupt priority, so when this interruptexecutes all interrupts must be unmasked.  There is therefore no need tosave and then restore the interrupt mask value as its value is alreadyknown - therefore the slightly faster vPortRaiseBASEPRI() function is usedin place of portSET_INTERRUPT_MASK_FROM_ISR(). */vPortRaiseBASEPRI();{/* Increment the RTOS tick. */if( xTaskIncrementTick() != pdFALSE ){/* A context switch is required.  Context switching is performed inthe PendSV interrupt.  Pend the PendSV interrupt. */portNVIC_INT_CTRL_REG = portNVIC_PENDSVSET_BIT;}}vPortClearBASEPRIFromISR();
}

首先调用了vPortRaiseBASEPRI()把中断屏蔽，它的实现利用了Cotex-M4内核的BASEPRI register（这张图是从《STM32F4xx-Cortex_-M4内核参考手册》截的）。

然后调用的xTaskIncrementTick() 则是实现了：
1、系统tick加1（无论调度器是否挂起）
2、如果tick溢出，把延时列表和延时溢出列表交换
3、处理延时列表的事宜
4、如果是抢占式调度，会返回pdTRUE，这样接下来就会把PendSV中断标志位置位，进入PendSV中断服务完成任务切换。如果是协作式调度则返回pdFALSE，不会置位PendSV中断标志。

接下来看看PendSV_Handler（PendSV中断函数，用于任务切换）。

有关R14与R15(PC)寄存器的描述（我在网上找的）

R14称为子程序链接寄存器LR(Link Register),当执行子程序调用指令(BL)时,R14可得到R15(程序计数器PC)的备份。在每一种运行模式下，都可用R14保存子程序的返回地址，当用BL或BLX指令调用子程序时，将PC的当前值复制给R14，执行完子程序后，又将R14的值复制回PC，即可完成子程序的调用返回。

寄存器R15用作程序计数器(PC),在ARM状态下,位[1:0]为0,位[31:2]用于保存PC,在Thumb状态下,位[0]为0,位[31:1]用于保存PC。由于ARM体系结构采用了多级流水线技术，对于ARM指令集而言，PC总是指向当前指令的下两条指令的地址,即PC的值为当前指令的地址值加8个字节程序状态寄存器。

一开始我只找了R14的描述，然后觉得很奇怪，上图中的程序怎么会跳到R14（PC的内容）所指的地址呢，不应该是PC+1吗（我只了解一点51内核，cortex-M内核还没怎么了解，以后有时间得看看它的内容），所以才查了PC寄存器的内容。
阅读这些汇编代码需要对照ARM与Thumb指令集说明（除非特殊需要，不然应该没什么人会去背这个吧）。可以在keil提供的“帮助”窗口查阅。

任务优先级与中断优先级
中断优先级用于硬件中断管理，属于微处理器内核的内容。cortex-M4的中断优先级数字越大优先级越低。
任务优先级用于调度器的任务管理，属于操作系统的内容。FreeRTOS中任务优先级数字越大优先级越高。
vTaskDelay相对延时与vTaskDelayUntil绝对延时
我试着写了一段代码来进行说明

void Task_1( void* parameter )
{/* 用于保存上次时间。调用后自动更新 */static portTickType PreviousWakeTime;...PreviousWakeTime = xTaskGetTickCount(); for( ;; ){...               /*假设此处可能切换成了更高优先级的任务并去执行，并假设执行该任务要花费5个tick才会把CPU释放给Task_1*/vTaskDelay(50)        or      vTaskDelayUntil(&PreviousWakeTime，50)    }
}

我画了个非常潦草的图来说明Task_1的运行情况（这里假设Task_1处于运行状态的时间非常短，没有画出来）

可以看到用相对延时的话任务每次被唤醒的时间间隔可能是55个tick，也可能是50个tick，绝对延时则会让任务每次进入就绪的时间是确定的。
关于消息队列、信号量与互斥量
用于进程间通信或同步的手段。信号量与互斥量的创建利用了消息队列的数据结构。它们可以实现任务间的通信，本质上就是函数利用全局变量来对其他函数产生影响（进行通信）。它们可以让等待它们的任务进入阻塞状态。
事件位
相比起消息队列，它的结构更加简单。不能传递值，只传递事件标志。
任务通知
相比起上述的时间和消息队列，它更更简单，不需要创建该对象，也就不需要额外花费RAM空间，因为它是在任务控制块（TCB）里定义了uint32_t类型的变量（用来传递值）和uint8_t类型的变量（用来传递状态）来实现的，它的功能函数的实现也更加简单。（FreeRTOS V8.2.0 才开始支持的）
内存管理方案
heap_1.c：最简单的，只能申请内存，不能进行内存释放，申请内存的时间是一个常量。
heap_2.c：可删除内存。采用了一种最佳匹配算法，但是会产生内存碎片。
heap_3.c：简单地封装了标准 C 库中的 malloc()和 free()函数。此时FreeRTOSConfig.h中的configTOTAL_HEAP_SIZE 宏定义不起作用，使用启动文件里划分的堆空间。
heap_4.c：在heap_2.c的基础上多了合并相邻内存空间的功能。
heap_5.c：在heap_4.c的基础上把外扩RAM也纳入分配空间。
关于“stdint.readme”文件
在C语言的发展过程中会添加新的标准，所以会有C89、C99、C11标准。不同的编译器对标准的支持程度不一样，有的会支持新出的标准而有的则不会。FreeRTOS希望在不同的编译器下都可以编译，所以它没有用C99及C99之后的内容，除了C99引进的stdint.h。这个文件定义了一些整数类型和宏。
如果编译器不提供stdint.h的话，就把FreeRTOS/Source/include路径下的stdint.readme改成stdint.h并放到工程指定的头文件路径下吧。
关于协程
和任务（task）相似的东西，但是对RAM的要求很低，是为存储非常小的情况设计的，但是使用起来有更多的限制，现在用的很少，FreeRTOS官方虽然没有删除协程，但并不再打算更新这部分内容。
关于互斥量的优先级继承机制
一个用来减轻优先级反转危害的措施。当更高优先级的任务（A）要获取一个被低优先级任务（B）占用的互斥量时，A不可避免的要等待B，如果B的优先级临时提高到与A一样，可以避免优先级介于两者的任务这时候掺一脚（假设有任务C，优先级顺序A>C>B，没有优先级继承的话C可能会抢占B，导致A又要等B又要等C执行）。如果不想出现优先级反转，要硬实时之类的，应该是在一开始的设计阶段就要考虑。

在STM32CubeMX中配置FreeRTOS

原本我是计划学习μC/OS的，因为查学习路径的时候网上都推荐μC/OS，不过在使用STM32CubeMX的时候发现它提供了FreeRTOS中间件并可以快速配置，所以选择了先学习FreeRTOS。
STM32CubeMX中FreeRTOS的配置界面。

CMSIS是什么
CMSIS是ARM和一众厂商一起决定的 Cortex-M 处理器系列的通用接口，相当于大家围在一起制定了标准并提供了各种外设函数、实时操作系统和中间设备等在该标准下的通用接口的实现，使用通用接口的话，应用程序可以更简单地在不同厂商的Cortex-M处理器之间反复横跳（移植更方便），V2表示版本2。
版本选择不了，STM32CubeMX里面好像只能用新版本的FreeRTOS。
点击选项可以看见参数说明等。

创建任务
任务、队列等直接在STM32CubeMX里面就可以创建好，不必在编辑器里面写。
STM32CubeMX默认创建了一个defaultTask，这是一个啥都不做的任务，每次执行就阻塞1个tick。
我创建了两个任务

关于优先级
单从配置的名字看不出具体的优先级数字，只能看出优先级先后。我在cmsis_os2.h里面找到它的定义。

/// Priority values.
typedef enum {osPriorityNone          =  0,         ///< No priority (not initialized).osPriorityIdle          =  1,         ///< Reserved for Idle thread.osPriorityLow           =  8,         ///< Priority: lowosPriorityLow1          =  8+1,       ///< Priority: low + 1osPriorityLow2          =  8+2,       ///< Priority: low + 2osPriorityLow3          =  8+3,       ///< Priority: low + 3osPriorityLow4          =  8+4,       ///< Priority: low + 4osPriorityLow5          =  8+5,       ///< Priority: low + 5osPriorityLow6          =  8+6,       ///< Priority: low + 6osPriorityLow7          =  8+7,       ///< Priority: low + 7osPriorityBelowNormal   = 16,         ///< Priority: below normalosPriorityBelowNormal1  = 16+1,       ///< Priority: below normal + 1osPriorityBelowNormal2  = 16+2,       ///< Priority: below normal + 2osPriorityBelowNormal3  = 16+3,       ///< Priority: below normal + 3osPriorityBelowNormal4  = 16+4,       ///< Priority: below normal + 4osPriorityBelowNormal5  = 16+5,       ///< Priority: below normal + 5osPriorityBelowNormal6  = 16+6,       ///< Priority: below normal + 6osPriorityBelowNormal7  = 16+7,       ///< Priority: below normal + 7osPriorityNormal        = 24,         ///< Priority: normalosPriorityNormal1       = 24+1,       ///< Priority: normal + 1osPriorityNormal2       = 24+2,       ///< Priority: normal + 2osPriorityNormal3       = 24+3,       ///< Priority: normal + 3osPriorityNormal4       = 24+4,       ///< Priority: normal + 4osPriorityNormal5       = 24+5,       ///< Priority: normal + 5osPriorityNormal6       = 24+6,       ///< Priority: normal + 6osPriorityNormal7       = 24+7,       ///< Priority: normal + 7osPriorityAboveNormal   = 32,         ///< Priority: above normalosPriorityAboveNormal1  = 32+1,       ///< Priority: above normal + 1osPriorityAboveNormal2  = 32+2,       ///< Priority: above normal + 2osPriorityAboveNormal3  = 32+3,       ///< Priority: above normal + 3osPriorityAboveNormal4  = 32+4,       ///< Priority: above normal + 4osPriorityAboveNormal5  = 32+5,       ///< Priority: above normal + 5osPriorityAboveNormal6  = 32+6,       ///< Priority: above normal + 6osPriorityAboveNormal7  = 32+7,       ///< Priority: above normal + 7osPriorityHigh          = 40,         ///< Priority: highosPriorityHigh1         = 40+1,       ///< Priority: high + 1osPriorityHigh2         = 40+2,       ///< Priority: high + 2osPriorityHigh3         = 40+3,       ///< Priority: high + 3osPriorityHigh4         = 40+4,       ///< Priority: high + 4osPriorityHigh5         = 40+5,       ///< Priority: high + 5osPriorityHigh6         = 40+6,       ///< Priority: high + 6osPriorityHigh7         = 40+7,       ///< Priority: high + 7osPriorityRealtime      = 48,         ///< Priority: realtimeosPriorityRealtime1     = 48+1,       ///< Priority: realtime + 1osPriorityRealtime2     = 48+2,       ///< Priority: realtime + 2osPriorityRealtime3     = 48+3,       ///< Priority: realtime + 3osPriorityRealtime4     = 48+4,       ///< Priority: realtime + 4osPriorityRealtime5     = 48+5,       ///< Priority: realtime + 5osPriorityRealtime6     = 48+6,       ///< Priority: realtime + 6osPriorityRealtime7     = 48+7,       ///< Priority: realtime + 7osPriorityISR           = 56,         ///< Reserved for ISR deferred thread.osPriorityError         = -1,         ///< System cannot determine priority or illegal priority.osPriorityReserved      = 0x7FFFFFFF  ///< Prevents enum down-size compiler optimization.
} osPriority_t;

优先级个数超过32个，可见没有使用硬件优化任务查找（Cortex-M处理器提供了一个计算前导零的指令‘CLZ’可以优化优先级查找）。

关于Timebase Source
Timebase Source如果使用SysTick，那么在生成代码前会有这样的警告。

原因是使用HAL库的一些函数（比如延时）会依赖一个时钟源提供周期的节拍，这和操作系统的tick（心跳）是一样的道理，这里的Timebase Source是设定HA库函数L所依赖的时钟源，如果把时钟源设为内核的SysTick，相当于HAL库和操作系统共用一个“心脏”，如果HAL库的某个功能把“心脏”给停了那么操作系统会受到影响。
给HAL库换一个时钟源就好了，我这里用的TIM1。

顺便一提，HAL库用来记录节拍数的全局变量叫uwTick，FreeRTOS用来记录节拍数的全局变量叫xTickCount。
编写任务函数
创建好任务后产生代码，接下来写任务功能就好了，我这里就是简单的点灯，把freetros.c里的任务函数补充好。

/* USER CODE BEGIN Header_Task_LED_Red */
/*** @brief  Function implementing the TASK_LED_RED thread.* @param  argument: Not used* @retval None*/
/* USER CODE END Header_Task_LED_Red */
void Task_LED_Red(void *argument)
{/* USER CODE BEGIN Task_LED_Red *//* Infinite loop */for(;;){HAL_GPIO_TogglePin(LED_RED_GPIO_Port,LED_RED_Pin);osDelay(3000);}/* USER CODE END Task_LED_Red */
}/* USER CODE BEGIN Header_Task_LED_Green */
/**
* @brief Function implementing the TASK_LED_GREEN thread.
* @param argument: Not used
* @retval None
*/
/* USER CODE END Header_Task_LED_Green */
void Task_LED_Green(void *argument)
{/* USER CODE BEGIN Task_LED_Green *//* Infinite loop */for(;;){HAL_GPIO_TogglePin(LED_GREEN_GPIO_Port,LED_GREEN_Pin);osDelay(1000);}/* USER CODE END Task_LED_Green */
}

现象
灯光颜色周期性地变化。

FreeRTOS学习记录相关推荐

FreeRTOS学习记录 05--任务调度器开启和切换
文章目录 0 前言 1 任务调度器的开启 1.1 如何启动第一个任务的 2 任务的切换 2.1 PendSV 异常 2.2 两个事件引起PendSV 异常 2.3 PendSV 的中断服务函数在这里 ...
FreeRTOS学习记录（四）：任务、任务切换(难点)
2022-04-23 依据:[野火]<FreeRTOS内核实现与应用开发实战指南> 目录一.任务二.创建任务 1.定义任务栈 2.定义任务函数 3.定义任务控制块 4.实现任务创建函数 ...
FreeRTOS学习记录 01--中断管理
文章目录 0 前言 1 Cortex-M 中断管理 1.1 中断配置 1.2 优先级分组配置 1.3 FreeRTOS中断 PendSv和Systick中断优先级配置 2 FreeRTOS的临界段代码 ...
FreeRTOS学习记录 04--队列篇
文章目录 0 前言 1 队列的基础知识 1.1 队列 Queue_t 1.2 队列初始化 Dynamic 2 API函数的实现 Application Programming Interface 2. ...
FreeRTOS学习记录 02--任务篇
文章目录 0 前言 1 任务基础知识 1.1 任务优先级 1.2 任务控制块TCB_t 1.3 任务的状态 2 API函数 2.1 任务创建 2.2 任务删除 2.3 任务阻塞 2.4 任务挂起 2. ...
初学者，FreeRTOS学习记录，配合STM32CubeMX（一）
学习FreeRTOS之前,需要先了解RTOS,RTOS全称是Real Time Operating System,中文名是实时操作系统,实时操作系统是保证在一定时间限制内完成特定功能的操作系统.比如u ...
freeRtos学习笔记 (9) 移植和CPU利用率统计
freeRtos学习笔记 (9) 移植和CPU利用率统计使用官方固件移植首先准备一个能跑的裸机工程注意,freertos需要使用systick定时器,而stm32HAL库默认使用systick作 ...
freeRtos学习笔（3）临界区管理
freeRtos学习笔记 freeRtos临界区管理 freeRtos临界区代码的临界段也称为临界区,一旦这部分代码开始执行,则不允许任何中断打断.为确保临界段代码的执行不被中断,在进入临界段之前须 ...
1、野火freertos学习笔记
野火freertos学习笔记 1.任务 1.1 栈 1.2 任务的切换 taskYIELD(); 1.3 临界段 2.空闲任务 3.任务优先级 4.任务延时的表现 5.时间片 5.1抢占式.协做式 6 ...

FreeRTOS学习记录

FreeRTOS学习记录

前言

FreeRTOS学习记录

在STM32CubeMX中配置FreeRTOS

FreeRTOS学习记录相关推荐

最新文章

热门文章