用ST的HAL库后，被绕晕了，这样编程真的好吗？

EMC菜鸟 · 发表于 2017-9-4 16:38:20

用的 STM32L053R8，其中设置CPU的内核电压这一个语句：
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
看到这个语句，先找 PWR_REGULATOR_VOLTAGE_SCALE1，如下：
#define PWR_REGULATOR_VOLTAGE_SCALE1 PWR_CR_VOS_0
然后：
#define PWR_CR_VOS_0             (0x1U << PWR_CR_VOS_Pos)                   /*!< 0x00000800 */
再然后：
#define PWR_CR_VOS_Pos          (11U)
，，，，，，
再找 __HAL_PWR_VOLTAGESCALING_CONFIG 的定义：
#define __HAL_PWR_VOLTAGESCALING_CONFIG(__REGULATOR__) (MODIFY_REG(PWR->CR, PWR_CR_VOS, (__REGULATOR__)))
然后：
#define MODIFY_REG(REG, CLEARMASK, SETMASK)  WRITE_REG((REG), (((READ_REG(REG)) & (~(CLEARMASK))) | (SETMASK)))
再然后：
#define WRITE_REG(REG, VAL) ((REG) = (VAL))
，，，，，，
等等，还没完，PWR_CR_VOS 是什么？再找：
#define PWR_CR_VOS_Msk          (0x3U << PWR_CR_VOS_Pos)
#define PWR_CR_VOS                PWR_CR_VOS_Msk

以上所有的语句、定义，看了半天，其实加起来就为了实现将 PWR_CR 寄存器的11、12位写为 01 ，用语句表示如下：
PWR->CR = (PWR->CR & (~0x00001800u)) | 0x00000800u;

呃，我不确定，这样真的“更简单”？

STT · 发表于 2017-9-4 16:45:11

一个是给大部分人看的一个是你自己看的

su33691 · 发表于 2017-9-4 16:47:52

估计是为了方便用STM32CubeMx进行配置？

security · 发表于 2017-9-4 16:48:37

你可以认为：
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
是写给人看的。

而 PWR->CR = (PWR->CR & (~0x00001800u)) | 0x00000800u;
是写给机器看的。

security · 发表于 2017-9-4 16:59:55

当你明白 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1) 背后的规则后，
过几个月后，
你再来看 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1); 和 PWR->CR = (PWR->CR & (~0x00001800u)) | 0x00000800u;
从哪个写法，你能更快速的知道代码背后的意图呢？

jjkk1314T · 发表于 2017-9-4 17:33:11

太绕了不太适应

EMC菜鸟 · 发表于 2017-9-4 17:44:03

security 发表于 2017-9-4 16:59
当你明白 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1) 背后的规则后，
过几个月后，
...

这个如何：
PWR->CR = (PWR->CR & (~0x00001800u)) | 0x00000800u; //设置内核电压为1.8V

modbus · 发表于 2017-9-4 17:47:35

能不能少敲些字母

security · 发表于 2017-9-4 18:02:07

EMC菜鸟发表于 2017-9-4 17:44
这个如何：
PWR->CR = (PWR->CR & (~0x00001800u)) | 0x00000800u; //设置内核电压为1.8V

增加注释，这个可以。
实际上，写成这样会更直观点：
PWR->CR = (PWR->CR & ~(BIT_11 | BIT_12)) | BIT_11; // 设置内核电压为1.8V

另外，越高级的编程，基本是越看不到对寄存器的直接操作的，这方向，ST 是没走错的。

security · 发表于 2017-9-4 18:03:04

modbus 发表于 2017-9-4 17:47
能不能少敲些字母

有自动补全的，
实际编程，不需要敲那么多字母的。

justdomyself · 发表于 2017-9-4 18:03:29

确实挺晕

wye11083 · 发表于 2017-9-4 18:21:07

security 发表于 2017-9-4 18:02
增加注释，这个可以。
实际上，写成这样会更直观点：
PWR->CR = (PWR->CR & ~(BIT_11 | BIT_12)) | BIT_1 ...

其实是为了兼容性。毕竟不可能搞出来几百套STM32Cube。

gwnpeter · 发表于 2017-9-4 18:42:51

我都是只用STM32Cube来初始化，正常使用的时候，都是寄存器

mint · 发表于 2017-9-4 20:25:51

毕竟官方的，现在新项目（内部工具用）就上了 HAL ，坑不少，（如 M7 的 USB CDC 因为堆栈的分配太小导致 USB 无法枚举成功，这个让我找了好几天，，，）一般碰到问题就去官方社区交流，

一部分可以找到答案，

一部分自问自答，

意识到生态的重要了，大家都再帮 ST 找 bug 额，，，，

不过，写底层驱动真的很爽（还有移植 CMSIS OS，文件系统之类的），只要你知道你需要如何配置的，维护一个 MX 配置就可以了，，，

让不知其所以然的也可以先跑起来，然后有需要再深入理解自己那部分，这个应该是 MX 带来的最大的可能性。

可以花一两个月折腾感受下，然后再看看，，，

security · 发表于 2017-9-4 20:56:07

wye11083 发表于 2017-9-4 18:21
其实是为了兼容性。毕竟不可能搞出来几百套STM32Cube。

兼容性只是其中一点，其实就算只有一个硬件，对于一个合格的 sdk，也需要这么做。需要屏蔽掉硬件的实现细节或差异，让开发者不过多关注硬件细节，尽可能的快速开发。

lixin91985 · 发表于 2017-9-4 21:21:04

用过CYPRESS 才知道ST落后很多了。。 IDE 全整合，图形配置，代码编辑，编译。

即使这样，我还是经常需要操作寄存器。

fuquan_dai · 发表于 2017-9-4 21:28:56

因为stm的标准库喜欢上stm32，因为HAL库觉得有必要放弃stm32了。。。

jingwaner · 发表于 2017-9-4 22:16:35

单片机就是该用寄存器，没必要装高级

PEcontrol · 发表于 2017-9-4 23:09:38

同意楼上，感觉有一些单片机应用不需要这么复杂，
特别是一些底层的实时应用，更习惯于直接操作寄存器，清清爽爽。
照这个模式发展下去，以后都是微型计算机编程了。

Flyback · 发表于 2017-9-4 23:33:10

代码自注释，这样可以减少阅读障碍

security · 发表于 2017-9-4 23:45:16

jingwaner 发表于 2017-9-4 22:16
单片机就是该用寄存器，没必要装高级

看应用场景了。
这就跟单片机裸奔，还是上 RTOS 的选择是一样的。
项目体积越大，这类需求就会越大。

security · 发表于 2017-9-4 23:47:06

Flyback 发表于 2017-9-4 23:33
代码自注释，这样可以减少阅读障碍

你 get 到关键点了。

cycisok · 发表于 2017-9-4 23:47:22

我接触的单片机不多，接触过的厂家里比较喜欢芯唐的库写法。类似9楼的写法

cycisok · 发表于 2017-9-4 23:48:04

绕太多确实不爽，看文档比照的时候找好长时间

security · 发表于 2017-9-4 23:50:31

PEcontrol 发表于 2017-9-4 23:09
同意楼上，感觉有一些单片机应用不需要这么复杂，
特别是一些底层的实时应用，更习惯于直接操作寄存器， ...

我想这是趋势。
硬件资源是一直在持续提高的。越高级的硬件，就需要越抽象的封装。

cycisok · 发表于 2017-9-4 23:54:47

函数封装的时候可以用自然些的，但底层操作绕多就没必要了。我觉得是思维习惯的不同，有些库真的很难用

AlertTao · 发表于 2017-9-5 06:36:34

只能说：世界变化太快，已经没有太多时间看数字了，HAL能看懂意思就好了。

yelong98 · 发表于 2017-9-5 08:01:12

hal的库变化也快得很

redroof · 发表于 2017-9-5 08:15:44

可读性最重要，绝大部分地方可读性甚至大于执行效率。更何况那一堆define到最后其实变成了跟直接写寄存器一样，啥也没损失

eaglelpx · 发表于 2017-9-5 08:16:58

玛德。我也用的很崩溃，I2C输出波形老是不对，方波夹杂着三角波。各种设置都没用

EMC菜鸟 · 发表于 2017-9-5 08:25:08

security 发表于 2017-9-4 18:02
增加注释，这个可以。
实际上，写成这样会更直观点：
PWR->CR = (PWR->CR & ~(BIT_11 | BIT_12)) | BIT_1 ...

这个好，以前一直没想到这种用法，简单粗暴直接！

security · 发表于 2017-9-5 08:26:50

redroof 发表于 2017-9-5 08:15
可读性最重要，绝大部分地方可读性甚至大于执行效率。更何况那一堆define到最后其实变成了跟直接写寄存器一 ...

是的，所以我在 4 楼，就说那代码是写给人的。
代码的客户，是人，
代码写得再复杂，机器照样 666 的看得懂，而我们却不行。

security · 发表于 2017-9-5 08:29:56

EMC菜鸟发表于 2017-9-5 08:25
这个好，以前一直没想到这种用法，简单粗暴直接！

写代码，要记得代码首先是写给我们看的就行。
不要让我们过多的思考。
我在我的团队中，就推行这种 BIT 定义，而不是直接出现数字（magic number）。

EMC菜鸟 · 发表于 2017-9-5 08:31:22

本帖最后由 EMC菜鸟于 2017-9-5 08:32 编辑

security 发表于 2017-9-4 20:56
兼容性只是其中一点，其实就算只有一个硬件，对于一个合格的 sdk，也需要这么做。需要屏蔽掉硬件的实现细 ...

我觉得对电路板而言，这个方向并不一定正确，，，，，，我始终认为，电路板不是计算机，配置千差万别的，想屏蔽掉硬件是不可能的事情，简单一点来说，就设置一个内核的电压、在寄存器里设置两个位，真的象HAL库这样写更容易让使用者理解吗？除非是纯软件工程师来做嵌入式开发，否则但凡懂硬件的工程师，不可能更喜欢HAL库这种写法！
另：我始终不认为纯软件工程师能做好嵌入式软件，至少对我来说，不把处理器所有的寄存器了解一遍，我是不敢让我的程序批量出去的！

zxzx8059 · 发表于 2017-9-5 08:33:55

小封裝的ROM常常都少，原廠的build完就沒剩多少ROM能用了，
這場合還是適合直接動reg..

wzd5230 · 发表于 2017-9-5 08:34:27

lixin91985 发表于 2017-9-4 21:21
用过CYPRESS 才知道ST落后很多了。。 IDE 全整合，图形配置，代码编辑，编译。

即使这样，我还是经常需要 ...

cypress哪个系列是这样的？我用Traveo系列，累成狗！

security · 发表于 2017-9-5 08:34:49

EMC菜鸟发表于 2017-9-5 08:31
我觉得对电路板而言，这个方向并不一定正确，，，，，，我始终认为，电路板不是计算机，配置千差万别的， ...

这个因应用而定。看项目体积。
像我从业 10 多年，从来没有把任何一款 MCU 的寄存器，全部了解一遍。
没精力啊，一般只有遇到问题，才会聚焦某个模块。

atommann · 发表于 2017-9-5 08:39:40

Thus, programs must be written for people to read, and only incidentally for machines to execute. -- SICP
出处 https://mitpress.mit.edu/sicp/front/node3.html

security · 发表于 2017-9-5 08:43:13

atommann 发表于 2017-9-5 08:39
Thus, programs must be written for people to read, and only incidentally for machines to execute. -- ...

好吧，原话出处搬来了，
说明我不是在这边瞎 BB 的。

EMC菜鸟 · 发表于 2017-9-5 09:02:35

security 发表于 2017-9-5 08:34
这个因应用而定。看项目体积。
像我从业 10 多年，从来没有把任何一款 MCU 的寄存器，全部了解一遍。
没 ...

还是你舒服！
对我来说，批量出去后，如果出问题，那只能辞职也谢罪了，，，，，，（小公司的悲哀？）

fengyunyu · 发表于 2017-9-5 09:11:26

自从用了st，就没看寄存器了

huangqi412 · 发表于 2017-9-5 09:13:00

lixin91985 发表于 2017-9-4 21:21
用过CYPRESS 才知道ST落后很多了。。 IDE 全整合，图形配置，代码编辑，编译。

即使这样，我还是经常需要 ...

贴个CRPRESS的界面了解下

atommann · 发表于 2017-9-5 09:15:22

本帖最后由 atommann 于 2017-9-5 09:18 编辑

security 发表于 2017-9-5 08:43
好吧，原话出处搬来了，
说明我不是在这边瞎 BB 的。

你的观点是对的。

https://www.forth.com/starting-f ... a_Computer_Language
有这样一段话

What’s the difference between Forth and other high-level languages? To put it very briefly: it has to do with the compromise between man and computer. A language should be designed for the convenience of its human users, but at the same time for compatibility with the operation of the computer.
以现有的计算机体系来说，编程这件事情，是要在人和机器上要做一个折中。即要方便人，也要方便机器。目前芯片的发展很快，集成度越来越高，用更高级的语言编程已经是趋势，像 micropython, lua, C++, javascript, Java 用在 MCU 上等等

实际上，人的时间是非常宝贵和值钱的。新产品应早日推向市场，这要求更高的开发速度。

wzyllgx · 发表于 2017-9-5 09:21:28

不喜欢HAL还有LL可以选择，直接操作寄存器的。

2012Ehome · 发表于 2017-9-5 09:25:59

低功耗的代码空间少的用寄存器操作，不是低功耗空间允许直接上库

redroof · 发表于 2017-9-5 09:28:13

EMC菜鸟发表于 2017-9-5 08:31
我觉得对电路板而言，这个方向并不一定正确，，，，，，我始终认为，电路板不是计算机，配置千差万别的， ...

懂不懂硬件无所谓，重要的是你看到这一行，它要做什么事情是清清楚楚的。谁也不会误解。
而往某某寄存器里面写个某某数字，谁知道这是在干啥？
不说过几年，就算过一个月，你不翻手册自己都别想知道这里写的是啥

还有，就算你看着手册在写，要数寄存器的第几位也完全可能数错。特别是寄存器的很多位都要设置的情况下。
例如：你往寄存器里面写了个数字，后面跟一个注释说“设置某某功能”，结果实际上你算错了数字。下次要查的时候就够你查了。
一般人见到写明了注释说设置某某功能，肯定不会重新拿出寄存器手册来核对这个功能对应的寄存器位是不是你前面设的那几位！
而头文件里面的各个位的define值是厂家写在标准库里的，基本上不会定义错。所以你直接用这些定义就又减少了一种出错的可能。

xuzhiping9889 · 发表于 2017-9-5 09:57:10

感觉各有优缺点吧，毕竟这样封装让不熟悉的人可以尽快上手，熟悉的人你也可以直接用寄存器操作，效率也能提高

security · 发表于 2017-9-5 10:02:28

xuzhiping9889 发表于 2017-9-5 09:57
感觉各有优缺点吧，毕竟这样封装让不熟悉的人可以尽快上手，熟悉的人你也可以直接用寄存器操作，效率也能提 ...

要跟对大方向就是了。
多数的情况，用库，
少部分要求严格的情况，再来优化。

不然竞争对手的产品上市了，你的产品估计还在实验室里面。

kinsno · 发表于 2017-9-5 10:11:36

security 发表于 2017-9-4 18:02
增加注释，这个可以。
实际上，写成这样会更直观点：
PWR->CR = (PWR->CR & ~(BIT_11 | BIT_12)) | BIT_1 ...

把HAL改成这种写法，明显要舒适的多，既照顾了寄存器，也照顾了可读性。
HAL库，真的是一个冗余啊。
临时上DEMO还是很好的，有时间还是要精简的。

canspider · 发表于 2017-9-5 10:32:58

security 发表于 2017-9-4 16:59
当你明白 __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1) 背后的规则后，
过几个月后，
...

你没get到点
问题不是__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1)这个写法有多复杂难懂
而是这一堆字母真tm长不好记
你要是弄成汉字版的
HAL配置电源电压比例(电源电压比例1)
楼主肯定觉得这样写比直接写数字好多了

security · 发表于 2017-9-5 10:41:53

canspider 发表于 2017-9-5 10:32
你没get到点
问题不是__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1)这个写法有多复杂 ...

写的时候，肯定要知道这些接口的大致存在、大概命名，然后依赖自动补全功能啊。
如果写代码不依赖自动补全，那么基本还在原始社会。

canspider · 发表于 2017-9-5 10:43:35

本帖最后由 canspider 于 2017-9-5 10:45 编辑

security 发表于 2017-9-5 10:41
写的时候，肯定要知道这些接口的大致存在、大概命名，然后依赖自动补全功能啊。
如果写代码不依赖自动补 ...

补全也得要知道刚开始几个字母怎么拼的
你总不能让楼主26个字母挨个试一遍吧
你们这种能读懂单词的人永远不懂只会看字母的人的伤悲

4058665 · 发表于 2017-9-5 10:47:20

本帖最后由 4058665 于 2017-9-5 10:57 编辑

看代码确实很绕用了一段时间  觉的最主要用途是与cubemx结合，HAL库提供了标准的api，这样才能标准化和图形化
对于新手来说还是挺易上手的
最大的好处就是对于寄存器操作不需要一个个去位操作计算用惯了还是挺方便的
cubemx提供的  最好只做初始化操作应用细节觉的不少也不合理    可能cube设计的时候  就到初始化部分的原因
提供框架  让板子功能跑起来  仅仅如此

security · 发表于 2017-9-5 10:48:22

canspider 发表于 2017-9-5 10:43
补全也得要知道刚开始几个字母怎么拼的
你总不能让楼主26个字母挨个试一遍吧 ...

对于一个第三方库，肯定要知道个大概，才能开发。
总不能什么都不看，就开始写代码吧？盲目在那边敲吧？
对于合格的 SDK 而言，这些命名是要有规律的，遵循统一的前缀之类的。

就算是同一个团队内部，不同人员开发的，API 的命名，也是一样的道理，我们不会去记住全部，也不会去敲入全部，
记住模块前缀，以及开始几个字符，剩余靠自动补全。

security · 发表于 2017-9-5 10:54:58

4058665 发表于 2017-9-5 10:47
看代码确实很绕用了一段时间觉的最主要用途是与cubemx结合，HAL库提供了标准的api，这样才能标准化和 ...

至今我还没用过 STM32，没有真正去窥探一下 ST 的架构。
是个挺遗憾的事情。

li_thomas · 发表于 2017-9-5 10:57:17

本帖最后由 li_thomas 于 2017-9-5 10:58 编辑

ST有很多处理器，也有很多客户。它的出发点是可读性、兼容性和扩展性。对个人而言，相率优先。不同的出发点导致结果完全不一样

日日♂夜夜 · 发表于 2017-9-5 10:58:55

我倒觉得st为毛不搞一套C++封装库...
C++只要不用过分的模板写出来的比起C耦合好看好懂
很多地方也只要留出虚函数等待重载就可以
而不用__weak 什么的特殊标识
还有mdk什么时候把C++11标准库做出来啊

security · 发表于 2017-9-5 11:01:05

redroof 发表于 2017-9-5 09:28
懂不懂硬件无所谓，重要的是你看到这一行，它要做什么事情是清清楚楚的。谁也不会误解。
而往某某寄存器 ...

实际上，对于寄存器的直接操作，我一直使用以下形式，来避免出现 magic number，避免出错以及思考：

PWR->CR = (PWR->CR & ~(BIT_11 | BIT_12)) | BIT_11; // 设置内核电压为1.8V

也就是我在 9 楼，给楼主的建议。

security · 发表于 2017-9-5 11:04:05

日日♂夜夜发表于 2017-9-5 10:58
我倒觉得st为毛不搞一套C++封装库...
C++只要不用过分的模板写出来的比起C耦合好看好懂
很多地方也只要留出 ...

毕竟嵌入式的大哥，还是 C。
多数从业人员，对于 C++ 的掌握，恐怕还是有欠缺的。
在团队开发中，就要考虑队友的情况，现阶段，以及很长一段时间内，C 仍会是大哥，除非我们死光了

。

Excellence · 发表于 2017-9-5 12:39:31

nxp得都是寄存器操作

redroof · 发表于 2017-9-5 13:29:10

security 发表于 2017-9-5 11:01
实际上，对于寄存器的直接操作，我一直使用以下形式，来避免出现 magic number，避免出错以及思考：

PWR ...

写BitXX比写magic number好一点，但也没好太多。
你下次还是要看寄存器手册来确认BIT_11和BIT_12的功能。为什么bit11和bit12要设为这个值，会不会哪天笔误写错了？
写成 PWR_REGULATOR_VOLTAGE_SCALE1 才能完全没有疑义，再也不需要查手册了。

redroof · 发表于 2017-9-5 13:30:57

Excellence 发表于 2017-9-5 12:39
nxp得都是寄存器操作

寄存器操作其实也无所谓，只要定义清晰就行。给各个寄存器位都定义出对应的名字，然后你代码里面是与或这些名字就行了。
很多厂家都是只做到这一步为止的。

security · 发表于 2017-9-5 14:04:44

redroof 发表于 2017-9-5 13:29
写BitXX比写magic number好一点，但也没好太多。
你下次还是要看寄存器手册来确认BIT_11和BIT_12的功能。 ...

是的，这个只是给喜欢直接操作寄存器的开发者，提供一个稍微好一点的解决方案。

jingwaner · 发表于 2017-9-5 17:32:54

不管是HAL 还是寄存器，实际上都是对硬件驱动层的初始化或者配置。

使用寄存器，也可以写成模块函数，移植其他项目只要拷贝，修改个别参数即可，不会浪费太多时间。也可以快速开发出产品。

熟悉HAL库的时间，和熟悉寄存器配置或者说标准库使用，花的时间是差不多的。

而操作寄存器的好处是非常值得的：运行快，编译快，代码小

熟悉了寄存器，更容易理解MCU这类器件，对TIMER ,SPI ,I2C ,UART 了解更清楚，等你换MCU或者查找问题时，帮助更大，处理更快。

Excellence · 发表于 2017-9-5 17:34:51

从移植来说，应该用寄存器。不论st还是nxp

zlutian · 发表于 2017-9-5 22:42:59

ST，我还在一直用着早期的标准库，跟不上时代了。

7nian · 发表于 2017-9-6 07:23:34

如果你的产品知识配置这串口，IIC这几个外设就OK的话，那你想怎么来都无所谓，但是如果你的产品需要联网通信，界面交互，那这些配置的比重大么，我只需要一个稳定的通信接口，你的内部实现关我毛事，我只需要关注自己的业务逻辑就OK了，这此时真正有竞争力的地方。

zxzx8059 · 发表于 2017-9-6 08:18:31

Excellence 发表于 2017-9-5 12:39
nxp得都是寄存器操作

NXP換個IDE 函式名稱就變了
Driver包、CW(PE)、KDS、S32DS 每個都換一次

stt1990511 · 发表于 2017-9-6 11:39:20

各有各的应用场合

mqkycy · 发表于 2017-9-6 15:43:01

它的处理思路和架构是值得学习的。

MagicYang · 发表于 2017-9-6 15:45:38

关键是易读性。
直接用寄存器操作，一段时间后，自己写的代码都不认识了

javabean · 发表于 2017-9-6 16:20:01

本帖最后由 javabean 于 2017-9-6 16:26 编辑

EMC菜鸟发表于 2017-9-5 08:31
我觉得对电路板而言，这个方向并不一定正确，，，，，，我始终认为，电路板不是计算机，配置千差万别的， ...

你去看看linux的内核代码，驱动是硬件抽象，内核还对不同的处理器架构（X86,X64,Spark,Power,安腾，ARM）都有支持，全部都是抽象定义，还有各种宏
不光是软件工程师需要，硬件工程师也需要，只管这一小滩，是很简单的操作，当世界围着转的时候，任何一个简单的操作都是伟大的举动

你只搞这一个项目，很简单，ST做的事情大家都要围着转，就没那么简单。我家做窗子M2的螺丝小了，M4的螺丝又大了浪费钱，那我是自己造一个螺丝吗，还是用现成的，ST的做法在你的项目里可能是大炮打鸟，浪费，但当别人的巨型项目的时候，可能是手枪打卫星，还不够用呢，还要自己定义更多抽象，这就是小马过河，各种动物间所以没必要争，选自己合适的就好。

gongxd · 发表于 2017-9-6 17:22:57

可惜的就是hal库 bug一大堆，兼容性也不怎么好
比如最新的 stm32f4 1.6 中I2s和原来的差别很大
都是坑

shentqlf · 发表于 2017-9-6 18:19:13

我也是为了简化编程的复杂度，自己写了一套eBox固件库。用起来跟arduino差不多，非常方便

lixin91985 · 发表于 2017-9-6 23:02:45

还是STD库比较好。

lixin91985 · 发表于 2017-9-6 23:04:55

wzd5230 发表于 2017-9-5 08:34
cypress哪个系列是这样的？我用Traveo系列，累成狗！

PSOC4，，，基本不用管和寄存器相关的。直接根据硬件完成相关配置，并生成相关宏定义。。

使用起来还是有一些不方便的。例如时钟频率切换，每个中断，还套了一个乱的中断向量表，，，RAM消耗有点大。

ljc · 发表于 2018-4-11 19:53:39

使用HAL库封装到已经不需要再知道实际的寄存器配置，而如果想了解实际的配置，那么一层一层往下刨皮的同时，你会发现hal库的命名可以当作是对寄存器和配置的位注释了。

himan · 发表于 2018-4-11 19:56:34

实在是不习惯呢

nanfang2000 · 发表于 2018-4-12 09:29:18

不懂封装只能拿单片机工程师的工资，懂封装的人可以往嵌入式软件架构师升级。我是从51汇编一步一步走来的，到了今天，如果还关注单片机寄存器怎么使用的话，不会有今天的发展

jiulong855@.163 · 发表于 2018-4-12 09:57:00

好的封装、兼容性、程序的强壮度很重要的，写多了就知道这样写是必须的

No.5 · 发表于 2018-4-12 13:41:36

EMC菜鸟发表于 2017-9-5 08:31
我觉得对电路板而言，这个方向并不一定正确，，，，，，我始终认为，电路板不是计算机，配置千差万别的， ...

我同意你的观点！

yanghc · 发表于 2018-4-12 15:49:34

全部看完收获颇丰

即好懂又方便移植体积还小就是好程序。

zxzx8059 · 发表于 2018-4-13 08:40:37

Atmel ASP新版也是HAL庫
想看怎麼實現的都封裝起來看不到了

jinhuo3711 · 发表于 2018-4-13 11:15:55

wzyllgx 发表于 2017-9-5 09:21
不喜欢HAL还有LL可以选择，直接操作寄存器的。

ll是什么？

wzyllgx · 发表于 2018-4-13 11:48:11

jinhuo3711 发表于 2018-4-13 11:15
ll是什么？

LL库是直接操作寄存器的，以STM32CUBE里面可以选择是使用HAL库还是LL库。

gliet_su · 发表于 2018-4-13 13:21:22

这种还好了，我见过翻了5，6个文件才看到一个宏定义具体是什么

flamma · 发表于 2018-4-13 13:33:20

日日♂夜夜发表于 2017-9-5 10:58
我倒觉得st为毛不搞一套C++封装库...
C++只要不用过分的模板写出来的比起C耦合好看好懂
很多地方也只要留出 ...

C++的有ARM搞啊，mbed就是全套C++

CoolBird007 · 发表于 2018-4-13 13:47:30

说句难听的，ST搞这些库就是自寻死路，搞大集成到最后又不得不分开，看着吧。MDK有板你们看的。

simplorer · 发表于 2018-4-13 14:12:46

HAL的库太臃肿，可能是为了兼容或者cubemx配置做了很多妥协。
暂时放弃了，用std或者ll。

zhouyan · 发表于 2018-4-22 23:28:28

EMC菜鸟发表于 2017-9-5 08:31
我觉得对电路板而言，这个方向并不一定正确，，，，，，我始终认为，电路板不是计算机，配置千差万别的， ...

和我一样，之前用标准库，经常深入底层寄存器我加深理解。也放心。

gylg3344love · 发表于 2018-4-23 02:59:55

觉得51楼的说得太对了，简直一语惊醒梦中人，就是这种感觉。Hal库不知道什么时候才能习惯

wanglei11235 · 发表于 2018-4-23 14:44:16

在听ST的研讨会时，讲课的老师反复在强调，对于经验不足的开发者，一定要将他们的HAL库作为认真学习的对象。

用ST的HAL库后，被绕晕了，这样编程真的好吗？

阿莫论坛20周年了！感谢大家的支持与爱护！！