萌新的STM32 学习-6

BSP 文件夹，用于存放正点原子提供的板级支持包驱动代码，如：LED、蜂鸣器、按键等。
本章我们暂时用不到该文件夹，不过可以先建好备用。
CMSIS 文件夹，用于存放 CMSIS 底层代码（ARM 和 ST 提供）
SYSTEM 文件夹，用于存放正点原子提供的系统级核心驱动代码
Middlewares 文件夹
该文件夹用于存放正点原子和其他第三方提供的中间层代码（组件/Lib 等），如：USMART、
MALLOC、TEXT、FATFS、USB、LWIP、各种 OS、各种 GUI 等等。本章我们暂时用不到该
文件夹，不过可以先建好备用，后面的实验将会陆续添加各种文件。
Output 文件夹
该文件夹用于存放编译器编译工程输出的中间文件，比如：.hex、.bin、.o 文件等等。这里
不需要操作，后面只需要在 MDK 里面设置该文件夹为编译过程中间文件的存放文件夹就行。
Projects 文件夹
该文件夹用于存放编译器（MDK、IAR 等）工程文件，我们主要用 MDK，为了方便区分，
我们在该文件夹下新建：MDK-ARM 文件夹，用于存放 MDK 的工程文件

ST 公司为了方便用户开发 STM32芯片开发提供了三种库函数，从时间产生顺序是：标准库、HAL 库和 LL 库。
我们在进行操作时可以直接操作寄存器
这样的话执行效率高 但是时间成本也高
标准库是最早的

1. 标准外设库（Standard Peripheral Libraries）标准外设库（Standard Peripherals Library）是对 STM32 芯片的一个完整的封装，包括所有标准器件外设的器件驱动器，是 ST 最早推出的针对 STM 系列主控的库函数。标准库的设计的初衷是减少用户的程序编写时间，进而降低开发成本。几乎全部使用 C 语言实现并严格按照“Strict ANSI-C”、MISRA-C 2004 等多个 C 语言标准编写。但标准外设库仍然接近于寄存器操作，主要就是将一些基本的寄存器操作封装成了 C 函数。开发者仍需要关注所使用的外设是在哪个总线之上，具体寄存器的配置等底层信息。

2. HAL 库HAL 是 Hardware Abstraction Layer 的缩写，即硬件抽象层。是 ST 为可以更好的确保跨STM32 产品的最大可移植性而推出的 MCU 操作库。这种程序设计由于抽离应用程序和硬件底层的操作，更加符合跨平台和多人协作开发的需要。HAL 库是基于一个非限制性的 BSD 许可协议（Berkeley Software Distribution）而发布的开源代码。 ST 制作的中间件堆栈（USB 主机和设备库，STemWin）带有允许轻松重用的许可模式， 只要是在 ST 公司的 MCU 芯片上使用，库中的中间件(USB 主机/设备库,STemWin)协议栈即被允许修改，并可以反复使用。至于基于其它著名的开源解决方案商的中间件（FreeRTOS，FatFs，LwIP 和 PolarSSL）也都具有友好的用户许可条款。HAL 库是从 ST 公司从自身芯片的整个生产生态出发，为了方便维护而作的一次整合，以改变标准外设库带来各系列芯片操作函数结构差异大、分化大、不利于跨系列移植的情况。相比标准外设库，STM32Cube HAL 库表现出更高的抽象整合水平，HAL 库的 API 集中关注各外设的公共函数功能，这样便于定义一套通用的用户友好的 API 函数接口，从而可以轻松实现从一个 STM32 产品移植到另一个不同的 STM32 系列产品。但由于封闭函数为了适应最大的兼容性，HAL 库的一些代码实际上的执行效率要远低于寄存器操作。但即便如此，HAL 库仍是 ST未来主推的库。

3. LL 库：LL 库（Low Layer）目前与 HAL 库捆绑发布，它设计为比 HAL 库更接近于硬件底层的操作，代码更轻量级，代码执行效率更高的库函数组件，可以完全独立于 HAL 库来使用，但 LL库不匹配复杂的外设，如 USB 等。所以 LL 库并不是每个外设都有对应的完整驱动配置程序。

HAL库效率低
LL库不匹配部分复杂的外设




我们要先知道 STM32 芯片的某个外设的性能和工作模式，才能借助 HAL 库来帮助我们编程，甚至修改 HAL 库来适配我们的开发项目。HAL 库的 API 虽多，但是查找和使用有规律可循，只要学会其中一个，其他的外设就是类似的，只是添加自己的特性的 API 而已。需要按照芯片使用手册建议的步骤去配置芯片。HAL 库驱动提供了芯片的驱动接口，但我们需要强调一个概念是使用 HAL 库的开发是对芯片功能的开发，而不是开发这个库，也不是有也这个库能就直接开发。如果我们对芯片的功能不作了解的话，仍然不知道按照怎样的步骤和寻找哪些可用的接口去实现想要实现的功能。ST 提供芯片使用手册《STM32F1xx 参考手册.pdf》告诉我们使用某一外设功能时如何具体地去操作每一个用到的寄存器的细节，后面我们的例程讲解过程也会结合这个手册来分析配置过程。嵌入式的软件开发流程总遵循以下步骤：组织工具链、编写代码、生成可执行文件、烧录到芯片、芯片根据内部指令执行我们编程生成的可执行代码。

HAL_Init()函数
源码在 142 行到 167 行，简化函数如下（下面的代码只针对 F1 的 HAL 固件 1.8.3 版本，
其它版本可能有差异）：

HAL_StatusTypeDef HAL_Init(void)
{/* 配置 Flash 的预取控制器 */
#if (PREFETCH_ENABLE != 0)
#if defined(STM32F101x6) || defined(STM32F101xB) || defined(STM32F101xE) || defined(STM32F101xG) || \ defined(STM32F102x6) || defined(STM32F102xB) || \defined(STM32F103x6) || defined(STM32F103xB) || defined(STM32F103xE) || defined(STM32F103xG) || \ defined(STM32F105xC) || defined(STM32F107xC)/* Prefetch buffer is not available on value line devices */__HAL_FLASH_PREFETCH_BUFFER_ENABLE();
#endif
#endif /* 使能 Flash 的预取控制器 *//* 配置中断优先级顺序 */HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4);/* 使用滴答定时器作为时钟基准，配置 1ms 滴答（重置后默认的时钟源为 HSI） */HAL_InitTick(TICK_INT_PRIORITY);/* 初始化其它底层硬件（如果必要） */HAL_MspInit();/* 返回函数状态 */return HAL_OK;
}

该函数是 HAL 库的初始化函数，原则上在程序中必须优先调用，其主要实现如下功能：
1）使能 Flash 的预取缓冲器（根据闪存编程手册，打开预取指令可以提高对 I-Code 总线
的访问效率，且 AHB 时钟的预分频系数不为 1 时，必须打开预取缓冲器）
2）设置 NVIC 优先级分组为 4。
3）配置滴答定时器每 1ms 产生一个中断。
在这个阶段，系统时钟还没有配置好，因此系统还是默认使用内部高速时钟源 HSI 在跑
程序。对于 F1 来说，HSI 的主频是 8MHZ。所以如果用户不配置系统时钟的话，那么系统将
会使用 HSI 作为系统时钟源。
4）调用 HAL_MspInit 函数初始化底层硬件，HAL_MspInit 函数在 stm32f1xx_hal.c 文件里
面做了弱定义。关于弱定义这个概念，后面会有讲解，现在不理解没关系。正点原子的 HAL
库例程是没有使用到这个函数去初始化底层硬件，而是单独调用需要用到的硬件初始化函数。
用户可以根据自己的需求选择是否重新定义该函数来初始化自己的硬件。
注意事项：为了方便和兼容性，正点原子的 HAL 库例程中的中断优先级分组设置为分组
2，即把源码的 HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_4)改为如下代码：
HAL_NVIC_SetPriorityGrouping(NVIC_PRIORITYGROUP_2);
中断优先级分组为 2，也就是 2 位抢占优先级，2 位响应优先级，抢占优先级和响应优先
级的值的范围均为 0-3。
HAL 库使用注意事项本小节根据经验跟大家讲述一些关于 HAL 库使用的注意事项，供读者参考。1，即使我们已经在使用库函数作为开发工具了，我们可以忽略很多芯片的硬件外设使用上的细节，但当发生问题时，我们仍需要回归到芯片使用手册查看当前操作是否违规或缺漏；2，使用 HAL 库和其它第三方的库开发类似，把我们需要编写的软件和第三方的库分开成相互独立的文件，开发过程中我们尽量不去修改第三方的软件源码，需要修改的部分尽量在自己的代码中实现；这样一旦我们需要更新第三方库时，我们原来编写的功能也能很快地匹配新的库去执行功能；3，即使 HAL 库目前较以前已经相对更完善了，但它仍无法覆盖我们要想实现的所有细节功能，甚至可能存在错误，我们要有怀疑精神，辩证地去使用好这个工具；如我们在 PWM一节编码时发现 HAL 库中有个宏定义 TIM_RESET_CAPTUREPOLARITY 括号不匹配导致编译报错，这时我们不得不修改一下 HAL 库的源码了。4，注意 HAL 库的执行效率。由于 HAL 库的驱动对相同外设大多是可重入的，在执行HAL 驱动的 API 函数的效率没有直接寄存器操作来得高，如果在对时序要求比较严苛的代码，建议使用简洁的寄存器操作代替；5，我们在例程中使用 delay.c 中的延时函数取代 Hal_Delay();取消原来 HAL 库的 Systick 延时设置；但这会有一个问题：原来 HAL 库的超时处理机制不再适用，所以对于设置了超时的函数，可能会导致停留在这个函数的处理中，无法按正常的超时退出；6，我们建议如无致命 BUG 出现，尽量使用开发学习时已经测试稳定的 HAL 库来继续进行开发，不必要频繁更新 HAL 库，因为更新 HAL 库后可能会导致原来能正常运行的代码，在更新 HAL 库之后反面反面无法运行的情况，有些函数操作的结构方式变化了等等，这里只是笔者的建议，大家自己的实际情况权衡。