关于 STM32 HAL 质量和性能 [关闭]答案

【问题标题】：About STM32 HAL quality and performance [closed]关于 STM32 HAL 质量和性能 [关闭]
【发布时间】：2018-09-10 19:00:38
【问题描述】：

我即将开始一个基于经典 STM32L4 产品的新项目。我在 ARM 开发方面有很好的经验，但在 STM32 方面没有。我想知道 STmicro 提供的 STM32 HAL 和低级驱动程序（在 STM32Cube 包中）的质量和性能如何。我想收集有关该主题的开发人员经验和反馈。基本上我想知道你是否对这段代码感到满意，或者相反，如果你遇到一些问题，如果你们中的一些人出于某种原因开发了自己的驱动程序等等...... 谢谢！

【问题讨论】：

供应商提供的库的质量？中等通常，只需自己查看代码（简单的一瞥应该可以巩固您的答案）。性能，差，经常写覆盖几个家庭，非常臃肿，执行的代码的一部分不适合你的芯片，也不是完全 if-then-elsed out。总的来说，不是特别指任何一个特定的芯片供应商......
专业地你应该能够使用这些库或不使用这些库，你应该定期尝试每个供应商的解决方案以及阅读手册（在为下一个项目选择路径时）。您拥有包括您选择的库在内的代码，您的老板不会关心他们必须吃掉 10,000 个单位，因为您想通过使用别人的代码来节省时间，您的责任，您拥有它您查看库并祝福他们/拥有它们.
我还发现阅读手册和对寄存器进行编程比尝试让库工作更容易。有时您必须深入研究他们的代码才能找到手册中的错误，但是在那里您发现您真的很高兴您没有使用该库...再次笼统地说...ST文档很好，不是最好的（相当关闭），绝对不是最糟糕的。

标签： arm stm32

【解决方案1】：

我不喜欢 HAL 有很多原因：

它给伪开发者一种错误的感觉，即他们不必知道他们的硬件是如何工作的。
学习 HAL 所花费的时间可能比了解硬件工作原理所需的时间更长（通常是这样）。
可怕的开销
很多错误。

但另一方面，我使用 HAL（实际上由我进行了深入修改）来控制两个外围设备 USB 和以太网，因为写入可能需要太多时间。但正如我之前写的那样，我知道它在硬件/低级别上是如何工作的，并根据我的喜好对其进行了修改。

【讨论】：

是的，你是对的！ USB 和以太网等外围设备过于复杂，无法从头开始编写驱动程序。但我真的不明白有人用 HAL 控制 GPIO、UART、SPI 和其他简单的外围设备。如果是自己的驱动程序，您可以完全控制外围设备。
感谢您的回答。您能否详细说明第 3 点和第 4 点？
还有，STMicro提供的底层驱动呢
关于第 1 点，这不正是 HAL 的一般用途吗？ :)
3.为了使抽象层几乎总是增加一些开销，直接外围寄存器配置需要的代码少得多，而且速度也更快。

【解决方案2】：

我个人不喜欢 HAL 库，原因如下。

它在我的控制器中占用了大量内存，我真的没有空间可以容纳引导加载程序和应用程序，在这里我还需要添加 2 个 HAL 开销（一个在引导加载程序中，另一个在应用程序中）。
它在内部使用中断（我很确定它确实如此）
它不是没有错误的，我曾经尝试过 1.0 版，但失败了。
调试很痛苦，您永远不知道错误在哪里，在您的应用程序中还是在 HAL 中。

我喜欢 ST 的标准外设库，它只是汇编到 C 的转换器，非常易于使用。

【讨论】：

#2 不正确，除非您明确要求，否则 HAL 不会使用中断。
#2 不正确。 #3 是否有任何软件错误？你在那里设置的标准有点高。 #4 任何人的代码都是如此。
@TarickWelling 您可以承受应用程序中的错误。但是在 BSP 中出现 bug 会让你在调试时畏缩不前。只有一种方式你想使用你的外围设备，而且必须是正确的..
@Tarick Welling 至少大多数软件最不礼貌的是，当发布错误时，他们会在关闭问题之前对其进行修补。我正在使用带有旧版本 hal 的 f1 并且 I2c 协议工作得很好，我更新到 1.8 版本并且 Hal 坏了，我去他们的 github 看看是否有人发布了这个问题。我担心我做错了什么，因为没有任何相关的未解决问题。这个白痴为一个有同样问题的人做了一个修补程序，然后像什么都没发生一样在没有修补的情况下关闭了问题。[证明] (github.com/STMicroelectronics/STM32CubeF1/issues/6)
@DheerajKumar 我并不是说其他人的代码中的错误（在像 BSP 这样的核心代码中更是如此）不会很糟糕和令人沮丧，但存在错误是不可避免的事情。我也完全不同意只能以一种方式使用外围设备的概念。以 DMA 为例，它非常复杂，可以做很多事情，因此很难编程。

【解决方案3】：

从较小的 8 位微控制器过渡到 ARM 后，我立即开始在 STM32 上使用 HAL 库，并获得了或多或少令人满意的体验。但它带来了如前所述的开销和大量记录不充分的功能。这可能会导致一些混乱。

但是，与从头开始手写代码相比，使用 HAL 的最大优势在于它提供的抽象级别。当我需要从一种类型的 STM32 切换到另一种类型时，这会派上用场；以及当我需要快速启动和运行时。 - 我在几个非常不同类型/系列的 STM32 微控制器（L0、L1、F1、F4、F7）上使用了非常相似的代码；它实际上大部分时间都有效。使用 HAL 库比您需要知道特定微的确切内存映射和寄存器布局时要轻松得多...

话虽如此，我需要承认，在现代嵌入式软件方面，我仍然是一个新手，而且我还在学习，经过大约 2 年的不同基于 STM32 的项目（爱好和专业）的原型设计工作。例如，我仍然需要了解有关提供的 LL 代码的更多信息。

以不同的软件背景进入嵌入式领域，使用 HAL 级别代码而不是按正确顺序旋转不同寄存器的单个位，并考虑所有不同的限制以使例如基本的 UART / SPI / I2C 通信正常工作，对我来说轻松了很多。恕我直言，STM32 HAL 位于纯手写代码和 mbed 所做的例如（C++ / 与供应商无关的抽象（据我所知））之间的中间地带。 - 它将复杂的野兽驯服到可接受的水平，以便像我这样的普通软件开发人员可以处理它。这需要一些权衡，就像其他人已经提到的那样......

毕竟，STM32 HAL 还可以用作样板代码存储库，在某些情况下，它有时比神秘的参考手册更容易阅读/理解。 - 当我需要快速测试新板时，使用 STM32CubeMX 生成的 HAL 代码总是让我在启动时开始更加顺畅。它还可以帮助进行实验和测试。并且当稍后需要手动优化性能关键部分时，在设置项目后仍然可以这样做，甚至使用 STM32CubeMX 逐步调整它。您可以将手写代码与 HAL 代码混合使用。

自 2016 年以来发现的一些问题：

当 ST 发布新的代码更新时，一些常量、结构和函数签名发生了变化。事情似乎在不断发展。
缺乏良好的文档（代码文件中的 cmets）和干净的示例代码（太具体，也没有很好的文档记录）。
代码复杂，有时效率低下。
拼写错误。

【讨论】：

但重要的一点是，您将 Hal 与棍子和石头进行比较，当然 Hal 总比没有好，但与假设的正常工作的硬件抽象层相比，它仍然很糟糕（正如 Rust 所做的那样)

【解决方案4】：

我喜欢 HAL 和 Cube，但您必须阅读驱动程序并准备好受苦。我曾经像反对者一样摇摆不定，你可以选择你的毒药。在我的情况下，如果我使用 HAL，我可以吸引真正的程序员来维护我的代码。别再说了，我在 HAL 上。请注意，Cube 只是创建了一个可行的近似值。

【讨论】：