STM32的HAL库，真烂！！！！

以前，在STM32F10x的时候，ST的库，是不错的。
后来出了个HAL库，真烂。
也不知道ST公司的人是怎么想的？？？
它的硬件库，是一种平台，只要提供功能服务就行了。（以前的库，就是这样）
现在的HAL库，把功能服务和实现策略都做到一起，想拆开很难。
比如USART的实现，提供了一个结构，包含一大堆的东西。而实际上，比如初始化时用到的参数，也放在这个结构里面。
要知道，初始化参数，很大的可能是只用一次，以后再也不用到，平白的占用很多内存空间。
把这个结构定义在外部，占用全局内存，放在函数里面，占用栈空间。
在实际实现中，如果把这种结构放在｛｝中，在｛｝中进行初始化，栈空间占用会很少。
比如：

void x_Init()
{
    {
        A a;
       ............
       ...........
       A_Init(&a);
    }

    {
        B b;
        ...............
        ..............
        B_Init(&b);
     }
}
上述代码，所占栈空间，以结构A、B中，字节数多决定。

STM32的MCU，是单片机，不是PC机，内存能节省的，就要节省。
现在ST公司的HAL库这么一搞，那么个库就基本上是个废库，只能起到参考作用，很多代码得息去改写。这就失去了库的初衷了，意义就不大。

唉！！！！

附议。

做这个的才不会考虑效率，考虑代码优化

不喜欢的可以用LL层啊

cubeMX 还就是用了 HAL, 细看 HAL 内部, 相同的功能或数值, 和外设库使用不同的名称. 却又很相似.
要看内部, 真是头大

你是没看到ST的野心，HAL只是个开始，后期CUBEMX会加上对LL的支持，也可以自己裁剪，那时候就爽了

哈哈，用不惯的时候那确实真他妈烂。。习惯了就好了。

是的。还有LL库。 它侧重考虑了不同系列间的移植。

用惯了标准库 转过来刚开始真有点不习惯。它的管脚和时钟配置部分还是不错地，省了不少精力。

反正等熟悉了都可以自己裁剪的。

LL库感觉与原来的固件库很像

用习惯了，感觉用得很爽，没发现有什么问题，只是效率有点低，不过也无所谓。

弄几个初始化的函数,
用完,转寄存器操作.
如果你要过程中调初始化, 将这部分改成寄存器操作

反正初始化完后,  基本不会再用得着库这东西了,都是自己的封装函数

啥？我还没开始用HAL库就又有新的库了？！！这变来变去还有没有个定性了！

呵呵.看出做硬件的对软件的理解不行了...还停留在256字节ram的单片机水平.

栈的占用是很短时间的,函数用完了栈就释放了.
连这点都考虑的,肯定是自己写的代码不愿意优化去把问题推给别人....

其实现在单片机的rom，ram，频率都有了大幅度提升，为了开发效率和移植、可读性等都可以用更人性化的库开发去妥协，没有对错，只有看任务情况确定用哪种开发。

我粗略的算了下，一个UART_HandleTypeDef结构体约有50个字节大小，你一个工程能用几个串口？平均按3个算是150个字节，算多吗？！
另外，你都不实现逻辑了吗？实现的话为了便于移植和维护，总不能都用全局的变量吧！这个时候以一个结构体作为实参是最合适的，这个优点对于那点RAM占用来说是非常值得的！
最后，自己的代码中尽量写的“优雅”一些所节省的RAM比省去HAL或LL库里的结构体要多！

icecut 发表于 2017-6-7 10:12
呵呵.看出做硬件的对软件的理解不行了...还停留在256字节ram的单片机水平.

栈的占用是很短时间的,函数用完 ...

说的太对了。

还有MIX库

ilovezeno 发表于 2017-6-6 12:22
不喜欢的可以用LL层啊

粗略的看了一下LL库，还不错。

用了一款745，没办法只好用HAL，的确HAL库做的比较拖沓冗余，想做万能的，又没有那个水平，只能忍受了，不舒服的部分只能自己修改

lr_xgm 发表于 2017-6-7 11:11
用了一款745，没办法只好用HAL，的确HAL库做的比较拖沓冗余，想做万能的，又没有那个水平，只能忍受了，不 ...

hal的库不是万能的.以前哪个通用版本的库才是万能的.
不过改hal要小心点,重新更新会覆盖.