ST的HAL库千万不要用，效率低到惊人！

SCREA · 发表于 2017-8-31 15:15:18

本帖最后由 SCREA 于 2017-8-31 15:18 编辑

。。。。。。。。。。。。。。。
HAL 调式起来比较绕，目的很简单，过程就复杂，毕竟HAL考虑比较多，就做的尽量高大全。

一般常规开发都只用芯片的某些模块的某些功能，属于单一专用了。自然HAL融合进去也就带了很多鸡肋。

ayumi8 · 发表于 2017-8-31 15:22:21

HAL 点个 LED 测试开发板还是可以的拿到ST的没玩过的MCU 可以秒点亮

xuzhiping9889 · 发表于 2017-8-31 15:31:05

本来库就是做实验用的，具体项目要求高的话还是要自己配置寄存器的

li_thomas · 发表于 2017-8-31 15:37:54

效率和可移植可读性之间权衡

EMC菜鸟 · 发表于 2017-9-1 10:02:02

我总感觉ST现在想把硬件抽象出来，很难，有人说这是趋势，我认为不好说，毕竟微处理器不象标准处理器那样标准，很多时候处理器的核、外设都不一样，电脑的配置就那样，电路板可是千差万别，就算用 STM32CubeMX 生成代码，你还得了解各种细节，就比如说 GPIO，输入输出上拉下拉推挽模拟复用高速低速，这些基本的特性你得了解吧？这些东西都是很底层的东西，你能看明白这些东西，看寄存器也就那么回事了吧？HAL库这种模式也许适合那些软件人员，但对硬件人员来说，初始化一个GPIO还东绕西绕的弄上七八个函数？总共也就七八个寄存器，而且跟以前用过的ST的ARM都大同小异，你现在让我重新去学HAL？逗我呢？
另外还要看产品的用途，特别是24小时工作的设备，想必大多硬件工程师都被“硬件没坏、但软件不知道在干什么”的现场BUG折磨过吧？软件想要健壮可靠，设计者就得知道它到底都在干什么、就得对处理器和软件运行有全方位的把控，这也是我不喜欢操作系统的原因，因为我根本不知道它在干什么，出了问题我也不知道怎么去查，这样的产品成千上万的出去，遇到问题恐怕只有辞职以谢罪了！
话又说回头，对于很多硬件工程师来说，也不会天天换处理器吧，更何况就算换处理器，你说 STM32F103 换到 STM32F030，能有多大的变化？基本上一个处理器的框架能用好久的吧，怎么感觉楼上的兄弟们说的好像天天要换新处理器似得？

yayagepei · 发表于 2017-9-1 21:37:49

gamep 发表于 2017-8-9 13:36
cube 这是方便毒药啊

对，cube可以用来参考，但最好还是自己弄一下，不然会跟乱

flash3g · 发表于 2017-9-2 11:46:32

EMC菜鸟发表于 2017-9-1 10:02
我总感觉ST现在想把硬件抽象出来，很难，有人说这是趋势，我认为不好说，毕竟微处理器不象标准处理器那样标 ...

兄弟说的在理，Std库已经足够方便了，可是新的芯片不支持Std库了。STM32CubeMX HAL我只拿来测试硬件，实际产品开发真的不敢用。

gsq19920418 · 发表于 2017-10-24 16:11:30

didadida 发表于 2016-7-20 09:48
刚开发完一个STM32L0系列基于HAL库的项目，感觉确实存在效率问题，解决方法就是自己改下代码，比如直接用操 ...

這個ORE真的是很惡心呀！

清新怡人 · 发表于 2017-11-6 14:31:21

不能说用了HAL就不看硬件，嵌入式始终和硬件打交道，HAL要用，提高了效率，但硬件在心里也要清楚，缺一不可。想用F1的代码不加修改移植到F4，可能吗？

网络孤客 · 发表于 2017-11-15 08:41:01

程序效率从高到低
直接用汇编 --- 寄存器 --- 库函数 --- HAL库
开发效率则相反

没必要抵触某种开发手段，各人喜欢就是。
HAL库一定要配合CUBE，否则光打入HAL_几个字符就多花不少时间。

flamma · 发表于 2017-11-15 08:57:41

HAL库初始化很方便，其实HAL库的封装也还好了，效率低主要还是中断那一块，为了兼容各种使用情况，一个中断里面各种if判断语句。mbed那才是封装的厉害。

kupier · 发表于 2017-12-30 13:06:50

jingwaner 发表于 2016-7-20 09:18
用过NXP，才知道，ST的寄存器分配有多烂

楼上说HAL库行的，应该没有做过：

NXP真心好用

阿峰 · 发表于 2018-5-23 11:03:51

本人小白，之前只做过8位STC，想过度到STM32.后来才知道STM32的库分为两种：标准库和HAL库。想想还是学习HAL库吧，毕竟HAL库ST还在持续维护，标准库好像已经不更新了，新型号已经只支持HAL库。

g921002 · 发表于 2018-5-23 11:30:34

本帖最后由 g921002 于 2018-5-23 11:34 编辑

用Cube初始化很方便，程式其實也不過執行一次，沒有甚麼效率不效率的問題。

周邊物件的instance指針可以直接操作暫存器。一開始從暫存器級別的朋友很容易就跨過去了。
比如PWM使用，初始化完後要變更duty，不要用官方在初始化代碼裡面設定duty的方式(多此一舉)，而是用htim1.Instance->CCR1這樣的方式透過instance直接操作暫存器。
對操作暫存器習慣的朋友根本小菜一碟。

通常容易出問題的是在中斷的callback function，像CAN、UART 這些跟通訊相關的容易出問題。不過那也不是程式bug，就是個誤區要避開。

工具好不好使，還是要看用的人。

XIVN1987 · 发表于 2018-5-23 17:03:32

不光是性能，，不喜欢绕来绕去、很多层调用的代码，，读起来不直观，，还是更喜欢STM32F103那样的标准外设库

JoshuaAstray · 发表于 2018-5-23 17:08:14

可以选用LL库，就是有点不全

hpdell · 发表于 2018-5-23 17:16:22

本帖最后由 hpdell 于 2018-5-23 17:21 编辑

viewtool2014 发表于 2017-8-8 21:56
现在开发都会向着软件开发演进, 硬件就即使是单片机硬件性能也不错了, 做开发讲究的是一个性价比, 在可控的 ...

观点十分赞同，而且现在的单片机的性能远远比以前强大不少，不在乎这点资源浪费，

如果有十分严格的地方，可以改成寄存器操作

而且现在都比较喜欢高低搭配，或者男女搭配干活的，

adslmorisong · 发表于 2018-5-27 00:22:53

还行吧，看怎么用

let8011 · 发表于 2018-5-27 11:19:44

谢谢分享

jianfengxixi · 发表于 2018-5-27 12:12:42

EMC菜鸟发表于 2017-9-1 10:02
我总感觉ST现在想把硬件抽象出来，很难，有人说这是趋势，我认为不好说，毕竟微处理器不象标准处理器那样标 ...

照你这样，让那些搞嵌入式linux的情何以堪，总不能把整个源代码都看一遍吧(^_^;)

CoolBird007 · 发表于 2018-5-27 17:40:35

EMC菜鸟发表于 2017-9-1 10:02
我总感觉ST现在想把硬件抽象出来，很难，有人说这是趋势，我认为不好说，毕竟微处理器不象标准处理器那样标 ...

ST这是在作死的节奏，准备把这块市场让回给atmtl(PIC)的节奏，算是好事吧。。看着吧。等ATMEL出了标准外设库，ST的死期就到了。

barryxiao · 发表于 2018-5-27 19:49:46

g921002 发表于 2018-5-23 11:30
用Cube初始化很方便，程式其實也不過執行一次，沒有甚麼效率不效率的問題。

周邊物件的instance指針可以直 ...

确实是，多数复杂配置的地方都只执行了一次，根本就没效率的问题在里边。

绝大多数外设中断都可以使用DMA代替，EXTI中断的逻辑也没跳很多层，直接使用官方中断反而方便、有效率。
代码的时间优化主要是优化造成效率下降的最主要的那一块，例如循坏polling，把这部分改为寄存器操作或配合操作系统调度，就已经性能很好了。剩下的10%耽误了又怎样，反正CPU都会剩的

ljq77402 · 发表于 2018-5-27 20:06:22

资源不是很缺，效率不要求十分严格的情况下，还是追求程序分层，结构化，，，寄存器配置的时候搞懂了，过一段时间之后通常忘得一干二净，，但是用库就不会，不需要深究原理，对维护交流还是大有好处的。

BMWmao · 发表于 2018-5-27 22:46:53

可以看看 Libopencm3，不过是用GCC的。
travis-ci.org/libopencm3/libopencm3[/url]
github.com/libopencm3[/url]

wuhuijiang · 发表于 2019-12-14 09:58:10

坐等库稳定，但产品又不等人，急急