你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

为什么不常见不用固件库或 HAL 的 STM32 新手教程?

[复制链接]
maxtch 提问时间:2017-12-9 22:38 /
阅读主题, 点击返回1楼
收藏 1 评论52 发布时间:2017-12-9 22:38
52个回答
maxtch 回答时间:2017-12-13 10:17:32
任风吹吹 发表于 2017-12-13 09:49
哥们,你居然说HAL抽象度不够? 通过HAL可以实现所有STM32跨平台开发,并且HAL与中间件层完全分离,只要 ...

您试试看从 STM32 跨到别的厂家的单片机,您就知道 HAL 的抽象度为什么不够了。横向比较一下 ST HAL、TI StellarisWare、ASF、MPLAB Harmony、LPC Xpresso 你会发现这些东西全都是渣渣,反而是 Keil RTE 还像点样子。
maxtch 回答时间:2017-12-13 10:20:58
zhao.zhao 发表于 2017-12-13 10:15
楼主是高手,喜欢高效的代码,也无可厚非,个人习惯和使用系统的不同,大家都有选择的自由;但你从别人的角 ...

STD 和 HAL 不是 ARM 的,这两个是 ST 的。ST 的商业先传团队值得好好奖励一下,因为他们成功的把很多人都套到 Keil+HAL 的圈子里面不能自拔了,想办法套个商业模式你就成功了。

ARM 的是 CMSIS-RTE,好像反而没多少人用哦?
maxtch 回答时间:2017-12-13 10:23:45
iclearsunshine 发表于 2017-12-13 10:01
费时费力自讨苦吃。这个问题已经没有争辩的意义了。MCU只会越来越复杂,记寄存器只能是死路一条。 ...

如果你把 MCU 分割成功能模块,每一个模块还是那点复杂度,上世纪 70 年代如此,现在还是如此。如果每一个功能模块都对应一个独立的驱动程序,复杂 MCU 不过是多几个驱动程序,每个驱动程序有三四个实例罢了。这东西要各个击破啊。
任风吹吹 回答时间:2017-12-13 10:28:55
maxtch 发表于 2017-12-13 10:17
您试试看从 STM32 跨到别的厂家的单片机,您就知道 HAL 的抽象度为什么不够了。横向比较一下 ST HAL、TI  ...

楼主,如果说到横向比较,那么你是否知道基于HAL库上有个叫mbedTLS的东东?你想写个代码所有MCU都支持,干嘛还使用寄存器啊?直接使用mbed啊。恕我多嘴,恰好HAL+mbedTLS就可以实现。
maxtch 回答时间:2017-12-13 10:33:13
任风吹吹 发表于 2017-12-13 10:28
楼主,如果说到横向比较,那么你是否知道基于HAL库上有个叫mbedTLS的东东?你想写个代码所有MCU都支持, ...

mbedTLS 不是拿来干这个的,RTFM!你说的是 RTE,但就算是 RTE 是我也不用:太庞大了。你试试看 STM32F042F4P6 上 RTE,能塞得进去算你牛。
maxtch 回答时间:2017-12-13 10:41:39
别的厂家也有类似于 HAL 的东西,但是在我看来这些库都没有 HAL/SPL 那么过分:至少这些库是固化在片上 ROM 里面,不占用代码空间的。
任风吹吹 回答时间:2017-12-13 10:48:22
maxtch 发表于 2017-12-13 10:33
mbedTLS 不是拿来干这个的,RTFM!你说的是 RTE,但就算是 RTE 是我也不用:太庞大了。你试试看 STM32F04 ...

楼主你这么说就有点极端了,MCU的性能与库的抽象度是两个相对的因子,那那个M0的MCU来弄个RTM算什么事,这个除ST外的其他MCU也不能把,对于M0核的MCU,HAL有点勉强,SPL相对OK,最适合的当属LL库。M0使用HAL不是不行,而是合不合适的问题。RTM也类似,所以楼主的这个假设算是极端了。之所以和楼主讨论这么多,原本就是看到楼主各种说HAL的不便效率方面低下而推荐寄存器操作方式方式,殊不知LL库的推出正式解决这种问题,后来楼主又说HAL抽象度不够,殊不知基于HAL之上的各种中间件实现APP与底层的完全分离,甚至跨平台,到最后又回到CPU本身处理性能与之匹配的库所产生的效率问题上。这种拿低性能处理器搭配重量级的软件的假设本身就没有可取之处。话题已经偏移最初的含义了,没有继续讨论的意义了。
maxtch 回答时间:2017-12-13 10:55:33
Inc_brza 发表于 2017-12-13 09:52
为了不误会楼主,我去楼主的github看了一下代码~
http://github.com/SushiBits/Lig ... ob/master/src/led ...

我的库至少把硬件抽象到了某种标准接口上。我选用的接口定义是 POSIX 优先,Arduino 其次。你可以看看这几个文件,目标芯片是 STM32F103CBT6,芯片容量比较大,我就没有用简化驱动:

POSIX 设备驱动:http://github.com/SushiBits/LCDC ... system/src/device.c
串口驱动,继承 POSIX 设备:http://github.com/SushiBits/LCDC ... /system/src/usart.c
HD44780 驱动,继承 POSIX 设备:http://github.com/SushiBits/LCDC ... ob/master/src/lcd.c
POSIX 时钟驱动:http://github.com/SushiBits/LCDC ... r/system/src/time.c
应用程序:http://github.com/SushiBits/LCDC ... b/master/src/main.c
任风吹吹 回答时间:2017-12-13 11:00:31
maxtch 发表于 2017-12-13 10:41
别的厂家也有类似于 HAL 的东西,但是在我看来这些库都没有 HAL/SPL 那么过分:至少这些库是固化在片上 RO ...

你真的认为库固定放在ROM内好?你认为所有人都认可吗?你有没有考虑过一旦出现问题的可追索性?库方式至少还是开源的。至于空间,放ROM真的就好吗?ST真的就只是仅仅不远多提供一个可以存放库的ROM吗?这种方式与提供库的方式有什么本质区别吗?仅仅只是不占空间?
maxtch 回答时间:2017-12-13 11:06:43
任风吹吹 发表于 2017-12-13 10:48
楼主你这么说就有点极端了,MCU的性能与库的抽象度是两个相对的因子,那那个M0的MCU来弄个RTM算什么事,这 ...

首先,我特别单独把 F042F4 拎出来的目的是这颗芯片放不下 HAL,而如果你想用 ST 的 USB 库又非得用 HAL 不可(Cube 没有 LL USB 库)这个困局不应该存在的。

然后您觉得 HAL 已经可以跨平台了。我想说的是请您放眼一下别的厂家,您就知道 ST 的 HAL 有多么平台局限了。RTE 可以跨厂家,但是如果我想在 ST 的芯片上用 RTE 就得用 HAL(又是一个不能用 LL 的)然后代码臃肿的问题就又回来了。这也是为什么我会提到别家的芯片内置的 ROM:别家芯片的 RTE 只依赖这个 ROM。换句话说,如果我用 NXP LPC 或 TI LM3S/MSP432 的芯片我至少不用为了硬件库预留代码空间;但是 ST 的芯片上我需要为底层硬件库预留空间,这里就是为什么我需要考虑这个库的文件体积,进而抱怨 HAL 臃肿了
关于
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
意法半导体官网
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
官方最新发布
STM32N6 AI生态系统
STM32MCU,MPU高性能GUI
ST ACEPACK电源模块
意法半导体生物传感器
STM32Cube扩展软件包
关注我们
微信公众号二维码 微信公众号
手机版二维码 手机版