因为STM32标准外设库已经停更了，导致很多开发者都转向了HAL，但一些读者可能比较疑惑，有HAL和LL两种库，到底能不能混合使用呢？

一、标准外设库停更了


很多学习STM32的朋友都比较依赖之前的标准外设库（StdPeriph_Lib），我想告诉大家一个事实，那就是标准外设库已经停更很久了。

支持标准外设库的STM32，只有相对较老的系列：F0、 F1、 F2、 F3、 F4、 L1.

我特地看了下，STM32标准外设库最后一次更新时间是2016年11月的F4系列。

标准外设库地址：


https://www.st.com/en/embedded-software/stm32-standard-peripheral-libraries.html


（公号不支持外链接，请复制链接到浏览器打开）

这后面出来的L0、 L4、 L5、 F7、 H7、 G0、 G4、MP1等都没有标准外设库了。

所以，使用STM32CubeHAL将成为今后的的主流。这里就出来了一个问题：该使用HAL，还是LL开发呢？


二者能共同共同开发吗？

拓展阅读：


关于STM32的四类嵌入式软件库


STM32Cube LL能高效的原因

二、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方式其实是不一样的，混用之后很容易出错。

这里简单举例说这些，深入理解底层的朋友应该知道，还有许多地方也是不建议混用。

当然，不是绝对的（不能混用），我想说：万不得已，慎用。

不是我想混合使用HAL和LL库，遇到过官方HAL库自己调用了LL库。