关于 STM32 HAL 质量和性能
About STM32 HAL quality and performance
我即将开始一个基于经典 STM32L4 产品的新项目。
我在 ARM 开发方面有很好的经验，但在 STM32 方面没有特别的经验。
我想知道 STmicro（在 STM32Cube 包中）提供的 STM32 HAL 和低级驱动程序的质量和性能如何。
我想收集开发人员关于该主题的经验和反馈。
基本上我想知道您是否对这段代码感到满意，或者相反，如果您遇到一些问题，如果你们中的一些人出于某种原因开发了自己的驱动程序，等等......
谢谢！
我不喜欢 HAL 有很多原因：
- 它给伪开发者一种他们不必知道他们的硬件是如何工作的错觉。
- 学习 HAL 所花费的时间可能（通常）比了解硬件工作原理所需的时间更长。
- 可怕的开销
- 很多错误。
但另一方面，我使用HAL（实际上是我深度修改过的）来控制两个外围设备USB和以太网，因为写入可能会花费太多时间。但是正如我之前写的那样，我知道它在 hardware/low 级别上是如何工作的，并根据我的喜好对其进行了修改。
我个人不喜欢 HAL 库，原因如下。
- 它在我的控制器中占用了很多内存，我真的没有 space 适合引导加载程序和应用程序的地方，这里我还需要添加 2 个 HAL 开销（一个在引导加载程序中，另一个在申请）。
- 它在内部使用中断（我很确定它确实如此）
- 它不是没有错误，我曾经尝试过 1.0 版，但失败得很惨。
- 调试很痛苦，您永远不知道错误在哪里，在您的应用程序中还是在 HAL 中。
我喜欢ST的是Standard Peripheral Library，就是汇编到C的转换器，非常好用。
从较小的8位微控制器过渡到ARM后，我立即开始使用STM32上的HAL库，并获得了或多或少令人满意的体验。但是它带来了已经说过的开销和大量记录不完整的功能。这可能会导致一些混乱。
但是，与从头开始手写代码相比，使用 HAL 的最大优势在于它提供的抽象级别。当我需要从一种 STM32 切换到另一种时，这就派上用场了；以及当我需要快速起床并 运行 时。 - 我在几个非常不同类型/系列的 STM32 微控制器（L0、L1、F1、F4、F7）上使用了非常相似的代码；它实际上大部分时间都有效。使用 HAL 库使转换变得不那么痛苦，而不是当您需要知道特定微处理器的确切内存映射和寄存器布局时...
话虽如此，我需要承认，在现代嵌入式软件方面我仍然是一个新手，并且我仍在学习，在不同的基于 STM32 的项目（业余和专业）上进行了大约 2 年的原型设计工作之后).我还需要进一步了解提供的 LL 代码，例如
以不同的软件背景进入嵌入式领域，使用HAL级代码而不是按正确顺序旋转不同寄存器的单个位，并考虑所有不同的限制以获得例如基本的UART / SPI / I2C沟通工作，让我轻松了很多。恕我直言，STM32 HAL 介于纯手写代码和 mbed 所做的示例（C++/供应商不可知抽象（据我所知））之间。 - 它将复杂的野兽驯服到可接受的水平，以便像我这样的普通软件开发人员可以处理它。这伴随着一些权衡，就像其他人已经提到的那样......
毕竟，STM32 HAL 也可以用作样板代码存储库，在某些情况下，有时 read/understand 比神秘的参考手册更容易理解。 - 使用 STM32CubeMX 生成的 HAL 代码总是让我在启动时更顺利地开始，当我需要快速测试一块新板时。它还可以帮助进行实验和测试。如果稍后需要手动优化性能关键部分，那么在设置项目后仍然可以进行优化，甚至可以使用 STM32CubeMX 对其进行增量调整。您可以将手写代码与 HAL 代码混合使用。
自 2016 年以来发现的一些问题：
一些常量、结构和函数签名在 ST 发布新代码更新时发生了变化。事情似乎在不断发展。
缺乏良好的文档（代码文件中的注释）和干净的示例代码（太具体，也没有很好的记录）。
代码复杂，有时效率低下。
拼写错误。
我喜欢 HAL 和 Cube，但你必须阅读驱动程序并做好受苦的准备。
我曾经像反对者一样摇摆不定，你可以选择你的毒药。
在我的情况下，如果我使用 HAL，我可以吸引真正的程序员来维护我的代码。不用多说，我参与了 HAL。预先警告，立方体只是创建了一个可行的近似值。
我即将开始一个基于经典 STM32L4 产品的新项目。 我在 ARM 开发方面有很好的经验，但在 STM32 方面没有特别的经验。 我想知道 STmicro（在 STM32Cube 包中）提供的 STM32 HAL 和低级驱动程序的质量和性能如何。 我想收集开发人员关于该主题的经验和反馈。 基本上我想知道您是否对这段代码感到满意，或者相反，如果您遇到一些问题，如果你们中的一些人出于某种原因开发了自己的驱动程序，等等...... 谢谢！
我不喜欢 HAL 有很多原因：
- 它给伪开发者一种他们不必知道他们的硬件是如何工作的错觉。
- 学习 HAL 所花费的时间可能（通常）比了解硬件工作原理所需的时间更长。
- 可怕的开销
- 很多错误。
但另一方面，我使用HAL（实际上是我深度修改过的）来控制两个外围设备USB和以太网，因为写入可能会花费太多时间。但是正如我之前写的那样，我知道它在 hardware/low 级别上是如何工作的，并根据我的喜好对其进行了修改。
我个人不喜欢 HAL 库，原因如下。
- 它在我的控制器中占用了很多内存，我真的没有 space 适合引导加载程序和应用程序的地方，这里我还需要添加 2 个 HAL 开销（一个在引导加载程序中，另一个在申请）。
- 它在内部使用中断（我很确定它确实如此）
- 它不是没有错误，我曾经尝试过 1.0 版，但失败得很惨。
- 调试很痛苦，您永远不知道错误在哪里，在您的应用程序中还是在 HAL 中。
我喜欢ST的是Standard Peripheral Library，就是汇编到C的转换器，非常好用。
从较小的8位微控制器过渡到ARM后，我立即开始使用STM32上的HAL库，并获得了或多或少令人满意的体验。但是它带来了已经说过的开销和大量记录不完整的功能。这可能会导致一些混乱。
但是，与从头开始手写代码相比，使用 HAL 的最大优势在于它提供的抽象级别。当我需要从一种 STM32 切换到另一种时，这就派上用场了；以及当我需要快速起床并 运行 时。 - 我在几个非常不同类型/系列的 STM32 微控制器（L0、L1、F1、F4、F7）上使用了非常相似的代码；它实际上大部分时间都有效。使用 HAL 库使转换变得不那么痛苦，而不是当您需要知道特定微处理器的确切内存映射和寄存器布局时...
话虽如此，我需要承认，在现代嵌入式软件方面我仍然是一个新手，并且我仍在学习，在不同的基于 STM32 的项目（业余和专业）上进行了大约 2 年的原型设计工作之后).我还需要进一步了解提供的 LL 代码，例如
以不同的软件背景进入嵌入式领域，使用HAL级代码而不是按正确顺序旋转不同寄存器的单个位，并考虑所有不同的限制以获得例如基本的UART / SPI / I2C沟通工作，让我轻松了很多。恕我直言，STM32 HAL 介于纯手写代码和 mbed 所做的示例（C++/供应商不可知抽象（据我所知））之间。 - 它将复杂的野兽驯服到可接受的水平，以便像我这样的普通软件开发人员可以处理它。这伴随着一些权衡，就像其他人已经提到的那样......
毕竟，STM32 HAL 也可以用作样板代码存储库，在某些情况下，有时 read/understand 比神秘的参考手册更容易理解。 - 使用 STM32CubeMX 生成的 HAL 代码总是让我在启动时更顺利地开始，当我需要快速测试一块新板时。它还可以帮助进行实验和测试。如果稍后需要手动优化性能关键部分，那么在设置项目后仍然可以进行优化，甚至可以使用 STM32CubeMX 对其进行增量调整。您可以将手写代码与 HAL 代码混合使用。
自 2016 年以来发现的一些问题：
一些常量、结构和函数签名在 ST 发布新代码更新时发生了变化。事情似乎在不断发展。
缺乏良好的文档（代码文件中的注释）和干净的示例代码（太具体，也没有很好的记录）。
代码复杂，有时效率低下。
拼写错误。
我喜欢 HAL 和 Cube，但你必须阅读驱动程序并做好受苦的准备。 我曾经像反对者一样摇摆不定，你可以选择你的毒药。 在我的情况下，如果我使用 HAL，我可以吸引真正的程序员来维护我的代码。不用多说，我参与了 HAL。预先警告，立方体只是创建了一个可行的近似值。