本篇文章应运而生，源于一位读者提出的问题，它反映了众多用户共同的困惑，因此我特意撰写此文，以便和大家共同探讨这一话题。

一、标准外设库的停止更新

面向学习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等都没有标准外设库了。

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

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

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

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！