3.STM32固件库

编程牛

已于 2024-03-26 09:28:48 修改

阅读量1.1k

点赞数 28

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

于 2024-03-26 09:04:15 首次发布

本文链接：https://blog.csdn.net/knightseasky/article/details/137032505

版权

STM32 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

本文介绍了STM32芯片的固件库，特别是HAL库和CMSIS标准，强调了HAL库在提供跨平台支持、简化开发过程和降低学习曲线方面的优势，以及与标准库的区别。同时，详细解读了库文件结构、各文件夹内容和库间的调用关系，为STM32嵌入式开发者提供了实用指导。

摘要由CSDN通过智能技术生成

如果想单独一对一辅导学习嵌入式、C++、Java、Python编程语言的可以加微信咨询

1. 固件库

STM32芯片不仅仅只有GPIO这一个外设。如果我们想要亲自完成这个函数库，工作量是非常巨大的。ST公司提供的一些封装好的软件库，包含了STM32芯片所有寄存器的控制操作，我们直接学习如何使用ST的这些固件库即可，会极大地方便控制STM32芯片。

1.1 CMSIS标准及库层次关系

因为基于Cortex系列芯片采用的内核都是相同的，区别主要为核外的片上外设的差异，这些差异却导致软件在同内核，不同外设的芯片上移植困难。为了解决不同的芯片厂商生产的Cortex微控制器软件的兼容性问题，ARM与芯片厂商建立了CMSIS标准(Cortex MicroController Software Interface Standard)。

所谓CMSIS标准，实际是新建了一个软件抽象层。
在这里插入图片描述
CMSIS标准中最主要的为CMSIS核心层，它包括了：

内核函数层：其中包含用于访问内核寄存器的名称、地址定义，主要由ARM公司提供。
设备外设访问层：提供了片上的核外外设的地址和中断定义，主要由芯片生产商提供。

可见CMSIS层位于硬件层与操作系统或用户层之间，提供了与芯片生产商无关的硬件抽象层，可以为接口外设、实时操作系统提供简单的处理器软件接口，屏蔽了硬件差异，这对软件的移植是有极大的好处的。STM32的库，就是按照CMSIS标准建立的。

1.2 STM32标准库与HAL（硬件抽象层）库的区别

STM32标准库与HAL（硬件抽象层）库的主要区别在于它们的抽象程度、易用性和对硬件的控制程度。

1.2.1 HAL库：

抽象程度：HAL库提供了一套统一的API，用于访问STM32系列微控制器的外设，实现了跨平台支持，即支持STM32全系列微控制器。
易用性：HAL库简化了固件开发，使得开发者可以更加关注应用层逻辑，而无需深入了解底层硬件。它还与STM32CubeMX工具集成，可以自动生成HAL库的初始代码，方便开发者配置硬件。
学习曲线：HAL库的学习曲线相对较缓，提供了简单而易于使用的函数，开发者无需关注底层的实现细节，从而提高了开发效率。

1.2.2 标准库（SPL）：

抽象程度：标准库是针对特定STM32系列提供的底层驱动，它更接近寄存器操作，为开发者提供了更多的控制权，但相对复杂一些。
易用性：标准库提供了对芯片和外设的底层访问，开发者可以根据自己的需求自由地控制硬件。但是，由于其底层性质，开发者需要花费更多的时间学习和理解。
学习曲线：标准库的学习曲线较陡，因为它提供了更底层的接口，开发者需要了解寄存器的使用和外设的控制方式。

总的来说，HAL库适合初学者和对开发效率要求较高的开发者，它隐藏了底层的复杂性，提供了更高级别的API。而标准库则适合具备一定硬件和嵌入式开发经验的开发人员，它提供了更直接的底层寄存器操作接口，允许开发者更加灵活地控制硬件。所以本文主要介绍HAL库。

1.3 库目录、文件简介

STM32 HAL库可以从官网获得，这里讲解的例程主要是HAL库文件。以下内容需要打开最新的STM32HAL库文件配合阅读。

解压库文件后进入其目录：“STM32Cube_FW_F1_V1.8.0”

软件库各文件夹的内容如下：
在这里插入图片描述
目录：STM32Cube_FW_F1_V1.8.0\

Documentation：文件夹下是HAL库帮助文档，主要讲述如何使用驱动库来编写自己的应用程序。说得形象一点就是告诉我们： ST公司已经为你写好了每个外设的驱动了，想知道如何运用这些例子就来向我求救吧。不幸的是，这个帮助文档是英文的，这对很多英文不好的朋友来说是一个很大的障碍。但这里要告诉大家，英文仅仅是一种工具，绝对不能让它成为我们学习的障碍。其实这些英文还是很简单的，我们需要的是拿下它的勇气。
Drivers：文件夹下是官方的CMSISI库，HAL库，板载外设驱动。
Middlewares：中间件，包含ST官方的STemWin、 STM32_Audio、STM32_USB_Device_Library、STM32_USB_Host_Library；也有第三方的fatfs文件系统等等。
Project ：文件夹下是用驱动库写的针对官方发行demo板的例子和工程模板。
Utilities：实用的公用组件比如LCD_LOG实用液晶打印调试信息。
Release_Note.html:：库的版本更新说明。

在使用库开发时，我们需要把Drivers目录下的CMSIS、STM32F1xx_HAL_Driver内核与外设的库文件添加到工程中，并查阅库帮助文档来了解ST提供的库函数，这个文档说明了每一个库函数的使用方法。

再看看CMSIS文件夹。STM32Cube_FW_F1_V1.8.0\Drivers\CMSIS\文件夹下内容。
在这里插入图片描述
目录：Drivers \CMSIS\

其中Device与Include中的文件是我们使用得最多的，先讲解这两个文件夹中的内容。

1.3.1 Include文件夹

在Include文件夹中包含了的是位于CMSIS标准的核内设备函数层的Cortex-M核通用的头文件，它们的作用是为那些采用Cortex-M核设计SOC的芯片商设计的芯片外设提供一个进入内核的接口，定义了一些内核相关的寄存器(类似我们前面写的stm32F103xx.h文件，但定义的是内核部分的寄存器)。这些文件在其它公司的Cortex-M系列芯片也是相同的。至于这些功能是怎样用源码实现的，可以不用管它，只需把这些文件加进我们的工程文件即可，有兴趣的朋友可以深究，关于内核的寄存器说明，需要查阅一些官方的说明文档，如：《cortex_M3_Technical Reference Manual》。

我们写STM32F1的工程，必须用到其中的四个文件：core_cm3.h、core_cmFunc.h、corecmInstr.h、core_cmSimd.h，其它的文件是属于其它内核的，还有几个文件是DSP函数库使用的头文件。

core_cM3.c文件有一些与编译器相关条件编译语句，用于屏蔽不同编译器的差异。里面包含了一些跟编译器相关的信息，如：“__CC_ARM ”(这里例程采用的RVMDK、KEIL)，“__GNUC__ ”(GNU编译器)、“ICC Compiler” (IAR编译器)。这些不同的编译器对于C嵌入汇编或内联函数关键字的语法不一样，这段代码统一使用“__ASM、__INLINE”宏来定义，而在不同的编译器下，宏自动更改到相应的值，实现了差异屏蔽，见代码如下。

core_cm3.c文件中对编译器差异的屏蔽

   #if   defined ( __CC_ARM )
   #define __ASM            __asm     /*!< asm keyword for ARM Compiler */
   #define __INLINE         __inline  /*!< inline keyword for ARM Compiler*/
   #define __STATIC_INLINE  static __inline

   #elif defined ( __GNUC__ )
   #define __ASM            __asm  /*!< asm keyword for GNU Compiler */
   #define __INLINE         inline /*!< inline keyword for GNU Compiler */
   #define __STATIC_INLINE  static inline

   #elif defined ( __ICCARM__ )
   #define __ASM            __asm  /*!< asm keyword for IAR Compiler */
   /*!< inline keyword for IAR Compiler. */
   #define __STATIC_INLINE  static inline
   #define __INLINE         inline

   #elif defined ( __TMS470__ )
   #define __ASM            __asm  /*!< asm keyword for TI CCS Compiler */
   #define __STATIC_INLINE  static inline

   #elif defined ( __TASKING__ )
   #define __ASM            __asm /*!< asm keyword for TASKING Compiler */
   #define __INLINE         inline /*!< inline keyword for TASKING Compiler */

   #define __STATIC_INLINE  static inline

   #elif defined ( __CSMC__ )
   #define __packed
   #define __ASM            _asm /*!< asm keyword for COSMIC Compiler */
   /*use -pc99 on compile line !< inline keyword for COSMIC Compiler   */
   #define __INLINE         inline
   #define __STATIC_INLINE  static inline

   #endif

较重要的是在core_cm3.c文件中包含了“stdint.h” 这个头文件，这是一个ANSI C 文件，是独立于处理器之外的，就像我们熟知的C语言头文件 “stdio.h” 文件一样。位于RVMDK这个软件的安装目录下，主要作用是提供一些类型定义。如下：

stdint.c文件中的类型定义

   /* exact-width signed integer types */
   typedef   signed          char int8_t;
   typedef   signed short     int int16_t;
   typedef   signed           int int32_t;
   typedef   signed       __int64 int64_t;

   /* exact-width unsigned integer types */
   typedef unsigned          char uint8_t;
   typedef unsigned short     int uint16_t;
   typedef unsigned           int uint32_t;
   typedef unsigned       __int64 uint64_t;

这些新类型定义屏蔽了在不同芯片平台时，出现的诸如int的大小是16位，还是32位的差异。所以在我们以后的程序中，都将使用新类型如uint8_t 、uint16_t等。

在稍旧版的程序中还经常会出现如u8、u16、u32这样的类型，分别表示的无符号的8位、16位、32位整型。初学者碰到这样的旧类型感觉一头雾水，它们定义的位置在Stm32F103xx.h文件中。建议在以后的新程序中尽量使用uint8_t、uint16_t类型的定义。

core_cm3.c跟启动文件一样都是底层文件，都是由ARM公司提供的，遵守CMSIS标准，即所有CM3芯片的库都带有这个文件，这样软件在不同的CM3芯片的移植工作就得以简化。

1.3.2 Device文件夹

在Device文件夹下的是具体芯片直接相关的文件，包含启动文件、芯片外设寄存器定义、系统时钟初始化功能的一些文件，这是由ST公司提供的。

1.3.2.1 system_stm32f1xx.c文件

文件目录：\Drivers\CMSIS\ Device\ST\stm32f1xx\Source\Templates

这个文件包含了STM32芯片上电后初始化系统时钟、扩展外部存储器用的函数，例如我们前两章提到供启动文件调用的“SystemInit”函数，用于上电后初始化时钟，该函数的定义就存储在system_stm32f1xx.c文件。STM32F103系列的芯片，调用库的这个SystemInit函数后，系统时钟被初始化为72MHz，如有需要可以修改这个文件的内容，设置成自己所需的时钟频率。

1.3.2.2 启动文件

文件目录：\Drivers\CMSIS\Device\ST\stm32f1xx\Source\Templates

在这个目录下，还有很多文件夹，如“ARM”、“gcc”、“iar”等，这些文件夹下包含了对应编译平台的汇编启动文件，在实际使用时要根据编译平台来选择。我们使用的MDK启动文件在“ARM”文件夹中。其中的“strartup_STM32F103xx.s”即为STM32F103芯片的启动文件，前面两章工程中使用的启动文件就是从这里复制过去的，strartup_STM32F103xe.s(xe适用于大容量产品)可兼容F103的 ve,ze,rc 芯片。如果使用其它型号的芯片，要在此处文件夹选择其他对应的启动文件。

1.3.2.3 stm32F103xx.h文件

文件目录：\Drivers\CMSIS\Device\ST\stm32f1xx\Include

stm32F103xx.h 这个文件非常重要，是一个STM32芯片底层相关的文件。它是我们前两章自己定义的“stm32F103xx.h”文件的完整版，包含了STM32中所有的外设寄存器地址和结构体类型定义，在使用到STM32 HAL库的地方都要包含这个头文件。

CMSIS文件夹中的主要内容就是这样，接下来我们看看STM32F1xx_HAL_Driver文件夹。

1.3.3 STM32F1xx_ HAL _Driver文件夹

文件目录：DriversSTM32F1xx_HAL_Driver

进入Drivers目录下的STM32F1xx_HAL_Driver文件夹如下：
在这里插入图片描述
STM32F1xx_HAL_Driver文件夹下有inc（include的缩写）跟src（source的简写）这两个文件夹，这里的文件属于CMSIS之外的的、芯片片上外设部分。src里面是每个设备外设的驱动源程序， inc则是相对应的外设头文件。src及inc文件夹是ST的HAL库的主要内容，甚至不少人直接认为ST的HAL库就是指这些文件，可见其重要性。

在src 和inc文件夹里的就是ST公司针对每个STM32外设而编写的库函数文件，每个外设对应一个*.c* 和 .h 后缀的文件。我们把这类外设文件统称为：stm32f1xx_hal_ppp.c 或stm32f1xx_hal_ppp.h文件，PPP表示外设名称。如在上一章中我们自建的stm32f1xx_hal_gpio.c及stm32f1xx_hal_gpio.h文件，就属于这一类。

如针对模数转换(ADC)外设，在src文件夹下有一个stm32f1xx_hal_adc.c源文件，在inc文件夹下有一个stm32f1xx_hal_adc.h头文件，若我们开发的工程中用到了STM32内部的ADC，则至少要把这两个文件包含到工程里，如图。
在这里插入图片描述

1.3.4 stm32f1xx_it.c、 stm32f1xx_hal_conf.h文件

文件目录：STM32Cube_FW_F4_V1.19.0\Projects\STM32F103ZI-Nucleo\Templates

在这个文件目录下，存放了官方的一个库工程模板，我们在用库建立一个完整的工程时，还需要添加这个目录下src文件夹中stm32f1xx_it.c和inc文件夹中和stm32f1xx_it.h、stm32f1xx_hal_conf.h这三个文件。

stm32f1xx_it.c：这个文件是专门用来编写中断服务函数的，在我们修改前，这个文件已经定义了一些系统异常(特殊中断)的接口，其它普通中断服务函数由我们自己添加。但是开发者怎么知道这些中断服务函数的接口如何写？是不是可以自定义呢？答案当然不是的，这些都有可以在汇编启动文件中找到，在学习中断和启动文件的时候会详细介绍。

stm32f1xx_hal_conf.h：这个文件被包含进stm32f103xx.h 文件。STM32HAL库支持所有STM32F1型号的芯片，但有的型号芯片外设功能比较多，所以使用这个配置文件根据芯片型号增减ST库的外设文件, 另外时钟源配置也是在这里进行设置。如下：

stm32f1xx_hal_conf.h文件配置软件库

   /* Includes ---------------------------------*/
   /**
   * @brief Include module's header file
   */

   #ifdef HAL_RCC_MODULE_ENABLED
   #include "stm32f1xx_hal_rcc.h"
   #endif /* HAL_RCC_MODULE_ENABLED */

   #ifdef HAL_GPIO_MODULE_ENABLED
   #include "stm32f1xx_hal_gpio.h"
   #endif /* HAL_GPIO_MODULE_ENABLED */

   #ifdef HAL_DMA_MODULE_ENABLED
   #include "stm32f1xx_hal_dma.h"
   #endif /* HAL_DMA_MODULE_ENABLED */

   #ifdef HAL_CORTEX_MODULE_ENABLED
   #include "stm32f1xx_hal_cortex.h"
   #endif /* HAL_CORTEX_MODULE_ENABLED */

   #ifdef HAL_ADC_MODULE_ENABLED
   #include "stm32f1xx_hal_adc.h"
   #endif /* HAL_ADC_MODULE_ENABLED */

   #ifdef HAL_CAN_MODULE_ENABLED
   #include "stm32f1xx_hal_can.h"
   #endif /* HAL_CAN_MODULE_ENABLED */

stm32f1xx_hal_conf.h 这个文件还可配置是否使用“断言” 编译选项，如下：

断言配置

   #ifdef  USE_FULL_ASSERT

   /**
   * @brief  The assert_param macro is used for  parameters check.
   * @param  expr: If expr is false, it calls assert_failed function
   *   which reports the name of the source file and the source
   *   line number of the call that failed.
   *   If expr is true, it returns no value.
   * @retval None
   */
   #define assert_param(expr) ((expr) ? (void)0 : assert_failed((uint8_t
   *)__FILE__, __LINE__))
   /* Exported functions ---------------------------------- */
   void assert_failed(uint8_t* file, uint32_t line);
   #else
   #define assert_param(expr) ((void)0)
   #endif /* USE_FULL_ASSERT */

在ST的HAL库函数中，一般会包含输入参数检查，即上述代码中的“assert_param”宏，当参数不符合要求时，会调用“assert_failed”函数，这个函数默认是空的。

实际开发中使用断言时，先通过定义USE_FULL_ASSERT 宏来使能断言，然后定义“assert_failed”函数，通常我们会让它调用printf函数输出错误说明。使能断言后，程序运行时会检查函数的输入参数，当软件经过测试，可发布时，会取消USE_FULL_ASSERT宏来去掉断言功能，使程序全速运行。

1.4 库各文件间的关系

从整体上把握一下各个文件在库工程中的层次或关系，这些文件对应到CMSIS标准架构上。如图：
在这里插入图片描述
上图描述了STM32库各文件之间的调用关系，这个图省略了DSP核和实时系统层部分的文件关系。在实际的使用库开发工程的过程中，我们把位于CMSIS层的文件包含进工程，除了特殊系统时钟需要修改system_stm32f1xx.c，其它文件丝毫不用修改，也不建议修改。