hal库其实挺好，代表了一种非常科学健全的程序风格。

跨系列 通用性强 所以细节处理 比较晦涩， 刚开始 有点 茫然 其实很好用 ，标准库入门不也是慢慢来的，也绕弯路，HAL是趋势是融合，用起来很舒服，分分钟可就可以配置一个驱动，很方便。

快速开发试验比较方便，用CUBE直接生成框架，省时间，不过效率确实太差可读性也不行，还好有LL库辅助补充。主要是习惯了标准库开发，回头看HAL，LL都有点不是很顺。

一直很BS这个库

HAL初始化硬體又快又方便。效率？有些暫存器級別的控制，HAL產生周邊的instance可以讓你存取暫存器。
中斷的callback不喜還就直接在生成的ISR修改重指向就好。基本上它的代碼比Microchip Harmony容易理解多了。
ST的這個庫我用的還滿開心的。標準庫現在只有維護舊東西會用而已，新東西都轉用HAL了。

HAL库，只适合于代码生成参考，实际产品还是以标准库来实现，否则会死得很难看，HAL的只能用来看，做复杂项目绝对是个大问题！

个人观点，HAL库其实很鸡肋，非常适合新手开发，因为很多新手不了解芯片，由于芯片很多功能都被封装好了，对于新手来说基本上不需要知道如何去配置也不知要了解太多底层，需要什么功能直接调用那个庞大的封装库就好了。故而，很多新人很喜欢用HAL库，觉得很好用。对于老司机来说，很鸡肋。由于库封装的太好，故而显的很不灵活，原本可以两条编码去配置的寄存器就能搞定的问题，HAL库中基本上你必须要调用一个庞大的库函数才能去完成，反复的去全部配置一遍，并且在配置过程中还会很多条件的去判断。执行效率直线下降，代码变的很庞大。所以本人一般都是用HAL库去进行必须的初始化，其他的直接操作寄存器。特别是在中断中，基本上都是对寄存器直接读写，以提升代码效率，减少中断执行时间

HAL库很好用，至少你不用去频繁翻参考手册了，而且HAL库考虑比较周到，按用户设想，基本配置好了不会有什么问题。
优点：解放了程序员的生产力，把貌似高端的底层接口编程变成了简单的HAL库函数调用就可以了。程序员可以把精力放在思考程序的结构上了。维护也方便。可读性更好。
缺点：程序显得有点啰嗦，做了太多的没有用到的功能的判断，效率有点低，这也是受到攻击的主要方面。尤其是中断调用，会耽搁更多的时间。
综合：优点不说了，缺点确是可以克服的。一般初始化程序，无所谓效率，它就是开机执行一次。其他应用函数，如果你觉得它效率低下，也可以直接改写个新的，不用HAL库也不是个难事，改成寄存器操作的，毕竟HAL库追根溯源它也是读写寄存器的，只不过它经过多次封装后，对用户来说隐藏得有点深。
最后结论，推荐HAL库。

zhangxu56726 发表于 2016-9-24 09:37
喜欢的都是之前做应用的，或者不喜欢做驱动的

不喜欢的就是那些不愿意学习新知识，只停留在过去，80年代的老思想，早晚被社会淘汰

king321 发表于 2019-10-16 15:58
不喜欢的就是那些不愿意学习新知识，只停留在过去，80年代的老思想，早晚被社会淘汰 ...

看来你就是做应用的，HAL 效率低 是公认的，我用llow_level 库，这才能显示我的水平，用HAL的过几年你就只能写应用了， 不能驱动 应用两手都行，  到时候就是瘸子

HAL 库 是 ST 推广ST 各系列MCU精心打造的，虽然不可能说是 100% 完美，也不可能很烂，如果我们都是自己写库代码，开发效率就没了，难道会有人谁敢说，我所有的代码处处最高明？关键是会不会用得好。比如，有人在 uart 中断接收回调函数中，解析数据包处理，并写送数据到I2C EPROM，造成串口阻塞。 那I2C 的 HAL 库当然就不好用了。

zhangxu56726 发表于 2019-10-17 08:39
看来你就是做应用的，HAL 效率低 是公认的，我用llow_level 库，这才能显示我的水平，用HAL的过几年你就 ...

不能 两手都行那是你自己，不要用你自己能力去衡量别人