让我告诉您，我们中的很多人都对 HAL 库感到失望，它们确实记录得很差且含糊不清，而且仍然是新的包含许多错误。

因此，要回答您的问题，为什么 ST 决定采用 HAL 很简单：

1. 他们想创建一个硬件抽象层，用简单的英语表示他们希望软件开发和代码独立于微控制器，所以如果你今天为 stm32f4 编写代码，并且你需要在几年后迁移到 stm32f7 它将很容易，代码将高度模块化。

2. 这也允许更多的开发人员（如软件程序员）使用微控制器，而无需真正了解或深入了解硬件如何完成任务的深层细节。ST 和 TI 等公司（现在开始这条路）正在尝试使嵌入式开发类似于 PC 代码开发，您可以使用高级驱动程序快速开发代码。ARM 设备的高性能弥补了其驱动程序和库中的笨拙和缺乏优化。

3. 如果您使用 HAL 库，我认为 STM32cubeMX 是一个很棒的工具，因为最耗时的工作是初始化外围设备，现在您可以在很短的时间内完成，并且可以轻松更改可视化界面而不会影响用户代码（如果您在适当的地方编写代码）您可以使用 Stm32cubeMx 然后查看代码并尝试了解他们如何以及为什么使用每个功能，这样您就可以尝试解决练习并在附近有解决方案手册以进行更正伟大的海事组织。

4. ARM 内核非常复杂，因此我们在 8 位微控制器上使用的旧方法，如直接处理寄存器（以汇编方式编写 C）是不可行的，由于架构复杂，它既耗时又难以维护（检查例如时钟设置）

创建自己的库非常简单。他们的寄存器规范文档非常好，即使不是所有的外围设备也很容易设置。我发现使用他们的库更痛苦。但也许这只是我。st、nxp、ti、atmel 仅举几例（对于英特尔和微芯片而言，情况并非如此）。

他们为什么要更换图书馆，可能有很多原因，一些新老板接手，一些部门关闭，另一个接管。营销部门希望产品有一个新形象。正如 ElectronS 所提到的，这可能是一种尝试从硬件中抽象出来，以吸引不愿意或不能做裸机的用户。我会进一步说，他们可能正试图与 Arduino 现象竞争。mbed 和其他所有人一直尝试做但失败了（甚至在 Arduino 之前）。

在任何情况下，离硬件越远，它就会变得越臃肿和越慢，所以你必须为 rom、ram 和 mhz 花费更多的单位。只是为了让你能花同样多的时间编程？只是做的不一样吗？

你说你来自 PIC 世界，现在他们确实在工具方面做得很好，但他们的芯片文档很糟糕，有些是最糟糕的。他们用库和沙箱作为补偿。

在一天结束时，尝试各种选项，尝试竞争产品，看看他们的工具如何比较。你可以免费做很多事情，看看它是否有意义，你可以编译东西。甚至可能使用指令集模拟器。找到适合您的那个。

请注意，您始终可以使用无罐装库选项。您不受可以使用什么工具链、什么主机操作系统、什么 ide、编辑器等的限制。如果他们的选择在这方面非常有限，他们可能会坚持给您编程零件，然后转移到其他芯片或供应商，如果可以的话。

为了销售这样的芯片产品，他们必须提供一个开发环境，无论是他们所有的还是他们粘合在一起的免费东西。他们倾向于将某种图书馆放在一起。它只需要看起来足够好，并且 LED 示例的闪烁效果足以让您的管理人员或您的硬件团队在他们的产品中进行设计，然后当您的电路板产品被扔到软件的墙上时，就是痛苦的时候到达或没有到达。如果它几乎可以工作，但对芯片供应商来说不是一个巨大的胜利，因为您现在将为最后一点点的技术支持付费。因此，几乎到那里但不完全符合他们的最大利益。

芯片供应商只需要看起来足够好就可以赢得设计。他们必须不断改进（？改变）产品以吸引新老客户。因此，他们将进行重做，相隔多远以及继续支持的先前库数量各不相同。所以几乎任何你习惯的图书馆最终都会消失。所以要学会适应（或者不要使用他们的东西而去你自己的东西，你可以无限期地支持）。当然，理想情况下，您只需要为每个产品开发一次应用程序，使您的固件完美（如果使用第三方库，祝您好运），如果您能找到一个可以加载其工具链的计算机，您将不需要返回复制它，并记住如何使用那个旧库。请记住，您不仅应该保存源代码，还应该保存他们的所有工具和文档。

他们的库通常仅在一个工具链上受支持，在一个可能是两个 IDE 下，有时仅在 Windows 和某些版本上受支持。同样，如果您自己做，那么您没有这些限制，绝对不是 ARM。您始终可以阅读他们的任何/所有库，以了解他们是如何做事的。但这通常很可怕，他们不使用他们的 A 团队开发人员来做库，我提取了几行代码来询问面试候选人这段代码有什么问题。

为了在芯片端和软件端节省时间和精力，他们经常回收相同的 ip，所以一旦你看到外围设备在他们的一个芯片上的工作方式，它通常在他们的许多其他芯片上以相同的方式工作。是的，无论有没有它们的库，时钟系统都可能很棘手。将芯片变砖的可能性很高，这就是我的大部分芯片/电路板变砖的地方。有助于了解他们的芯片是如何工作的，例如 AVR，即使不是全部，也可以在芯片复位时重新编程，因此任何弄乱重新编程所需的引脚或挂起重新编程所需的逻辑的错误代码都不会没关系，你可以重新编程这些芯片。其中一些供应商（st 是其中之一）有一个内部引导加载程序，您可以使用带子选择它（例如在 st 世界中的 BOOT0），

一种尺寸适合所有人，没有人适合。对于软件尤其如此。因此，任何将硬件抽象出来的尝试只会让它变得缓慢和臃肿。如果这是您真正追求的，不妨获得更大的芯片并在其上运行 linux。这在很大程度上是由于开发人员不想弄脏他们的手，所以我们基本上要求这样做，他们正在努力提供它。

同样，不要将自己锁定在 st 或任何一家供应商（除非为时已晚并且管理层和/或硬件团队已将其固定在您身上，请注意 stm32 产品很好且易于使用）。货比三家。TI 在 cortex-m4 篮子里放了很多鸡蛋。您可以在这些 arm 产品以及供应商支持的解决方案上执行 mbed 操作。

您始终可以依赖的一件事是，他们会不时更改库并最终停止支持您习惯的库。

我知道这将是漫长而固执的，但由于我们刚刚（成功）发布了使用 HAL 的新产品，我认为值得考虑。另外，我不为 ST 工作，我讨厌 HAL 的每一点，几乎用 StdPeriph 重新启动了项目，我感受到了痛苦——但现在我明白了为什么。

首先，一点背景。我们开发超低功耗遥测系统，我们的产品由 STM32L1 供电。当我们开始开发固件时，我们对（裸机）ST 设备有通常的选择：手动完成所有操作、使用 StdPeriph 库或使用 HAL。ST 的人说服我们选择 HAL - 所以我们做到了。这很痛苦，我们不得不解决软件中的错误（I2C 部分让我们发疯了很长一段时间），我仍然不喜欢整体架构。但它有效。

一年多前，当我从桌面切换到嵌入式时，我被一些我无法命名甚至无法理解的奇怪事物惊呆了。随着时间的推移，我能够理解发生了什么——或者更确切地说，正在发生什么：嵌入式世界正在转型。硅变得越来越便宜，而 MCU 更强大、更通用。越来越多的设备，无论其尺寸、功率需求如何，都依赖于通用 MCU。越来越多的公司加入了这个游戏，带来了一群具有不同背景的新开发者。“刻薄”文化从传统的“具有编程魔法技能的 EE 家伙”转向“具有模糊硬件知识的 SW 家伙”。

这是好是坏无关紧要。它只是发生。实际上，它也不止一次地发生在软件界。2000 年的网络繁荣吸引了 PHP/MySQL 新手——去告诉他们 CPU 中有寄存器，他们会回答“我使用的是 Linux，所以我的操作系统中没有注册表”。早些时候，在保护模式下运行的多用户操作系统允许懒惰的开发人员在他们的整个职业生涯中永远不会设置 ISR并且很好。更早的时候，键盘和屏幕让打卡机和打印机制造商发疯了。

_{是的，当前的趋势让我个人感到难过，因为我看到无知的开发人员对最新的闪亮技术感到敬畏，同时完全无法将它们与历史联系起来。当我在 2015 年看到一个年轻的我用 WebGL 用 Ja​​vascript 编写游戏时，我想大喊“没有什么新鲜事！我在 1995 年用 C++ 和 3Dfx SDK 做了同样的事情！”。故事没有说明的是，他的游戏在我的手机上运行，​​而我的需要一台游戏 PC（和一个安装程序，我无法通过网络推送更新）。事实是，他可以在一个月内开发出一款游戏，而我在六个月或十二个月内就完成了。}

显然，无论是 ST、TI 还是英特尔，或者任何制造芯片的人都不想错过转机。他们是对的。HAL 是 ST 的回应，实际上非常合理，不仅在业务或营销方面，而且在工程方面也是如此。之所以好听，就在于名字：

硬件抽象层

如果有别的，这是你应该记住的。HAL 是一种摆脱硬件的努力。这是一个很好的工程，因为它允许我们将功能与细节分离。分层是允许开发复杂程序的原因 - 一个抽象在另一个之上，一直到硬件。抽象实际上是我们管理复杂性的最强大工具。我非常怀疑这个星球上的任何人都能够为特定的 CPU 编写 Web 浏览器的汇编程序。

文化转变确实难以消化，但我不得不认为，开发 Web 应用程序不需要阅读 Knuth 的计算机编程艺术，EE 世界必须承认有能够（并且将会！）开发嵌入式代码的新人没有阅读该死的神圣参考手册。

好消息是新玩家并不意味着老玩家的工作量减少 - 恰恰相反，恕我直言。当事情“不起作用”时，他们会打电话给谁？如果您有 RTFM（与他们不同），并且如果您知道这个晦涩的配置寄存器的每一位做什么，那么您就有优势。

在您的阅读和实验之间，只需使用 HAL。新单片机？没问题。新的MCU线？也没问题（我用 CubeMX 在短短一天内就在 STM32F4 Nucleo 上编写了一个测试代码，然后简单地将它移植到我们的设备上……感觉不错）。模拟单元测试？没问题。这个列表还在继续，因为抽象是好的。

当然，HAL 本身也不是 100% OK。它的文档很糟糕（但你有 RT F HRM，不是吗？），有错误，ST 刚刚向我们倾销了一个 beta 版本（这些天似乎很标准），他们的公众支持是个笑话。但不发布 HAL 会更糟。