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

EN

它在很大程度上是基于观点的，如果这个问题因为这个原因而被关闭，我不会感到惊讶。这个答案只涉及你所问的几个方面。这是一个非常广泛的话题，很难--如果不是不可能的话--在一篇不会长达几页的帖子中包含所有内容。然而，为了给你提供我对这个话题的看法，同时试图保持公正，简短的答案是..那得看情况。

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

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

• 现有函数可能不适合您的用途。以HAL为例，它在大多数常见情况下都工作得很好，但有时您的需求可能太具体了，以至于您不得不“在引擎盖下”搞得一团糟，最终往往要么编写自己的功能变体，要么在HAL之上构建新的功能。就我个人而言，我至少能想到几个HAL函数不是我所需要的例子。这并不一定意味着这个库不好，只是有时要求非常specific.
• Messing，有时出于性能原因可能需要直接使用寄存器。HAL和类似的是一个抽象层，作为任何抽象，它们比直接使用寄存器需要更多的时间来执行。如果您试图从给定的外围设备中挤出绝对最大值，则有时必须降低到寄存器级别。

现在到我的回答中更偏颇的部分..我明白你为什么要问这个问题了。来自PIC世界，在那里Flash或CPU时钟更珍贵，在那里直接使用寄存器是有意义的。在STM32的情况下，它不再那么关键。话虽如此，你有时会偶然发现“使用寄存器是唯一正确的方法”的观点，但就我个人而言，我发现这样的讨论最终纯粹是学术上的。我认为寄存器或构建在寄存器之上的任何抽象都是工具，您应该为正确的工作使用正确的工具。没有使用正确工具的两个例子：

• 你只使用寄存器作为“唯一正确的方式”，要么是因为你自己相信它，要么是别人告诉你的。你的产品需要两倍(如果不是更多)的时间来开发，你的代码在闪存中占用的空间更少(所以现在你使用的是46%的1MB闪存，而不是48%)。对性能至关重要的代码可以满足其目标。放宽执行时间限制的代码也非常高效，但它不会对最终客户产生太大影响。你的代码的可重用性也很低--每次你为一个新的MCU家族发布新产品时，你都会发现自己一遍又一遍地重写相同的代码部分。
• 你只使用硬件抽象层/任何其他类似的抽象，因为“你没有选择如此强大的MCU来降低到寄存器级别”，或者因为你被告知永远不应该接触寄存器。您的开发速度要快得多，并且可以使用寄存器发布两个产品，而不是只发布一个产品。然而，当有执行时间限制/传输速度必须达到时，您会发现自己选择的MCU比理论上应该需要的更强大。有时，你会发现自己在HAL周围编写包装器，因为它们并没有给你提供你所需要的功能--这感觉就像是让它变得比它应该的更复杂。

所以，毕竟，如果我想说的是，你应该在个案的基础上使用适合这项工作的东西。对于STM32，你现在有3个选择: HAL (顶层抽象层)，HAL (低级抽象-通常是简单的寄存器访问的包装函数)或者直接使用寄存器。你选择哪一个应该取决于你的需求。

我一直在使用Nucleo主板。它允许我在准备好实际的硬件之前就开始编写软件。

HAL & register方式与其说是“行业标准”，不如说是程序员的选择。我个人在编写USB和以太网等更复杂的外围设备时使用HAL驱动程序，以避免从头开始布线整个堆栈。

我刚刚完成了我的学位，我们大量使用了STM32平台和CMSIS和HAL。

这是一个偏好的问题。HAL库提供了更高的抽象，但带有一些不太直观的怪癖。HAL (was/)有时是错误的。我们遇到过SPI传输错误，由于每字节传输的延迟，导致SPI的较高传输速率无法使用。

CMSIS提供较低级别的访问，但仍然抽象出简单的位操作。我不认为直接寄存器访问是一种很好的编程方式，至少应该使用CMSIS。但这仍然是一个观点、偏好和对手头工作的正确选择的问题。如果你需要速战速决:哈尔。如果你真的需要很好的控制: CMSIS。

(顺便提一下，我认为CMSIS已经被淘汰，转而支持HAL，但目前它仍然可以使用)