ST强推HAL库到底是一种什么想法？
今天想找一下STM32L152的StdPeriph_Driver库竟然找不到了，连F1的Std库都找不到，STM32CubeMX生成的都是HAL库。我觉得HAL库一点都不好用，搞一堆花花肠子在里面，找BUG都不好找。单片机就是要稳定，接近底层，真搞不明白搞那么多干嘛？那么厉害干脆上linux算了。还有呢，就是你怎么说，都只是害怕改变，不想学习！！！就像以前得老工程师用汇编，然后到现在依然，你能说他没错？但是大家都知道，除了特定地方需要用到汇编(OS)，这种工程师是要被淘汰得。。。没有一个技能会让你存活很久得，还有很多人依然用protel99，说好用！！！不过是熟练，而不愿意学习新得软件罢了，当然了，你叫他们用AD，借口也是一样得，什么软件太大了啊，什么这不好用，那不好用啊！！！唉。。。人啊，不要为自己得懒惰找接口！！！ 适合自己的，适合工程的，才是需要的 本帖最后由 stm1024 于 2018-9-28 08:11 编辑
我还是习惯使用标准库，或者寄存器，虽然慢，但是心里踏实很多……不过这个是大趋势，跟着学习还是很有必要的。
不知你想过没有，ST搞了很多方向性很强的一些培训，例如GUI、以太网、电机等，所以，从中可见，这个公司在发展方向上，并不是局限于做一个卖芯片的公司，做了很多延伸到应用方面的工作，HAL是其中重要的一环。
这个问题问的人多了,ST解释是HAL库好移植，原来的封装库如果有新的产品加进来后改动太大，不好维护,后面加了LL库，更接近原来的封装库， 我有老产品还是用原来的库，有问题自己都好找，现在库跳转一大堆是有点难懂 现在的人啊，就是不愿意学习，怕改变。。。对对，别人公司脑残，花钱出力然后搞个HAL出来，还把以前得积累丢掉，你因为不想学习，懒得学习，就说别人是垃圾。。。首先HAL不仅仅是底层驱动，他是一套架构，目前行业内认可得一套公开得架构。。。再说了，你要是觉得HAL不底层，不是还有LL库得嘛。。。你要是还觉得垃圾，得了，自己看寄存器资料，搞一个自己喜欢得不就OK啦！！！最后得最后，公司都是趋利得，一个公司不可能花力气去搞一个新东西，如果去搞了，说明这个东西好处是值得把以前得全部丢掉。。。 硬件抽象层是一种解决可移植性问题的思路：
底层关于寄存器的操作尽量封装起来，
其实如果有软件架构师也会是这么处理的，要求开发团队的形成一个统一规范的抽象层，可以让新手专注于应用代码的实现，维护起来成本相对较低。
我换一个角度来说吧，为什么不再推标准库，因为标准库对于整个ST的各个产品线来说维护起来成本比起HAL库与LL库要高，即使是ST公司的开发人员也是会流动的，从维护层面上来说肯定是优选HAL。 本帖最后由 toofree 于 2018-9-27 18:25 编辑
标准库应该是能找到的，ST只要出过标准库，那么会保留最后一个版本的标准库，尽管以后全是HAL和LL了。
http://www.st.com/content/st_co ... /stsw-stm32077.html
在所有标准库器件
http://www.st.com/en/embedded-s ... ia=productId=LN1939
关键还是楼主对ST套路不熟悉
前几天研讨会，跟ST的工程师请教过这个问题。
标准库不更新了，但会保留最后一个版本。
STM32Cube官网只会挂最新版本，历史版本无法获取。
HAL使用起来比较简单，但是会涉及到一些其他的问题。比如我使用的时候，串口必须是不能关闭的，STD库会更适合，HAL每次都需要接收完成，再开中断，这样会导致有数据丢失。还有如果发生了溢出后，串口需要重新初始化，不然接收不到数据。 MrJiu 发表于 2018-9-27 17:25
现在的人啊，就是不愿意学习，怕改变。。。对对，别人公司脑残，花钱出力然后搞个HAL出来，还把以前得积累 ...
C语言用了这么久也没见落后啊，HAL库跟标准库比就跟python和C语言比一样，虽然用起来简单，但是要要庞大的运行环境。HAL也一样，编译出来的代码量比标准库还是大不少，直接用寄存器效率又不高，而标准库用于单片机是最合适的。当初大家不是都是用标准库开发的吗？ 搞生态链 toofree 发表于 2018-9-27 18:18
标准库应该是能找到的，ST只要出过标准库，那么会保留最后一个版本的标准库，尽管以后全是HAL和LL了。
http ...
找到了，谢谢。ST在深圳的研讨会我也去参加了，他们的那套CubeMX生成的代码我很早之前就体验过了，个人感觉生成的代码太臃肿，初始工程都有几十兆那么大，滚回去用标准库了，以后还是会计划用HAL库的，但是要整理一个轻巧的工程模板才行。