关于STM32 HAL的质量和性能

Question

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

Answer 1

我不喜欢HAL有很多原因：

1. 它给伪开发人员错误的感觉，他们不必知道他们的硬件是如何工作的。
2. 学习HAL所花费的时间可能比理解硬件的工作原理要长（通常是）。
3. 可怕的开销
4. 很多错误。

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

Answer 2

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

然而，使用HAL而不是手写代码从头开始的最大优点是它提供的抽象级别。当我需要从一种STM32切换到另一种时，这就派上用场了。而且当我需要快速启动和运行时。 - 我在STM32微型（L0，L1，F1，F4，F7）的几种非常不同的类型/系列上使用了非常相似的代码;它实际上大部分时间都在工作。使用HAL库使转换变得更加痛苦，比你需要知道确切的内存映射和注册特定微处理器的布局...

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

使用不同的软件背景输入嵌入式字段，使用HAL级代码而不是按正确顺序对不同寄存器的单个位进行twiddeling，并考虑所有不同的限制以获得基本的UART / SPI / I2C通信工作，为我缓解了一些事情。恕我直言，STM32 HAL位于纯手写代码和mbed之间的中间位置（例如C ++ / vender-agnostic抽象（据我所知））。 - 它将复杂的野兽驯服到可接受的水平，这样像我这样的普通软件开发者就可以处理它。这带来了一些权衡，就像其他人已经提到的那样......

毕竟，STM32 HAL也可以作为锅炉板代码库，在某些情况下，它有时比隐藏的参考手册更容易阅读/理解。 - 当我需要快速测试新电路板时，使用STM32CubeMX生成的HAL代码总是让我在启动时更加平稳。它还可以帮助实验和测试。当性能关键部分需要稍后进行手动优化时，在设置项目后仍然可以实现，甚至可以使用STM32CubeMX逐步调整它。您可以将手写代码与HAL代码混合使用。

自2016年以来确认的一些问题：

• ST发布新代码更新时，某些常量，结构和函数签名发生了变化。事情似乎在不断发展。

• 缺乏良好的文档（代码文件中的注释）和干净的示例代码（太具体，也没有详细记录）。

• 令人费解，有时效率低下的代码。

• 拼写错误。

Answer 3

由于以下原因，我个人不喜欢HAL库。

1. 它在我的控制器中占用了大量内存，我真的没有适合Bootloader和Application的空间，在这里我需要添加2个HAL开销（一个在Bootloader中，另一个在Application中）。
2. 它内部使用中断（我很确定它确实如此）
3. 它不是没有错误的，我曾经尝试过1.0版并且失败了。
4. 调试很痛苦，你永远不知道bug在你的应用程序或HAL中的位置。

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

Answer 4

我喜欢HAL和Cube，但您必须阅读驱动程序并做好准备受苦。 我曾经像否定者一样摇摆着，你可以选择毒药。 在我的情况下，如果使用HAL，则可以吸引真正的程序员来维护我的代码。不要再说了，我正在参加HAL。请注意，多维数据集只是创建了一些有效的近似值。