一、标准外设库停更了 很多学习STM32的朋友都比较依赖之前的标准外设库(StdPeriph_Lib),我想告诉大家一个事实,那就是标准外设库已经停更很久了。 支持标准外设库的STM32,只有相对较老的系列:F0、 F1、 F2、 F3、 F4、 L1. 我特地看了下,STM32标准外设库最后一次更新时间是2016年11月的F4系列。 标准外设库地址: https://www./en/embedded-software/stm32-standard-peripheral-libraries.html 这后面出来的L0、 L4、 L5、 F7、 H7、 G0、 G4等都没有标准外设库了。 所以,使用STM32CubeHAL将成为今后的的主流。这里就出来了一个问题:该使用HAL,还是LL开发呢? 二者能共同共同开发吗? 拓展文章:
这个问题的答案是:不建议共同使用。 当然,这个问题还要分情况:相同外设和不同外设之间共同使用HAL和LL库。 1.不同外设混用HAL和LL库 这里说的不同外设混用HAL和LL库针对的不同外设。比如:UART使用HAL库,SPI使用LL库。 这种情况下,一般来说:没问题。 因为官方不管是从资料,还是从STM32CubeMX工具配置都没有反对这种做法。 这虽然没有明确说不允许这样操作,但实际项目不建议这种方式。 至于原因,相信不用我说,有项目经验的朋友都明白。这样做不利于代码移植,管理等工作。 2.相同外设混用HAL和LL库 这里才是本文重点,这种情况,官方其实也是建议:不允许。 这样混用,会存在一系列问题:底层冲突、结构混乱、管理不方便等。 LL库驱动独立,HAL包含驱动包 拿STM32F4的UART传输函数来说,LL库的位于stm32f4xx_ll_usart.h: 而HAL定义于stm32f4xx_hal_uart.c: 从这里可以看得出来,LL只需包含头文件即可,HAL要包含bsp包。 假如使用LL库的工程,想使用HAL库,需添加bsp包到工程。 HAL句柄 对于LL而言,使用HAL库,会多一个句柄,比如UART1: UART_HandleTypeDef huart1; 如果LL库的工程,直接调用HAL接口是不行的,缺少句柄。 中断请求处理 HAL和LL的中断请求IRQ方式其实是不一样的,混用之后很容易出错。 这里简单举例说这些,深入理解底层的朋友应该知道,还有许多地方也是不建议混用。 当然,不是绝对的(不能混用),我想说:万不得已,慎用。 |
|
来自: 西北望msm66g9f > 《编程》