向使用 STM32 NUCLEO 的嵌入式系统工程师提出的问题

Question

我最近购买了 STM32 NUCLEO 开发套件，想知道实际的嵌入式系统工程师在开发产品时是否会在行业中使用它？

我正在使用 Kiel Uvision 5、STMCubeMX 和 STM32 ST-LINK Utility 来开发某些项目。由于我习惯使用 PIC 和 PORTA、OSCCON、TIMER0 等寄存器，我看到 Kiel Uvision 5 使用现成的函数，如 HAL_GPIO_TogglePin(.........) 等。这是他们通常的做法吗这是在工业中还是更直接地与寄存器一起工作？

Answer 1

它很大程度上基于意见，如果这个问题因此而结束，我不会感到惊讶。这个答案只涉及您所问问题的几个方面。这是一个非常广泛的主题，即使不是不可能，也很难将所有内容包含在一篇文章中，而一篇文章最终不会有几页长。然而，为了向您提供我对这个主题的看法，同时努力保持公正，简短的答案是……这取决于情况。

如果您询问最常见情况下使用什么，很可能是您提到的 HAL（以前称为 StdPeriph）函数。原因是——他们在大多数常见情况下都能完成工作。毕竟，这总是取决于创建产品的成本。如果 HAL 函数对于这个目的来说“足够好”，那么它们将会被使用，因为它们的开发速度更快。开发成本越高，您就越想削减它（或将其移到其他地方），而使用抽象是这样做的一种方法。

然而，尽管我认为可以安全地假设 HAL / Std Periph / 任何其他（包括专有）抽象层通常被使用，但情况并非总是如此，我能想到的至少有两个原因：

• 现有功能可能不适合您的目的。以 HAL 为例，它在大多数常见情况下工作得很好，但有时您的需求可能非常具体，以至于您必须“在幕后”搞乱，通常最终要么编写自己的函数变体在 HAL 之上构建新的东西。就我个人而言，我至少可以想到几个 HAL 函数不完全是我需要的例子。这并不一定意味着该库不好，只是有时要求非常具体。

• 出于性能原因，有时可能需要直接修改寄存器。HAL 和类似的都是抽象层，与任何抽象一样，它们比直接使用寄存器需要更多的时间来执行。如果您试图从给定的外设中挤出绝对最大值，有时您必须降低到寄存器级别。

现在我的答案中更有偏见的部分..我明白你为什么问这个问题。来自闪存或 CPU 时钟更为珍贵的 PIC 世界，直接使用寄存器确实有意义。对于 STM32，它不再那么重要了。话虽如此，您有时会偶然发现“使用寄存器是唯一正确的方法”的观点，但我个人发现此类讨论最终纯粹是学术性的。我将寄存器或构建在其之上的任何抽象视为工具，您应该使用正确的工具来完成正确的工作。没有使用正确工具的两个例子：

• 您只使用寄存器作为“唯一正确的方法”，要么是因为您自己相信，要么是别人告诉您的。您的产品需要两倍（如果不是更多）的时间来开发，您的代码在闪存中占用的空间更少（因此现在您使用 1MB 闪存的 46%，而不是 48%）。对性能至关重要的代码可以满足其目标。放宽执行时间限制的代码也非常高效，但它不会对最终客户产生太大影响（如果有的话）。您的代码的可重用性也较差 - 每次为新的 MCU 系列发布新产品时，您都会发现自己一遍又一遍地重写相同部分的代码。

• 您只使用 HAL/任何其他类似的抽象，因为“您没有选择如此强大的 MCU 必须深入到寄存器级别”，或者因为您被告知永远不应该触摸寄存器。您的开发速度会更快，并且可以使用寄存器发布两种产品，而不仅仅是一种产品。然而，当您必须达到执行时间限制/传输速度时，您会发现自己选择的 MCU 比理论上需要的功能更强大。有时您会发现自己围绕 HAL 编写包装器，因为它们没有为您提供所需的功能 - 感觉就像让它变得比应有的更复杂。

毕竟，如果我想说的是，你应该根据具体情况使用适合工作的东西。对于 STM32，您现在有 3 个选择：HAL（顶级抽象级别）、HAL LL（低级抽象 - 通常是围绕寄存器访问的简单包装函数）或直接使用寄存器。您选择哪一种应该取决于您的要求。