CubeMX是不是不支持生成LL库的工程，发现LL库独立的小函数超级多，用起来还挺麻烦的

eric2013 · 发表于 2019-6-11 10:39:55

以串口为例，这么多API，真是颓，全部以内联函数的形式集成在了头文件里面

CubeMX貌似不支持LL库的选择
QQ截图20190611103836.jpg

magicoctoier · 发表于 2019-6-11 10:50:56

在这里选择

eric2013 · 发表于 2019-6-11 10:52:10

magicoctoier 发表于 2019-6-11 10:50
在这里选择

，非常感谢告知。

Edmund1964 · 发表于 2019-6-11 13:01:53

有的外设是没有LL库的，只能用HAL

zerone · 发表于 2019-6-11 20:42:39

还是喜欢用原来的标准库

月明星_P2DFZ · 发表于 2019-6-12 13:48:11

支持一直都在用LL库。LL库可以独立使用，HAL库不就是LL库的再包装吗····

水晶之泪0517 · 发表于 2019-6-28 09:14:31

LL库不完全独立，有一部分和HAL库混合

juzibaba · 发表于 2019-6-28 17:51:49

硬汉大哥，请问实际开发中是用标准库还是HAL+LL库更加方便一些？

在水一方 · 发表于 2019-10-29 08:54:29

juzibaba 发表于 2019-6-28 17:51
硬汉大哥，请问实际开发中是用标准库还是HAL+LL库更加方便一些？

建议使用HAL 吧，LL库过于分散独立，还需要自己去封装，如果功能很多，就需要很多时间去封装，换个芯片也不好去移植。

cdr430 · 发表于 2019-11-5 17:58:00

L4，从F0的SPL标准外设库移植过来，用了2017年以后不再更新的SPL2LL_Converter工具，还需要手动修改很多地方。
SPL转HAL没有直接转换工具，刚接触LL，觉得跟SPL相似度较高。

calvinxxw · 发表于 2019-11-6 11:13:10

本帖最后由 calvinxxw 于 2019-11-6 11:21 编辑

兼容性和效率不可得兼。产品线太宽，要在一套框架内全部兼容，想想都知道HAL的效率多差。部分功能只能用HAL库，例程就能看出来。像STM32G4这种计算密集型，用于代替DSP的场合，HAL库显然是绊脚石。反观TI的DMC库，极致追求效率，代码兼容性和可读性稍差，但是在DSP场合效率决定成败，ST应该好好整理LL库，让它完全独立于HAL，而且功能完整。

caicaptain2 · 发表于 2019-11-7 09:36:43

calvinxxw 发表于 2019-11-6 11:13
兼容性和效率不可得兼。产品线太宽，要在一套框架内全部兼容，想想都知道HAL的效率多差。部分功能只能用HAL ...

可能mcu更讲究开发的效率和成本。所以计算强度的方便不是最优先的。
似乎计算效率的话，用FPGA更好，可以并行计算。 DSP都是个折中的选择。

fyyxxm · 发表于 2019-11-7 12:07:06

calvinxxw 发表于 2019-11-6 11:13
兼容性和效率不可得兼。产品线太宽，要在一套框架内全部兼容，想想都知道HAL的效率多差。部分功能只能用HAL ...

LL库已经很独立了，HAL库就是利用LL库实现功能。LL库独立开发项目，目前没有任何问题的

calvinxxw · 发表于 2019-11-7 14:59:06

caicaptain2 发表于 2019-11-7 09:36
可能mcu更讲究开发的效率和成本。所以计算强度的方便不是最优先的。
似乎计算效率的话，用FPGA更好，可 ...

如果只是用于事务性逻辑处理，当然开发速度更重要。但如果认为FPGA能代替DSP，就错了。应该说各有存在价值。

weixiang · 发表于 2020-5-20 09:09:36

请问楼主的内联函数列表是怎么打开的

eric2013 · 发表于 2020-5-20 09:14:37

weixiang 发表于 2020-5-20 09:09
请问楼主的内联函数列表是怎么打开的

在.h文件里面呢。

		自动登录	找回密码
密码			立即注册

[客户分享] CubeMX是不是不支持生成LL库的工程，发现LL库独立的小函数超级多，用起来还挺麻烦的