选择IDE

集成开发环境（IDE integrated development environment）有能力极大地影响开发。集成开发环境被设计成具有较小的学习曲线，并且通常提供一种简单的方法来从现有的驱动程序和中间件建立解决方案。

在本章中，我们将讨论如何选择IDE，看看不同类型的IDE，并选择一个IDE来创建你在本书所用的代码包中发现的所有源代码。

下面是我们将涉及的主要议题的快速列表：

• 集成开发环境的选择标准
• 平台抽象的IDE
• 开放源代码/免费IDE
• 专有的IDE
• 为本书选择IDE

IDE选择标准

有些工程师喜欢不使用IDE，而是把他们最喜欢的文本编辑器和命令行编译器或链接器（如GCC或Clang）放在一起，手工制作一些makefiles，然后开始编码。这也是一种完全有效的方法--它将带来巨大的灵活性，减少对专有工具的依赖，当然应该考虑。

以下各节中的IDE列表并不意味着是详尽的。列出这个清单是为了提供一些例子，说明可用的IDE的多样性和每个IDE的不同焦点。下面是一些快速考虑的要点：

• 语言支持： 并非所有的嵌入式MCU都是用C99（或汇编）编写的；现在有许多语言选择。

• 调试支持： 除非你打算每次都切换到不同的工具，否则调试是必要的。你的IDE应该有一些调试能力。许多IDE依靠GNU调试器（GDB）作为底层调试协议，这意味着它们应该与任何支持GDB接口的调试硬件兼容。

• 线程感知的调试： 理想情况下，IDE应具有线程感知调试能力。记住，每个任务都有自己的堆栈。默认情况下，大多数调试功能只显示与当前程序计数器相关的堆栈，当试图分析任何当前未运行的任务时，这就成了问题。

• 设备支持： 挑选能够了解设备中硬件寄存器的IDE（除非你不会用它进行调试）。

• 平台操作系统： 即Windows、Linux或macOS--你总是可以运行一个虚拟机，但通常在你喜欢的操作系统上原生运行IDE会更方便。

• 成本： 包含获取、使用等成本。

• 与其他工具的集成： 开发一个嵌入式系统有许多组成部分。拥有一个尽可能多的集成开发环境是有帮助的，但需要考虑的一些项目是目标硬件、测试夹具、调试硬件、RTOS固件、用户固件、目标中间件、帮助配置硬件的辅助主机软件（即STM32Cube）、帮助你分析和调试代码的软件（即静态分析工具），以及测试框架。

• 易用性： 理想情况下，一DE将提供一个愉快的编码环境，并通过自动交叉引用（如IntelliSense）使代码创建更容易，从而提高生产率。

• 可用性：IDE将是可用的，完全支持的，并提供更新，以便在一个产品或项目的整个生命周期内充分利用新的硬件目标。对于长期项目来说，检查你打算使用的IDE的历史（和许可模式）是个好主意。如果集成开发环境只能通过订阅来使用（没有永久许可选项），可能有一天它就不再可用了。确保永久许可证始终在手，你就可以无限期地运行集成开发环境，并保证你始终能够从源代码中复制二进制文件。

• 生态系统： 大多数集成开发环境都不只包含集成开发环境本身。它们会有插件、中间件、论坛，有时还有整个开发者社区。

在接下来的章节中，我们将介绍几个不同概念的IDE组。以这种方式对IDE进行分组并不特别死板，但它确实有助于对它们的动机和用例的预期进行框定。有时，一个IDE可以被归入不止一个组别，这也是完全可以接受的。我们将用来对IDE进行分类的组别如下：

• 免费的MCU供应商IDE和以硬件为中心的IDE
• 平台抽象的IDE
• 开放源代码/免费IDE
• 专有的IDE

本章介绍的IDE实例是2019年的。虽然嵌入式系统固件开发工具的变化不像其他软件学科那么快，但预计随着时间的推移，情况会有一些变化

免费的MCU供应商IDE和以硬件为中心的IDE

如今，较大的MCU制造商通常会提供一个免费的IDE，以帮助降低潜在开发者的门槛。从历史上看，这些IDE除了提供一个编译器外，并没有提供更多的东西，而且如果你每天使用它们，一般来说是很糟糕的。然而，在过去的几年里，由于芯片制造商试图将自己与竞争对手区分开来，已经出现了向更高质量的供应商提供的IDE的转变。有时，它们集成了额外的功能，可以帮助配置硬件和/或供应商提供的驱动程序，这在硬件开发、最初的板卡启动和早期的固件开发中是很有帮助的，因为硬件外设正在被锻炼并与系统的其他部分集成。

由于这些工具并不是硬件制造商的核心业务，它们经常会被临时改变。这使得供应商的集成开发环境对于长期运行的项目来说是一个危险的选择。

几乎是为了证明这一点，STM在写这本书的时候改变了他们的IDE产品。所有的例子都需要被导入到新的软件中： STM32CubeIDE。
由于我们将使用STM32单片机作为我们的目标，我们将看看STM提供的IDE（在写作时，这是STM32CubeIDE）。对于每个不同的MCU供应商，你可以考虑他们专有的IDE--例如，如果你在NXP MCU上开发，你可能会考虑MCUXpresso。

STM32CubeIDE

在STM的案例中，同一MCU供应商提供了多个IDE。在收购Atollic之后，STM将Atollic TrueStudio的完全定制版与STMCubeMX应用程序一起推出，从而形成了STM32CubeIDE。尽管Atollic TrueStudio仍然可用，但它已被废弃，不建议用于新设计。

以下是STM32CubeIDE的快速统计数据：

平台抽象化的IDE

越来越复杂的MCU、对设备功能不断膨胀的期望以及不断缩小的开发周期，促使许多软件工具公司专注于创建高于硬件的抽象，其目的是使复杂设备的开发更加容易和快速。最成功的平台和抽象往往在上市几年后就有了自己的生命。Mbed和Arduino都有广泛的用户社区，有许多用户创建的网站和博客专门用于每个平台。

因为平台的一致性对于易用性是最重要的，所以实现通常会包括许多注重易用性的功能，有时会牺牲性能和良好的设计实践。例如，一些硬件目标将为诸如PWM输出等暴露一个API，即使底层MCU硬件没有支持该功能的外设。这在许多不同的硬件目标上创造了更快的原型开发经验，因为API将无缝地把功能映射到软件程序中。然而，设备性能会因此受到负面影响。有时，程序员甚至没有意识到在他们所做的简单的API调用之下，正在进行复杂的权衡。

有许多不同的因素决定了围绕一个平台的项目是否是一个好主意。

在以下情况下，在一个平台之上进行设计可能是好的：

• 该平台几乎包含了你所需要的一切： 如果平台已经有了所有的主要部分，那么就没有什么不确定性；所需要的只是一些特定领域的代码。
• 你预定的目标设备有一个符合你确切要求的开发板： 这导致的不确定性比试图添加许多缺失的子电路并将其与现有的平台代码适当整合要少。
• 团队中的大多数工程师已经对该平台有很深的经验： 深厚的经验意味着他们已经增加了类似于项目所需的任何定制的能力

在一个平台之上进行设计，在以下情况下可能是不好的：

• 很少有团队成员对所需的平台有经验： 有些平台比其他平台更复杂--没有第一手经验的人可能是有风险的。
• 打算使用的MCU还没有被平台所支持： 在一个平台上添加MCU支持通常有许多辅助要求，这些要求对你的项目没有任何价值。对于一个非常简单的项目来说，在现有的复杂平台上增加对一个新设备的支持，比在裸机上或用最小的供应商提供的库来创建项