为什么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

相关推荐
Wangshanjie_9819 分钟前
【STM32】-SPI通讯
stm32
qq_411262421 小时前
整体无需占用任何硬件 UART,即可新增一条全双工软串口
单片机·嵌入式硬件
阿捏利2 小时前
C Primer Plus 第6版 编程练习——第7章(上)
c语言·编程题·c primer plus
jz_ddk2 小时前
[实战]调频(FM)和调幅(AM)信号生成(完整C语言实现)
c语言·算法·信号处理
码农Cloudy.3 小时前
C语言<数据结构-链表>
c语言·数据结构·链表
XINVRY-FPGA3 小时前
XCZU47DR-2FFVG1517I Xilinx FPGA AMD ZynqUltraScale+ RFSoC
人工智能·嵌入式硬件·fpga开发·信息与通信·信号处理·射频工程·fpga
星竹晨L3 小时前
C语言——预处理详解
c语言·开发语言
Cyrus_柯4 小时前
单片机基础(STM32-DAY2(GPIO))
单片机·嵌入式硬件
吃货界的硬件攻城狮4 小时前
【STM32 学习笔记】SPI通信协议
笔记·stm32·学习
lightqjx4 小时前
【数据结构】顺序表(sequential list)
c语言·开发语言·数据结构·算法