HAL观望之中，实际使用觉得并不灵活，无法满足需求，需要按照HAL的结构重新构建底层函数，结果还是太麻烦了，而且相当臃肿。

HAL没啥毛病，cubemax把细节都隐藏了，一旦出了问题，就不知道咋搞。推荐有STD库的用STD库。没有的用HAL库，手动移植。弄清楚流程，出了问题才知道怎么解决。总之，鸡蛋不能放在一个篮子里,要用工具，不要被工具用。
一般来说基本外设的初始化配置，手动配置出了问题在与cubemax配置的比较，找问题。
像什么LWIP，GUI，FATFS等中间件，能自己移植就自己移植，USB就算了，USB包含太多子协议，实在复杂，这个建议直接生成，然后再去改描述符啥的,一般直接生成的很难用到实际项目中。

我向来是不惮于接触新事物的，cubemax也做了几个项目了，不过只用到了基本外设，加一个freertos，
一句话串口不好用，大部分条件下，项目不需要那么花哨。比如串口噪声,串口溢出等错误标志位啥的能搞上的都搞上了，没必要啊。这样搞得结果就是用户必须要写一个出错了的回调函数，来错误处理，否则串口死掉，死掉的原因是HAL库串口空闲繁忙保护机制。然而错误处理没有demo，全靠摸索。不做错误处理的只要一直正常也能用，一旦出错就死了，会给人造成不稳定的假象。一个简单的串口尚且如此，不知道其他驱动有没有类似的问题。太过复杂的架构，解决问题的办法不好找，对于初级工程师来说是不可能完成的任务。总的来说HAL库任然需要实际项目的考验，以及应用案例的支持。
完--撒花鼓掌

我刚开始也很抗拒HAL库，但是在新项目中使用了HAL，还是觉得很方便。免掉了所需外设和时钟的初始化配置，只需要把精力集中在功能需求上。而且各种stm32系列的芯片代码都是通用的，很方便就移植过来。  大家都很担心HAL有bug，而且因为层层嵌套不好查找。我觉得不用担心，一方面我没有遇到过。另外一方面，HAL已经出来那么久了，就算有bug也有人反馈了。我觉得就跟使用操作系统一样的，操作系统也有bug，而且操作系统也会损耗一部分cpu性能和内存，但是开发起来方便快捷。

学习了，谢谢。

路过学习一下！

初学HAL中，感觉还是有很多的内容要理清楚，读程序不容易呀~