还没用过LL库。
从使用感觉上，标准库更直观，更易理解。HAL就有点繁琐了，可能也是没适应的原因。
从执行效率上，肯定还是寄存器最快，感觉其次是STD库。
不过ST在推HAL库，以后都得转到HAL或LL库。

喜欢标准库可是ST强制让你转KAL库，有啥办法，没有选择性，考虑优势也没必要了

估计很多人用习惯了标准库，已经有很多代码了，切换过去并不容易，已经是历史遗留问题了

用的寄存器

HAL库在于对外设的封装，程序员只需要关注应用，缩短项目开发时间。至于效率，只是在初始化阶段比较繁琐而已，运行阶段回调函数多嵌套了几层，这是可以通过策略解决的，比如，串口中断接收，每包数据的接收，先要设置接收buffer和期待接收的data_len，这些都是可以通过定制的协议提前知道的，若把data_len设置为1，可以模拟成标准库的处理方式，然而每次中断都会有额外的消耗，于是系统效率下降。
然而HAL库对程序员自身发展不利，会对CubeMax产生依赖，底层原理认识不足，一旦出现BUG往往不知道如何解决，更有甚者，项目需要换别家的IC那更是惨不忍睹。这样出来的程序员只能成为正真的码农。
正确的选择是两者都要会。或者有空的时候分析HAL底层是如何实现那些中间件的，不过CubeMax封装的中间件对C语言基础要求就比较高了，而且和中间件源代码一般都被修改了一些，最重要的是网络上针对HAL如何实现中间件的资料几乎没有，如果有标准库实现的经历，再用HAL库的才能看的明白。

聪神聪 发表于 2018-2-27 08:46
感觉HAL的通用性更强，但是代码比较繁琐，在中断里面会消耗不必要的时间。我还是喜欢用标准库 ...

像UART、TIMER、SDIOMMC我都是直接写中断函数的，不会用官方的的库函数。
除非像DMA、LTDC、USB这种复杂的模块，又没有时间深入去了解的话，就只有直接调用HAL库函数来处理了。

无薪税绵 发表于 2018-2-27 09:48
我个人喜欢标准库。
因为入门时，用习惯了。
在项目上，有很多自己定义的函数都是引用标准库的。

我感觉如果开发的芯片型号不是很多，固定为STM32F7或F4，一次花多点时间用寄存器写好底层驱动是最好的。
如果开发产品涉及型号较多，那用HAL库时，可移植性就非常有用了

嘉木香 发表于 2018-2-27 09:43
新研、试验：HAL库；
开发、定型：STD库 OR 寄存器；

我也有这种想法：新研、试验：HAL库；开发、定型：STD库 OR 寄存器；
就是因为我用了HAL库，遇到了满满的BUG，最终高度成功后也证明HAL代码的问题。HAL库功能几乎都有，但有些功能还没有实现兼容所有的情况。有时真的想放弃HAL库，但有时需要快速实现功能时，也只有HAL库可以缩短开发时间。

toofree 发表于 2018-2-28 00:55
熟悉标准库，不排斥HAL。毕竟新出的器件都没有标准库了，HAL是趋势。
LL库暂时不打算用，前几天验证一个坛 ...

HAL也有较多BUG

ldskendy 发表于 2018-2-28 18:29
我感觉如果开发的芯片型号不是很多，固定为STM32F7或F4，一次花多点时间用寄存器写好底层驱动是最好的。
...

的确如此，现在公司使用的芯片，大多数都是固定的，除非是新样版或者选型中的，
所以，在稳定的前提下，我都尽量使用寄存器操作，
并自定义函数，方便自己在其它项目中调用。