为什么STM32的HAL库那么难用，ST还是要硬推HAL库？

我第一次接触STM32单片机，也感觉不太适应，特别是从51单片机过来的，突然感觉知识出现了一个断层。

像51单片机，甚至是以前的ARM7内核的NXP单片机，都是直接配置寄存器去使用外设。

而STM32则是用标准库，HAL库，想点个灯，工程都贼大，费劲巴拉的。

直到后面，慢慢接触到一些稍微大点的项目，好不容易，一步步把功能实现了，突然吊毛经理说要改功能，换芯片。

看着自己写得那堆屎山代码，欲哭无泪，好不容易测试稳定，又要改！！！

一路踩坑过来，就会慢慢明白。

为什么有些资深工程师，明明可以很简单实现功能，代码却绕来绕去，到底是为了什么？

如果做过体量稍微大点的项目，比如上了程序架构，类似RTOS这种，应该就能明白。

除了实现功能本身，还要考虑后期维护，比如说扩展功能，移植到不同的芯片平台。

这就需要站在更高的维度，去设计程序架构，避免重复造轮子，也有助于提高产品的开发效率。

就像让LED闪烁，简单吧？

但是如果换个产品，有10个LED，每个LED需要单独的，不同的闪烁效果，按照单个LED闪烁这种简单的程序架构，就行不通了。

我一般会给LED单独写一个文件，用数组去模拟LED闪烁的波形，这样下次增、减LED的数量或者效果，就不用大改了。

当然，我这样简单说一下，你可能也云里雾里。

我在早期录了一套程序架构的教程，有更系统的讲解，感兴趣的可以找我安排。

整个教程目的，就是教怎么去设计一个简单的程序架构，可作为学习RTOS提前铺垫。

基于以上这些思路，或者需求，大概就能猜到ST为什么推出标准库和HAL库了。

简单来说，就是把程序标准化。

比如STM32最开始推出标准库，就是为了把单片机外设相关的驱动程序(简称硬件层)，变成一系列通用的接口，让我们工程师只需要专注产品业务软件部分，用到哪个硬件，直接调用他们接口函数就行了。

但是标准库有个问题，官方的底层驱动程序，是直接对寄存器进行操作，抽象层次较低。

对于工程师来说，还是要了解一些硬件细节的，使用相对复杂些，不同系列芯片的代码移植也比较困难。

后面hal就逐渐优化了这个问题，增加了一层硬件抽象层，深化了一下面向对象的编程思维，将底层硬件细节进一步封装。

API也更加统一和简洁，不同系列芯片移植起来更容易，配合STM32CubeMX工具使用降低了学习门槛。

虽然Hal看起来越来越方便了，但也有弊端，比如代码体积会大一些，运行效率和实时性也会差一点。

怎么去选择？

如果是新型号，就只能用Hal库了，标准库已经不再更新，也可以理解成ST赶鸭子上架吧。

不过这不意味着标准库没有学习的价值，老工程师用标准库的还是多，而且到企业做产品，也不一定会用到最新系列的芯片。

最近有些老铁找我咨询学单片机，聊完发现99%的人都走了弯路，特意写了一篇单片机学习路径：
单片机不踩坑的学习路线https://blog.csdn.net/2301_78464137/article/details/141396541