STM32CubeMX 生成的代码框架解析 - 最小化工程篇(含FreeRTOS)

咸蛋-超人

已于 2024-03-25 17:05:51 修改

阅读量1.5k

点赞数 11

分类专栏： STM32 文章标签： stm32 嵌入式硬件单片机

于 2024-03-25 17:00:03 首次发布

本文链接：https://blog.csdn.net/Dr_chaser/article/details/137017019

版权

STM32 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

前言

最近因为工作中要用到STM32+FreeRTOS进行开发，因此借助此次机会学习下STM32CubeMX生成的带有FreeRTOS的工程代码。熟悉下其生成代码的结构，以及一些细节。

这篇的话我想首先分析下，最简单的结构是什么样的，即所有的都按照默认来，不增加外设驱动，不对FreeRTOS进行过多的配置，我称之为最小化工程。

后面再通过写一些增加驱动、FreeRTOS的各项配置等来进行对比，进一步加强理解。

1. 创建工程说明

基于STM32L451的芯片进行生成的
在这里插入图片描述
这里选择只复制用到了的库文件，这样整体生成的会相对小一些，没有用到的就不会被copy出来

在这里插入图片描述
FreeRTOS采用CMSIS_V2的接口，这里我理解其实就是对FreeRTOS的封装，因为该软件除了FreeRTOS还支持其它的RTOS，为了生成代码风格统一，所以特制定了一套统一的对RTOS的封装吧。

在这里插入图片描述
如上图所示，硬件驱动相关的操作接口几乎也米有

2. 目录结构介绍

2.1 总目录

在这里插入图片描述
文件夹
总目录下分别有4个文件夹Core、Drivers、MDK-ARM、Middlewares

IDE配置文件
其中两个文件.mxproject和stm32L451_minimal.ioc都和STM32CubeMX这个工具有关

2.2 Core文件夹

在这里插入图片描述
STM32CubeMX 根据配置自动生成的核心代码，和应用相关的后续应该都在这里了。

在这里插入图片描述
我们打开.mxproject这个cubeMX的配置文件，可以看到Core目录下的内容放在
[PreviousGenFiles] 下，这说明该目录里面的内容应该就是根据我们在cubeMX上做的操作生成的。

后续我们可以关注下，是不是我们增加和减少了什么配置后是在这个目录下的文件中体现。

2.3 Drive文件夹

该文件夹存在的主要是对芯片的外设操作接口。

其总共分为两块，分别是CMSIS（处理器封装接口）和HAL（外设驱动的封装接口）

实际上两者的关系应该是HAL调用了CMSIS的接口，可以理解HAL是CMSIS上面的一层。
CMSIS实现

Drivers\CMSIS
Drivers\CMSIS\Device\ST\STM32L4xx\Include
Drivers\CMSIS\Include

CMSIS（Cortex Microcontroller Software Interface Standard）是一种为Cortex-M处理器系列定义一致接口的标准，旨在简化嵌入式软件开发。

这个文件夹包含了针对STMicroelectronics的STM32L4xx系列微控制器的CMSIS设备文件。这些文件包括了特定芯片的寄存器定义、中断向量表等信息，为开发者提供了在特定芯片上进行低层次编程的支持。
在这里插入图片描述

STM32 HAL库

Drivers\STM32L4xx_HAL_Driver
Drivers\STM32L4xx_HAL_Driver\Inc
Drivers\STM32L4xx_HAL_Driver\Src

这里就是放置HAL的驱动了
在这里插入图片描述

2.4 MKD-ARM

在这里插入图片描述
就是keil5的工程文件

2.5 Middlewares

该文件夹中主要放置通过STM32CubeMX生成的一些中间件，即和STM32本身没啥关系的，例如一些RTOS和通信协议等等，cubeMX上集成这些中间件主要也是想简化大家的开发流程。（例如这里FreeRTOS都不用去官网下载了）

我们这里主要用到了FreeRTOS。

在这里插入图片描述

上面我们有说到，middlewares中不仅支持FreeRTOS还有其它的RTOS，那么为了方便开发者能够无缝随时切换不同的RTOS进行开发，就需要根据STM32的一些常用方式形成一套通用的RTOS操作接口。

这样无论底层的RTOS用的是FreeRTOS还是Rt-Thread，我们只需要了解cmsis_os2.h这套接口怎么用就行了。

同时通过调用cmsis中的接口，去间接调用RTOS，还能够做到切换RTOS时，上层应用无需改动，从而大大降低开发的工作量。

2.6 IDE配置文件

.mxproject
STM32CubeMX 根据配置自动生成的核心代码，和应用相关的后续应该都在这里了。

后续我们可以关注下，是不是我们增加和减少了什么配置后是在这个目录下的文件中体现。

stm32L451_minimal.ioc
stm32L451_minimal.ioc文件包含了使用STM32CubeMX进行配置时的所有设置信息，包括引脚分配、时钟配置、外设初始化等内容。

3. 重点文件介绍

3.1 Core文件夹

作为核心文件来说，core下的每个文件可以说都很重要了。

3.1.1 src

我们先看一下src下面有哪些东西

freertos.c

在这里插入图片描述
该文件中应该主要存放应用利用FreeRTOS编写的核心业务代码

这个文件里面当前除了这些注释以外就没什么了，不知道的以为这是个头文件。

但实际上我们从往下看。

Private includes  - 添加自己所需要的头文件
Private typedef  - 定义自己所需要的typedef
....
Private function prototypes  -- 私有函数接口声明，也就是staic的这种要在开头声明下
Private application code -- 编写自己的应用代码

从上述信息中我们可以了解到后续应用代码可能会主要放在这里，又或者说操作FreeRTOS 的配置文件生成的task、timer、信号量等等应该都会在这个文件中产生出来

main.c

该文件中作为应用的起始文件，主要是实现了main()函数。
该函数中对驱动、时钟、os分别进行了初始化，并将os启动起来。

头文件
在这里插入图片描述这里我们看到当调用FreeRTOS时，他不是直接调用FreeRTOS相关的.h，而是直接调用了cmsis_os.h，而这个cmsis_os.h中又包含了cmsis_os2.h。

同时这里还定义了一个OS中task 属性配置的结构体，用于后续生成task。

不过令我感到奇怪的是，为什么task这些不是放到freertos.c中而是放到了main.c中呢？

初始化
在这里插入图片描述
该文件中作为应用的起始文件，主要是实现了main()函数。
该函数中对驱动、时钟、os分别进行了初始化，并将os启动起来。

stm32l4xx_hal_msp.c

时钟相关的操作
在这里插入图片描述

stm32l4xx_it.c

中断函数处理
在这里插入图片描述
中断相关的处理操作，这个里面已经透除了很多的中断处理接口，后续应该我们只需要根据不同的中断使用方式，填入我们自己的处理逻辑即可。

滴答定时器

这里其实有一个很重要的时钟中断，就是设备硬件滴答中断。
为什么说他重要呢？大家可以将其理解为是我们的钟表，钟表帮助我们计时，然后我们在此基础上我们才有了年月日、上下班时间等等。
因此它是一切的基础。

在OS端，在执行不同线程之间的切换时，一般都会采用时间片和优先级的方法，其中时间片的计算就依赖于该定时器。

因该定时器产生的速度很快很频繁，一般情况下1ms一次，所以我们不要在该定时器调用的函数中做什么大量业务的处理。否则会导致整个软件的功能不正常

system_stm32l4xx.c

实现外设的.c文件
在这里插入图片描述

3.1. 2 include

FreeRTOSConfig.h

在这里插入图片描述
一些参数配置，像是系统时钟，堆的大小，taks名称的长度
另外还有是否开启某些功能

3.2 Drive

这部分上面目录结构中已经说过了，这里就没有什么好说的了，主要就是
CMSIS-M4 -> HAL ->应用

3.3 Middlewares

上面目录结构介绍中，我们已经说到为了能够兼容不同的RTOS，ST官网定义了一套自己的CMSIS接口，然后不同的操作系统去适配这套接口，应用则是直接调用这套接口。

3.3.1 CMSIS_RTOS_V2

cmsis_os.h

这是FreeRTOS的头文件
应用层调用FreeRTOS的接口时，只需要将该.h包含进去即可。
它里面

#include "FreeRTOS.h"
#include "task.h"
#include "cmsis_os2.h"

在这里插入图片描述
它里面包含了很多CMSIS FreeRTOS封装的接口

在这里插入图片描述

但是我们看他的注释中有很多的这种接口说明之类的，因此我认为该文件其实更像是一个 CMSIS FreeRTOS的接口兼容层。
里面这里面提到的“replaced osPoolCreate with osMemoryPoolNew”，我们实际查看可以看到osPoolCreate 在cmsis_os.h中
而osMemoryPoolNew在cmsis_os2.h中，且cmsis_os2.c中也只有osMemoryPoolNew的实现。

那么为什么没有osPoolCreate的实现还保留了该接口呢？

我认为就是为了兼容，比如这套接口我之前定义过了，他要兼容各个时期的实现，例如cmsis_os1.c中可能有该实现，且该接口也在被使用着，那么你不能让后续再生成代码的人发现重新生成后原先的接口不能用了，大面积报错要修改吧。为了保证cmsis_os2.h 和cmsis_os1.h 中的接口都各自对应着自己的.c 实现，而不相互影响，又要兼容分别在使用不同接口的用户，所以cmsis_os.h就负责整合他两个的接口了。

cmsis_os2.h/cmsis_os2.c

ST CMSIS RTOS V2版本接口的定义和实现，其中.h中是接口，.c中是如何使用FreeRTOS实现这套接口的。

.h中的接口
在这里插入图片描述
.c中的实现

freertos_mpool.h

这个文件中主要声明了内存池相关的宏定义和结构体
在这里插入图片描述
然后我们可以看到这个结构体的使用并非是应用，而是cmsis_os2.c，在该.c中用于实现
内存池相关的接口。

freertos_os2.h

在这里插入图片描述
我们来翻译下上面框起来的这段信息。

“CMSIS-RTOS2函数osDelay使用FreeRTOS函数vTaskDelay。万一
osDelay没有在应用程序图像中使用，编译器会优化它。设置#define INCLUDE_vTaskDelay 1来修复这个错误。”

在这里插入图片描述
我们再搜索一下INCLUDE_vTaskDelay 这个宏定义，通过上面的内容我们可以看到INCLUDE_vTaskDelay的赋值是在
FreeRTOS的配置文件中兼容的，那么再结合上面freertos_os2.h中的注释解释，我们大概就明白了。

ST借助FreeRTOS去实现cmsis_os2.h中的接口时，用了很多FreeRTOS上的功能，而这些功能需要FreeRTOS去开启，如果关闭了，那么可想而知cmsisi_os2.c中的实现肯定就有问题。

但是ST也控制不住一些人去修改FreeRTOS的配置，那么怎么做呢，它就通过该文件去检查自己所需要的FreeRTOS必要功能是否有开启，如果没开启那么就在编译时给出错误提示。或者直接让编译器进行修改。(这块我还不是很确定，我更加倾向于给出错误提示)

3.3.2 FreeRTOS

include

FreeRTOS.h
FreeRTOS的配置文件
在这里插入图片描述
这里好像还有一些扩展的结构体

MemMang

在 FreeRTOS 中，heap_1.c 到 heap_4.c 是 FreeRTOS 提供的不同内存分配算法的实现，用于动态内存分配。这些文件实现了 FreeRTOS 内存分配所需的函数，每个文件对应不同的内存分配策略，具体说明如下：

heap_1.c:
使用最简单的内存分配策略，所有任务共享一个固定大小的内存池，不支持内存块的释放（只能分配，不能释放）。

heap_2.c:
也是一个简单的内存分配策略，但允许内存块的释放，适合于仅需要少量的内存管理功能的系统。

heap_3.c:
实现了一个更复杂的内存分配算法，通过在运行时动态合并和分割内存块以提高内存利用率。

heap_4.c:
提供了一种高效的内存分配算法，使用了类似于二进制伙伴系统的方法来管理内存池，适用于需要高效内存管理的系统。

我们当前使用的是heap_4.c

src

这里面就是一些 list/task/timer…的实现了，这些我觉得等介绍FreeRTOS的时候再详细介绍，作为使用FreeRTOS来说的话我们最好还是先去熟悉FreeRTOS提供的这些接口，然后根据这些接口的使用方式去探索其实现。

咸蛋-超人

关注

11
点赞
踩
28

收藏

觉得还不错? 一键收藏
0
评论
STM32CubeMX 生成的代码框架解析 - 最小化工程篇(含FreeRTOS)

最近因为工作中要用到STM32+FreeRTOS进行开发，因此借助此次机会学习下STM32CubeMX生成的带有FreeRTOS的工程代码。熟悉下其生成代码的结构，以及一些细节。这篇的话我想首先分析下，最简单的结构是什么样的，即所有的都按照默认来，不增加外设驱动，不对FreeRTOS进行过多的配置，我称之为最小化工程。后面再通过写一些增加驱动、FreeRTOS的各项配置等来进行对比，进一步加强理解。文件夹总目录下分别有4个文件夹Core、Drivers、MDK-ARM、Middlewares。
复制链接

扫一扫