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

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

一般都是先生成HAL代码，然后再修修改改，这样可能更方便一点。
不过总体上来说，HAL确实提升了开发的效率，省的不停滴查手册

我的方法类似你用的，也是用文件夹区分BSP,API,APP等，然后每一层用一个.h文件include。
接入HAL的，只是修改main.c和stm32f1xx_it.c 这两个文件。所以重新生成工程（或者换芯片），也不用修改自己的代码。
而且这样的分布，如果只是修改BSP里面的.c文件，只会重新编译BSP文件夹里面的不好影响到其他层。
这样的好处，就是提升编译速度。

一如既往的喜欢标准库，也使用过HAL库但是编译起来太烧配置，因为使用得比较少也不好做过多的评论。听说HAL驱动集成得很好

不怎么好用，而且能保证生成的驱动就一点问题没有吗？

标准库和 HAL 我都不用。开发起来代码复杂度和直接操作寄存器差不了多少，烧空间。所谓的跨平台，这种 HAL 因为没有别的厂家支持，也只不过是一种供应商锁定的方法罢了。

一直在这个论坛里推stm32cubemx与HAL库，
其实我也想顺便推荐一下LL库，但是LL库目前没有在项目中使用，不敢误人子弟。

之前想用STM32F107VCT6的时候用TCP联网，看了教程也不会用，自己觉得可能用MCU做这些应用并不是太合适。
单纯的控制，GPIO,中断,CAN,I2C,定时器，PWM,串口,这些基本功能还是挺方便的

至于 USB、网络这类复杂外设，网上可以找到不依赖 HAL 或标准库的独立支持库。而且这类库普遍体积都非常小。

该说不说HAL十分方便移植，但是缺点就是不好优化啊，生成的下载文件 都好大

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

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

学习了，谢谢。