电气电子大佬辛
标准库函数则是ST以前推出的，包括寄存器版本和库函数版本。寄存器版本使用较麻烦，每个设置都要去查看芯片datasheet，好处是可以让你熟悉芯片的寄存器配置。库函数是基于寄存器版本进行二次封装后
推出的，它的优势就是寄存器版本的劣势，方便了使用，不再需要手动去配置寄存器，使用更方便了。但是它的劣势就是HAL的优势，就是每次修改MCU功能，都需要手动去修改功能，而且自己修改也不能
保证正确性，程序代码在不同MCU之间的移植性不强。
HAL库，HAL是Hardware Abstraction Layer的缩写，中文名称是：硬件抽象层，HAL库工程一般使用Cube软件来生成工程。HAL库是ST公司为STM32的MCU最新推出的抽象层嵌入式软件，
更方便的实现跨STM32产品的最大可移植性。优势就是不需要开发工程师再关注所用MCU型号，只需要专注所以要的功能软件开发工作。而且是未来主推的方向，正在不断的推出更新。
建议平时用的时候将自动更新关闭，否则会出现之前调试好的代码因为更新导致不能正常工作。设置方法点Cube软件的help，然后选择手动更新，详细见配图。
以我和公司工程师研发经历来看，最开始的时候都使用标准库函数，后来发现ST推出HAL库以后，慢慢都转到HAL库的开发。它的优势在于不同芯片间软件代码的移植性非常强，而且用Cube软件生成
的工程规定了自己的代码放置位置，如果不按规定写，重新用Cube生成工程时自己的代码会被覆盖，进一步加强了代码的移植性。
另外，如果需要修改MCU的功能，比如新添加GPIO或者串口，采用标准库函数的时候，需要复制其他串口的初始化代码，然后手动修改。而采用HAL库则不需要，只需要在Cube添加设置，然后生成即可，
Cube自动帮你把初始化代码生成。
综上所述，建议新手直接使用HAL库，这样更容易上手，更快的开发出所需要的软件功能。将繁琐的寄存器配置工作，交给Cube软件即可，这也符合未来开发的主流思想。
招财机器人
1.首先介绍下什么是HAL固件库？
STM32 HAL固件库是Hardware Abstraction Layer的缩写，中文名称是：硬件抽象层。HAL库是ST公司为STM32的MCU最新推出的抽象层嵌入式软件，为更方便的实现跨STM32产品的最大可移植性。HAL库的推出，可以说ST也慢慢的抛弃了原来的标准固件库，这也使得很多老用户不满。但是HAL库推出的同时，也加入了很多第三方的中间件，有RTOS，USB，TCP / IP和图形等等。和标准库对比起来，STM32的HAL库更加的抽象，ST最终的目的是要实现在STM32系列MCU之间无缝移植，甚至在其他MCU也能实现快速移植。
2.HAL固件库介绍
从本质上讲，HAL库和标准库一样都是提供了每个外设的API，我们只需要填写好我们需要配置的参数就可以了。
而且，HAL库在结构上和标准库基本也是类似，接口调用方式等都是一致的，只是改了一些叫法而已，例如之前标准库叫stm32f4xx_xx.c，现在HAL库叫stm32f4xx_hal_xx.c.
3.使用建议：
我们在实际使用过程中，建议使用HAL库，只需要在STM32 Cube Mx软件生成工程代码以后，按照我们之前使用标准库的方式一样来继续写我们的逻辑代码就好。
电子攻城狮
最开始在大学我学习stm32 的时候最早是使用寄存器来开发的。
当我把所有寄存器的例程跑了一遍以后，就又使用标准库再把之前的例程再学习了一遍，之后再也没有用过纯寄存器开发的。
为什么？因为没有机会了，这时候我已经毕业了。在公司开始做项目，项目的紧迫性已经不再是以你学习实践为目的，而是更快更高质量的完成项目开发工作，把产品推向市场。
再后来STM32出的型号越来越多，st为了把所有型号的库使用统一的接口并且方便后续维护退出了STM32HAL库和STM32LL库。这两种库都可以基于STM32CUBEMX图形化配置以后直接生成工程。而标准库ST也不会再维护更新
所以很明显最好就是使用ST最新的HAL库或者LL库。有的人可能会说HAL库效率不高，我还是用标准库吧，没错HAL是没有标准库效率高。但是有LL库作为替补更接近底层。
目前我做的项目都是优先基于HAL库来做，如果有些FLASH比较小的比如8k，我为了优化代码空间大小会使用LL库。
电子创客营
这个问题，我想我比较有发言权。
stm32的标准外设库，是对stm32所有寄存器的封装，包括对所有外设驱动的封装。stm32的标准库几乎全部用c语言实现，虽然在stm32各芯片之间有通用性，但通用性不是很强，比如stm32f1和stm32f7之间的移植，就需要改动比较多了，因为它们之间的文件结构本来就有点不一样，所以移植起来还是要废点功夫的。
hal库是st公司为了更方便地进行stm32之间的移植而开发的库，通用性很强，在不同的两款stm32芯片之间的移植基本上不需要修改。
标准库其实就是对stm32寄存器的封装，看上去比较简单明了。st标准库的封装当时都是把寄存器封装成结构体的形式，通过对结构体赋值从而控制寄存器。一般高数有初始化函数，使能函数，读取状态标志位函数等。hal库比较复杂，比如最简单的串口中断函数单独调用了好几层，所以文件比较大，编译也需要更久的时间。
如果对性能有要求，感觉用标准库甚至是直接操作寄存器比较合适，但是如果要可移植性强，我建议用hal库。
当然，使用hal库还可以用cubemx，直接配置完，一个工程文件就产生了，非常方便。
希望我的回答能帮到你。
Geek潮玩
显然标准库更有执行效率，针对外设来整合的，但是要操作一个片上外设，你需要了解其原理，知道需要配置哪些东西才能用起来。而hal库很大程度上把功能整合了，只需要知道要干什么就行了。举个简单例子，标准库使用外部中断的方法：开gpio时钟，配gpio，配置中断管理，配置中断线映射，写中断服务函数，其中包含查询事件，清楚标志位。而hal库的gpio配置模式可以直接选择中断方式，中断服务函数hal库已经写好了的，你只需要把中断执行程序写在相应callback函数里，不用关心什么标志位。hal本身还提供一个延时函数，由systick得到的精确延时，最关键的是可以搭配stm32cubeMX，图形化操作进行外设配置，一键生成工程，然后就可以专注功能了。个人认为趋势肯定是用hal库，因为很多新的32一开始就不提供标准库支持了，hal库的效率降低将会由更高的处理能力弥补，其快速开发和高度可移植性将会更受欢迎。但是初学者还是应该脚踏实地，从标准库学起，穿插一些寄存器操作的学习，然后才是hal库。如果干什么都是调一个函数解决，那随便叫个写软件的来顶替你不就好了。
just_仰望星空
我正好标准库，Hal库以及LL库都用。
给你介绍下。
HAL库是官方主推的，但是效率不高，而且BUG很多。
但是不影响它开发效率啊，几乎可以做到不用关心底层就可以开心的开发应用。
以上纯属扯淡。。。
这个好用是好用，但是Bug是有的，而且有些地方说明不清晰。
比如我用F4的Sdio搭载Fatfs。这个Hal库生成的驱动是不管用的。你只有调用官方例程移植过来才行。
还有一些奇奇怪怪的BUG。但是我建议还是一直跟上，官方更新速度奇快无比。现阶段为了提升速度，可以选择使用部分LL库。效率大增。
这个库还有个缺点就是会给编译器增加很大的负担。举个例子，我只想从A到B，这个库就基本上给你整成A-C-D-E-------B。然后编译时间超级长。
标准库基本上速度可以跟寄存器媲美(那是不可能的)。但是入手时间长一点，文档非常丰富。但是最新款F7以后不支持了。但是学了标准库玩HAL库是so easy。
我可以负责任的告诉你，你会用寄存器那你用什么库都so easy。你会标准库用HAL库也是小菜一碟。所以，看你自己怎么想的。标准库要求你对手册还要比较深入的了解。但是Hal库几乎可以放下手册了。特别是时钟及外设配置。
后面大家都要转Nxp的Rt1050了，F7也许是绝唱了吧。h7性价比极地。
中国顶级科技评论人
HAL库移植性好于标准库，在满足硬件平台相同的情况呀，程序向上兼容，即F4的程序可以下到F7里，但由于HAL库为了实现这种效果，将底层封装做的太臃肿，以至于效率太低，编译时间特别长，而标准库与之相比较移植性不强，但效率比HAL库高，再对于同一个芯片，标准库实现同样的功能可能会出现不同的程序，但在两台电脑上仅有一两个函数的差别，但却不能添加或删去这个函数，举个例子，一台机子上程序为ABCD,但另一台子上是ACD，实现了同样效果，但如果第一台去了B却可能无法实现这个效果。但总的来说，HAL库容易上手且不会出现标准库的问题，但标准库几乎适合任何条件，HAL要么有Cube MX生成，或者VS生成，或者自己下了库，但标准库，可以在没有cube mx或者vs，且没有下载库的情况下，而使用编译器MDK自带的库
放弃给你自由
我以前一直用标准库，后来发现cube里的usb库更完善和稳定，为了用这个usb库，免去移植的麻烦，迫不得已，用cube，发现这个hel库挺好用，而且官方一直在更新，完善，修改bug。目前已经整个了好多东西，jpg解码，操作系统，usb文件系统等等。其实hal库和标准库是一个套路，原理都是一样的。