STM32

STM32CubeMX学习笔记（35）——FreeRTOS实时操

2022-01-06  本文已影响0人  Leung_ManWah

一、FreeRTOS简介

FreeRTOS 是一个可裁剪、可剥夺型的多任务内核，而且没有任务数限制。FreeRTOS 提供了实时操作系统所需的所有功能，包括资源管理、同步、任务通信等。

FreeRTOS 是用 C 和汇编来写的，其中绝大部分都是用 C 语言编写的，只有极少数的与处理器密切相关的部分代码才是用汇编写的，FreeRTOS 结构简洁，可读性很强！最主要的是非常适合初次接触嵌入式实时操作系统学生、嵌入式系统开发人员和爱好者学习。

最新版本 V9.0.0（2016年），尽管现在 FreeRTOS 的版本已经更新到 V10.4.1 了，但是我们还是选择 V9.0.0，因为内核很稳定，并且网上资料很多，因为 V10.0.0 版本之后是亚马逊收购了FreeRTOS之后才出来的版本，主要添加了一些云端组件，一般采用 V9.0.0 版本足以。

二、新建工程

1. 打开 STM32CubeMX 软件，点击“新建工程”

2. 选择 MCU 和封装

3. 配置时钟
RCC 设置，选择 HSE(外部高速时钟) 为 Crystal/Ceramic Resonator(晶振/陶瓷谐振器)


选择 Clock Configuration，配置系统时钟 SYSCLK 为 72MHz
修改 HCLK 的值为 72 后，输入回车，软件会自动修改所有配置

4. 配置调试模式
非常重要的一步，否则会造成第一次烧录程序后续无法识别调试器
SYS 设置，选择 Debug 为 Serial Wire

三、SYS Timebase Source

在 System Core 中选择 SYS ，对 Timebase Source 进行设置，选择 TIM1 作为HAL库的时基（除了 SysTick 外都可以）。

在基于STM32 HAL的项目中，一般需要维护的 “时基” 主要有2个：

  1. HAL的时基，SYS Timebase Source
  2. OS的时基（仅在使用OS的情况下才考虑）

而这些 “时基” 该去如何维护，主要分为两种情况考虑：

强烈建议用户在使用FreeRTOS的时候，不要使用 SysTick（滴答定时器）作为 “HAL的时基”，因为FreeRTOS要用，最好是要换一个！！！如果共用，潜在一定风险。

四、FreeRTOS

4.1 参数配置

在 Middleware 中选择 FREERTOS 设置，并选择 CMSIS_V1 接口版本


CMSIS是一种接口标准，目的是屏蔽软硬件差异以提高软件的兼容性。RTOS v1使得软件能够在不同的实时操作系统下运行（屏蔽不同RTOS提供的API的差别），而RTOS v2则是拓展了RTOS v1，兼容更多的CPU架构和实时操作系统。因此我们在使用时可以根据实际情况选择，如果学习过程中使用STM32F1、F4等单片机时没必要选择RTOS v2，更高的兼容性背后时更加冗余的代码，理解起来比较困难。

在 Config parameters 进行具体参数配置。

Kernel settings：

Memory management settings：

Hook function related definitions：

Run time and task stats gathering related definitions：

Co-routine related definitions：

Software timer definitions：

Interrupt nesting behaviour configuration：

4.2 内存管理策略

在 Config parameters 的 Memory management settings 中默认内存管理策略为 heap_4

五、UART串口打印

查看 STM32CubeMX学习笔记（6）——USART串口使用

六、生成代码

输入项目名和项目路径


选择应用的 IDE 开发环境 MDK-ARM V5

每个外设生成独立的 ’.c/.h’ 文件
不勾：所有初始化代码都生成在 main.c
勾选：初始化代码生成在对应的外设文件。 如 GPIO 初始化代码生成在 gpio.c 中。

点击 GENERATE CODE 生成代码

七、内存管理

7.1 基本概念

FreeRTOS 操作系统将内核与内存管理分开实现，操作系统内核仅规定了必要的内存管理函数原型，而不关心这些内存管理函数是如何实现的，所以在 FreeRTOS 中提供了多种内存分配算法（分配策略），但是上层接口（API）却是统一的。这样做可以增加系统的灵活性：用户可以选择对自己更有利的内存管理策略，在不同的应用场合使用不同的内存分配策略。

在嵌入式程序设计中内存分配应该是根据所设计系统的特点来决定选择使用动态内存分配还是静态内存分配算法，一些可靠性要求非常高的系统应选择使用静态的，而普通的业务系统可以使用动态来提高内存使用效率。静态可以保证设备的可靠性但是需要考虑内存上限，内存使用效率低，而动态则是相反。

每当任务，队列或是信号量被创建时，内核需要进行动态内存分配。虽然可以调用标准的 malloc()与 free()库函数，但必须承担以下若干问题：

  1. 这两个函数在小型嵌入式系统中可能不可用，小型嵌入式设备中的 RAM 不足。
  2. 这两个函数的具体实现可能会相对较大，会占用较多宝贵的代码空间。
  3. 这两个函数通常不具备线程安全特性。
  4. 这两个函数具有不确定性。每次调用时的时间开销都可能不同。
  5. 这两个函数会产生内存碎片。
  6. 这两个函数会使得链接器配置得复杂。

FreeRTOS 对内存管理做了很多事情，FreeRTOS 的 V9.0.0 版本为我们提供了 5 种内存管理算法，分别是 heap_1.c、heap_2.c、heap_3.c、heap_4.c、heap_5.c，源文件存放于 FreeRTOS\Source\portable\MemMang 路径下，在使用的时候选择其中一个添加到我们的工程中去即可。

FreeRTOS 的内存管理模块通过对内存的申请、释放操作，来管理用户和系统对内存的使用，使内存的利用率和使用效率达到最优，同时最大限度地解决系统可能产生的内存碎片问题。

7.2 内存管理方案

7.2.1 heap_1.c

heap_1.c 管理方案是 FreeRTOS 提供所有内存管理方案中最简单的一个，它只能申请内存而不能进行内存释放，并且申请内存的时间是一个常量，这样子对于要求安全的嵌入式设备来说是最好的，因为不允许内存释放，就不会产生内存碎片而导致系统崩溃，但是也有缺点，那就是内存利用率不高，某段内存只能用于内存申请的地方，即使该内存只使用一次，也无法让系统回收重新利用。

实际上，大多数的嵌入式系统并不会经常动态申请与释放内存，一般都是在系统完成的时候，就一直使用下去，永不删除，所以这个内存管理方案实现简洁、安全可靠，使用的非常广泛。

内 存 分 配 时 需 要 的 总 的 堆 空 间 由 文 件 FreeRTOSConfig.h 中 的 宏 ·configTOTAL_HEAP_SIZE 配置，单位为字。通过调用函数 xPortGetFreeHeapSize() 我们可以知道还剩下多少内存没有使用，但是并不包括内存碎片。这样一来我们可以实时的调整和优化 configTOTAL_HEAP_SIZE 的大小。

heap_1.c 实现了一个非常基本的 pvPortMalloc() 版本，而且没有实现 vPortFree()。


heap1.c 方案具有以下特点：

7.2.2 heap_2.c

heap_2.c 方案与 heap_1.c 方案采用的内存管理算法不一样，它采用一种最佳匹配算法(best fit algorithm)，比如我们申请 100 字节的内存，而可申请内存中有三块对应大小 200 字节， 500 字节和 1000 字节大小的内存块，按照算法的最佳匹配，这时候系统会把 200 字节大小的内存块进行分割并返回申请内存的起始地址，剩余的内存则插回链表留待下次申请。heap_2.c 方案支持释放申请的内存，但是它不能把相邻的两个小的内存块合成一个大的内存块，对于每次申请内存大小都比较固定的，这个方式是没有问题的，而对于每次申请并不是固定内存大小的则会造成内存碎片，后面要讲解的 heap_4.c 方案采用的内存管理算法能解决内存碎片的问题，可以把这些释放的相邻的小的内存块合并成一个大的内存块。

同样的，内存分配时需要的总的内存堆空间由文件 FreeRTOSConfig.h 中的宏 configTOTAL_HEAP_SIZE 配置，单位为字。通过调用函数 xPortGetFreeHeapSize() 我们可以知道还剩下多少内存没有使用，但是并不包括内存碎片，这样一来我们可以实时的调整和优化 configTOTAL_HEAP_SIZE 的大小。

heap_2.c 方案具有以下特点：

7.2.3 heap_3.c

heap_3.c 方案只是简单的封装了标准 C 库中的 malloc()和 free()函数，并且能满足常用的编译器。重新封装后的 malloc()和 free()函数具有保护功能，采用的封装方式是操作内存前挂起调度器、完成后再恢复调度器。

heap_3.c 方案具有以下特点：

要注意的是在 使 用 heap_3.c 方 案 时 ， FreeRTOSConfig.h 文件中的 configTOTAL_HEAP_SIZE 宏定义不起作用。在 STM32 系列的工程中，这个由编译器定义的堆都在启动文件里面设置，单位为字节，我们具体以 STM32F10x 系列为例

7.2.4 heap_4.c

heap_4.c 方案与 heap_2.c 方案一样都采用最佳匹配算法来实现动态的内存分配，但是不一样的是 heap_4.c 方案还包含了一种合并算法，能把相邻的空闲的内存块合并成一个更大的块，这样可以减少内存碎片。heap_4.c 方案特别适用于移植层中可以直接使用 pvPortMalloc()和 vPortFree()函数来分配和释放内存的代码。

内 存 分 配 时 需 要 的 总 的 堆 空 间 由 文 件 FreeRTOSConfig.h 中 的 宏 ·configTOTAL_HEAP_SIZE 配置，单位为字。通过调用函数 xPortGetFreeHeapSize() 我们可以知道还剩下多少内存没有使用，但是并不包括内存碎片。这样一来我们可以实时的调整和优化 configTOTAL_HEAP_SIZE 的大小。

heap_4.c 方案的空闲内存块也是以单链表的形式连接起来的，BlockLink_t 类型的局部静态变量 xStart 表示链表头，但 heap_4.c 内存管理方案的链表尾部则保存在内存堆空间最后位置，并使用 BlockLink_t 指针类型局部静态变量 pxEnd 指向这个区域（而 heap_2.c 内存管理方案则使用 BlockLink_t 类型的静态变量 xEnd 表示链表尾）

heap_4.c 内存管理方案的空闲块链表不是以内存块大小进行排序的，而是以内存块起始地址大小排序，内存地址小的在前，地址大的在后，因为 heap_4.c 方案还有一个内存合并算法，在释放内存的时候，假如相邻的两个空闲内存块在地址上是连续的，那么就可以合并为一个内存块，这也是为了适应合并算法而作的改变。


heap_4.c 方案具有以下特点：

7.2.5 heap_5.c

heap_5.c 方案在实现动态内存分配时与 heap4.c 方案一样，采用最佳匹配算法和合并算法，并且允许内存堆跨越多个非连续的内存区，也就是允许在不连续的内存堆中实现内存分配，比如用户在片内 RAM 中定义一个内存堆，还可以在外部 SDRAM 再定义一个或多个内存堆，这些内存都归系统管理。

heap_5.c 方案通过调用 vPortDefineHeapRegions()函数来实现系统管理的内存初始化，在内存初始化未完成前不允许使用内存分配和释放函数。如创建 FreeRTOS 对象（任务、队列、信号量等）时会隐式的调用 pvPortMalloc()函数，因此必须注意：使用 heap_5.c 内存管理方案创建任何对象前，要先调用 vPortDefineHeapRegions()函数将内存初始化。

heap_5.c 方案具有以下特点：

八、相关API说明

8.1 osPoolCreate

创建内存池。

函数 osPoolId osPoolCreate (const osPoolDef_t *pool_def)
参数 pool_def： 引用由osThreadDef定义的任务
返回值 成功返回内存池ID，失败返回0

8.2 osPoolAlloc

通过内存池开辟空间。

函数 void *osPoolAlloc (osPoolId pool_id)
参数 pool_id： 内存池ID
返回值 成功返回分配的内存块地址，失败返回0

8.3 osPoolCAlloc

通过内存池开辟空间，并初始化为0。

函数 void *osPoolCAlloc (osPoolId pool_id)
参数 pool_id： 内存池ID
返回值 成功返回分配的内存块地址，失败返回0

8.4 osPoolFree

释放开辟的空间。

函数 osStatus osPoolFree (osPoolId pool_id, void *block)
参数 pool_id： 内存池ID

要返回内存池的内存块地址
返回值 错误码

九、示例

Memory Handler定义

/* Private variables ---------------------------------------------------------*/
/* USER CODE BEGIN PV */
osPoolId poolHandle;
/* USER CODE END PV */

Memory分配

/* USER CODE BEGIN Header_StartDefaultTask */
/**
  * @brief  Function implementing the defaultTask thread.
  * @param  argument: Not used
  * @retval None
  */
/* USER CODE END Header_StartDefaultTask */
void StartDefaultTask(void const * argument)
{
  /* USER CODE BEGIN 5 */
  osPoolDef(Memory, 10, uint8_t);               //定义了10个大小为uint8_t的内存池
  poolHandle = osPoolCreate(osPool(Memory));    //创建内存池
  uint8_t *pBuffer = osPoolAlloc(poolHandle);   //申请1个内存地址
  /* Infinite loop */
  for(;;)
  {
    osDelay(1);
  }
  /* USER CODE END 5 */
}

十、注意事项

用户代码要加在 USER CODE BEGIN N 和 USER CODE END N 之间，否则下次使用 STM32CubeMX 重新生成代码后，会被删除。

• 由 Leung 写于 2022 年 1 月 6 日

• 参考：FreeRTOS STM32CubeMX配置 内存管理 任务管理
　　　　STM32内存结构介绍，FreeRTOS内存分配技巧，Stack_Size和Heap_Size大小设置
　　　　STM32CubeIDE（十一）：FreeRTOS选项中Disable、CMSIS_V1和CMSIS_V2的区别
　　　　HAL库中的 SYS Timebase Source 和 SysTick_Handler()

上一篇下一篇

猜你喜欢

热点阅读