还是HAL库好用，至少用标准库的时候硬件I2C都很难配出来。
HAL库的话就是小菜一碟。
而且DMA的控制方式也容易多了。

听大师分析

ldskendy 发表于 2018-2-28 18:26
像UART、TIMER、SDIOMMC我都是直接写中断函数的，不会用官方的的库函数。
除非像DMA、LTDC、USB这种复杂 ...

有道理，我也这么做的

习惯了标准库后用HAL有点麻烦，标准库操作寄存器的步骤感觉比HAL库少一两步，标准库学习起来更加简单明了，可能这是因为我习惯问题，目前遇到过编译标准库比编译HAL库要快很多，可能编译器问题吧，不过HAL库是更加全面的，而且现在ST是主推HAL库了，新手学习直奔HAL库吧，为以后打算，但是如果是紧急项目还是用标注库稳妥点，安全起见

       原来主要用的是标准库，也接触了一下HAL库，怎么说呢，本人水平比较差，总是在两种库中徘徊。为什么这么说，首先，原来用惯了标准库，同时标准库退出了那么长时间，网上各种外设的例程基本都全了，查找起来也比较方便。
       HAL库也尝试用了下，对于相对复杂的工作，比如以太网、USB、SD卡、文件系统等，用stm32cube简单配置一下就可以实现功能，确实很快，不需要移植和太多的修改，对于简单的功能，比如I2C，SPI、usart等，就是鼠标点点功能就好，代码自动生成，感觉还是比较爽。
      但是当出现问题需要调试时，HAL库就比较麻烦，封装太深，不像标准库那样容易找到问题点。
      结论就是：不追求新芯片的情况下，还是考虑用标准库。

最多就用HAL库生成个底层驱动配置，中断什么的还是用寄存器来搞

我是前些年用标准库写过程序，现在又要写32的程序，接触了一下HAL，调试了一段时间，感觉HAL入手快，简单应用快速完成。
但是，写32的一般都有特定的需求，不都是简单应用，尤其对实时性、效率等有要求的应用，感觉HAL很垃圾，我调试一个通信程序，仅一个数据包的接收过程用Receive_IT加回调，不说数据写缓冲区过程与标准库方法没区别，仅仅附加的多次开关中断、各种条件判断等等。。本来不存在的好多东西都加进来了，不仅效率低，而且调试过程中莫名其妙的问题频频出现。
本来单片处理器就是强调效率的，它又不是商用处理器，用来运行庞大操作系统的，搞那么臃肿干嘛。
感觉ST不更新标准库，强推HAL，是一种商业运作模式，对开发者来讲，没什么益处。
个人观点，仅供参考。

我是从标准转hal库的，发现hal挺好用的

用HAL库，不过会把串口、spi等简单东西HAL底层修改了用,对于USB,网口啥的直接生成