再谈HAL库

HAL库是二次封装库，标准库是一次封装库，寄存器应用是汇编的衍生版本。到底谁好，依旧争论不休。

早在去年就写过一篇关于《选择HAL库还是标准库》的文章，感觉还是不能表达自己深恶痛绝的感情。连接如下：

选择HAL库还是标准库_hal库和标准库哪个好-CSDN博客

1、从寄存器应用版本到标准库，再到HAL库

什么是HAL库？从字面意思解释，所有的函数名和宏定义均带有前缀"HAL_"，意思是这些函数是与硬件有相关，这里是对底层硬件操作的一种封装。
举例：

HAL_StatusTypeDef HAL_Init(void)；

#define __HAL_FLASH_PREFETCH_BUFFER_ENABLE()    (FLASH->ACR |= FLASH_ACR_PRFTBE)

既然和硬件有关，难道加个前缀就不用去了解硬件吗？显然不是。有了标准库，为什么要搞个HAL库呢？

1)、寄存器应用版本

寄存器版本相当于汇编，编写程序极不方便，每次配置都要去查找寄存器的各个位是什么意思，且寄存器之间有联系却没有任何提示。

寄存器应用举例：

一个简单的IO操作，搞得如此之复杂，于是，便有了标准库。

2)、标准库

标准库是单片机C语言的必然产物。它通过宏定义和函数封装，实现了部分功能性封装，随机组合，极大地方便了编程，适合大多数单片机软件工程师的喜爱。

标准库举例如下：

3)、HAL库 

标准库发展这么久了，已经很完善了。忽然有人突发其想，我们能否一个库，让大家不用去了解硬件，只看看文档就可以实现编程，这样，可以弱化其能，我们就可以坐收其利。然而想法是好的，毕竟单片机不是我们用的PC电脑，一切都是标准接口。 单片机的设计千变万化，无法做到统一。没有一家的CPU可以做到独领风骚。所谓HAL库的出现，个人认为完全是画蛇添足。HAL库在标准库的基础上，再次封装，将标准中分离的函数再次封装，以为能节省开发时间，然其所写的功能性函数，很多不是我们所需要，且在调试时，发现很多不便，因为很多关联性的功能，还是要去具体分析。很多开发人员，都说被坑了。不仅ROM中的程序庞大，而且还耗RAM中的内存，这个已经是不争的事实。其次，即使介绍的文档，也很难让人灵活使用，因为这程序都和硬件有关，稍有不胜，就会引起错误，而且错了，很难找到。这么多弊病，为什么有有很多人说好呢？

二次封装库，深受老师、学生和入门者的喜爱，因为他们都想走捷径，都以为找到了再也不受硬件的困扰，我们只需要象JAVA那样调用就可以了，从此脱离了硬件，脱离了苦海，再也不受苦受难了。等走上工作岗位，做项目时，才发现这个东西，不仅大，而且问题也大。于是，便会发生灵魂拷问，怎么会这样呢？学习时不是很爽的吗？怎么现在如此不听使唤呢。C语言中也有自己的标准库，这些库属于纯软件，所以使用起来，感觉非常好。然HAL库和硬件有关，用起来必然会被掣肘。人们用理解C语言的标准库去理解HAL，便是大错特错。

这是群里的聊天记录