现在再看HAL库的时候发现，越来越多的HAL操作放弃直接操控寄存器，而选择操控LL的封装。
这会不会让本来效率不高的HAL在LL基础上更加效率低下。

将来也许会出现根据LL封装更高效的HAL2出现。

一直以来都在用标准库，现在准备转向HALL库。

HAL库确实比较大，一套HAL库占100M的空间，不过HAL库毕竟可以用STM32CubeMX直接导入好，不需要在进行复杂的添加库操作，还是很方便的

    HAL库在初始化配置外设会方便快捷些，尤其是配置系统时钟更会避免出错。但编译速度慢些。尤其是当对main.h进行修改会从头再编译一遍。
    标准库在初始化配置要复杂些，配置系统时钟⑩容易出错，但编译速度快。运行也稳定。只可惜L0、L4、F7、H7都不支持。

    LL库应该是方向，但目前例程较少。

说实话,HAL库比较臃肿, 不太适合实际产品应用, 标准库比较简洁,适合对时间没有严格要求的产品

STM32Cube一统天下，官方的STM32库函数性能对比.pdf里面做过对比测试：

STM32库函数性能对比.pdf (240.74 KB, 下载次数: 38)

2018-2-27 13:12 上传

点击文件名下载附件

无论那种库都是为了减轻开发人员的编程麻烦开发的基于C的函数库，好处是一经编好，适用性大增，稍稍改改或增加些函数就可以应用到其他芯片上。缺点是易读性较差，不想寄存器编程那样可以明白具体操控。感觉HAL库比标准库通用性更强一点。

一直在用标准库，没用过HAL，没法比较！

没出问题的时候是CubeMX+HAL好，出了问题就开始怀念标准库了！个人觉得熟练掌握标准库还是有必要的，毕竟其他友商的库跟标准库思路更像，不是每个公司都会给用ST的。目前用HAL的厂商相对要少。上面说了那么多都是废话，最后说一句就是：老夫写代码就是一把梭.....

我个人还是喜欢直接捅寄存器。

1. 不管是标准库还是 HAL，ST 都没有做到有意义的抽象，代码臃肿占用闪存空间，而且干扰到编译器优化，但没有什么实际意义。在提供库这方面我喜欢 TI 的做法：把库预先编译好放在片内速度等同于 SRAM 的掩膜 ROM 里面，这样的话库不占用闪存空间，还可以反过来加速代码执行。
2. 我个人已经有一套结合了 Arduino 和 POSIX 的嵌入式开发体系了，有不少现成的代码可以用。这些代码大多来自 AVR，都是直接捅寄存器的。（AVR 芯片实在太小了，没有库可用，8 位单片机用库也没有大意义。）

我喜欢标准库+寄存器，相对于HAL库要直接一些，面对MCU我觉得就得简单暴力才能有效率。HAL库为了通用牺牲了很多。

HAL库应该是为了便於F1和其他几个系列之间的程序互相移植，可以有较少的改动
本身ST的MCU，在引脚分布上F1、F4等等之间差异也很小

至於寄存库的库，效率是高的

看个人习惯吧

熟悉标准库，不排斥HAL。毕竟新出的器件都没有标准库了，HAL是趋势。
LL库暂时不打算用，前几天验证一个坛友的问题，真是有BUG呀。