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

相关推荐
无小道9 分钟前
c++--typedef和#define的用法及区别
c语言·开发语言·汇编·c++
林内克思38 分钟前
stm32Cubmax的配置
stm32·单片机·嵌入式硬件
互联科技报1 小时前
重振索尼复古微型电脑——计划以OrangePi CM5 作为主板升级
单片机·嵌入式硬件·电脑
时序数据说1 小时前
时序数据库的存储之道:从数据特性看技术要点
大数据·数据库·物联网·开源·时序数据库·iotdb
敲上瘾1 小时前
传输层协议UDP原理
linux·c语言·网络·网络协议·udp
小林C语言3 小时前
C语言 | 文件读写检测
c语言
c7_ln3 小时前
MYSQL C_API使用全解
c语言·数据库·mysql
天天爱吃肉82184 小时前
从零到一:深度解析汽车标定技术体系与实战策略
python·嵌入式硬件·自动化·汽车
秋说12 小时前
【PTA数据结构 | C语言版】一元多项式求导
c语言·数据结构·算法
行之无边12 小时前
零基础入门物联网-远程门禁开关:硬件介绍
物联网