微控制器实时操作系统实践5选择IDE

选择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）、帮助你分析和调试代码的软件（即静态分析工具），以及测试框架。

• 易用性： 理想情况下，IDE将提供一个愉快的编码环境，并通过自动交叉引用（如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支持通常有许多辅助要求，这些要求对你的项目没有任何价值。对于一个非常简单的项目来说，在现有的复杂平台上增加对一个新设备的支持，比在裸机上或用最小的供应商提供的库来创建项目需要更多的努力。
• 黑盒调试很困难： 随着嵌入式工程师离硬件越来越远，理解系统的行为方式变得越来越困难，特别是当有多层其他人的代码（OPC）需要挖掘的时候。

年轻的实时嵌入式工程师的职业发展会因为早期在平台上投入太多的时间和精力而受到严重阻碍。由于所有这些额外的复杂性，在实时系统中是否能可靠地达到最后期限，存在着额外的风险和不确定性。挖掘复杂的代码库来试图追踪复杂的间歇性错误可能是真正的挑战。如果没有坚实的底层知识基础可供利用，这种挑战就会变得更大。

ARM Mbed Studio

ARM Mbed是以物联网为重点的平台，它提供了非常大的中间件库和跨越许多不同硬件供应商的一致的开发环境。最初，Mbed平台只通过网站提供，但他们现在增加了Mbed Studio--可用于Windows和macOS的离线IDE。

以下是ARM Mbed Studio的快速统计资料：

由于Mbed是面向平台的，因此可以用Mbed IDE设置项目，然后导出到各种离线IDE，如ARM Keil uVision，或基于makefile的项目，导入到Eclipse和Visual Studio Code。如果你的项目需要所包含的中间件提供的功能，而且实现得很好，那么不需要重新发明轮子就可以严重节省时间。

Arduino IDE

Arduino平台是一个极其普遍的平台，有巨大的硬件和软件的生态系统。一般来说，Arduino集成开发环境用于向新人介绍电子学和编程，它使用严格的结构化库，为用户编写草图暴露了C/C++的API。Arduino的目标是使非编程人员能够快速和容易地制作原型。因此，它尽可能多地将底层硬件的细节隐藏在库中。

以下是Arduino IDE的快速统计：

还有许多非Arudino提供的IDE，可以用来为Arduino平台编程。有些会有额外的功能，并暴露出更多底层的C/C++实现。

开放源码/免费IDE

自从IBM创建了Eclipse基金会来推广一源的、高度可扩展的IDE以来，许多基于Eclipse的IDE已经涌现出来。我们将在本节中看一下两个这样的IDE。近年来，微软开始大力关注开源项目，创建了免费的、开源的Visual Studio Code文本编辑器，本节也会介绍。

用于STM32的AC6系统工作平台（S4STM32）

AC6是一家咨询公司，它贡献了基于Eclipse的IDE，针对STM32 MCU。System Workbench增加了对基于STM的发现板的一些支持，以帮助快速建立项目。AC6还提供了适用于Linux的System Workbench，如果你正在开发多核器件（来自STM32MP1系列）的应用，它可能会很有用。

以下是STM32的AC6系统工作平台的快速统计：

Eclipse CDT和GCC

你也可以选择从头开始推出自己的基于Eclipse的IDE。Eclipse CDT是C/C++开发的事实上的标准。您还需要提供一个编译器。ARM 提供了一个完整的 GCC 站点，用于从 Windows、Linux 和 macOS 向 ARM Cortex-M 设备进行交叉编译。可以在 https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm 找到它。

以下是Eclipse CDT的快速统计资料：

对于那些不喜欢Eclipse集成开发环境的人来说，存在另一种替代方案，而且越来越受欢迎： Visual Studio Code。

微软Visual Studio Code

2015年，微软发布了Visual Studio Code，这是一个文本编辑器，提供添加扩展的能力。虽然这在表面上听起来相当简单，但有足够的扩展来提供一个非常值得尊敬的IDE体验，包括IntelliSense和完整的调试能力。如果你已经习惯了基于Visual Studio的IntelliSense和调试，那么这个环境就会非常熟悉。

以下是Visual Studio Code的快速统计数据：

与Eclipse CDT类似，Visual Studio Code需要安装GCC，以及一个扩展。为了让Visual Studio正确设置，请按照以下步骤进行：

• 要安装GCC for Cortex-M，请到https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm。
• 要安装JLink工具（用于连接到调试探针），请访问https://www.segger.com/downloads/jlink。
• 要安装cortex-debug扩展，请到https://marketplace.visualstudio.com/items?itemName=marus25.cortex-debug。

到目前为止，我们所涉及的所有IDE都是免费的（在某些情况下是开源的）。下一节包括那些要花钱的、基本上是闭源的IDE。为什么会有人想要这样的东西呢，你问。继续阅读，看看这些解决方案能提供什么。

专有的集成开发环境

付费的专有IDE曾经是MCU交叉编译应用程序的标准，现在开始被免费的、开放源码的解决方案所取代。然而，仅仅是免费选项的存在并不能立即使付费选项被淘汰。专用集成开发环境的卖点是，它们提供最广泛的设备支持，并要求开发者给予最少的关注。

设计成开箱即用，付费专业级解决方案的名声是为开发者节省时间。这些时间的节省通常有三种主要形式：设置MCU的统一环境、统一的调试环境和供应商提供的中间件，在多个MCU供应商之间通用。

现在启动和运行MCU比以往任何时候都要容易，但一旦项目进展到开始定义RAM和ROM中的特定内存区域或在基于Quad-SPI的闪存中添加额外的可执行空间，就需要一些额外的配置。最好的专业集成开发环境会提供一些帮助（通过图形用户界面），这使得这些配置比需要深入研究散点文件和基于汇编的启动代码要容易一些（尽管这些都是需要掌握的优秀技能！）。

与通过GUI快速配置MCU的能力类似，专业级IDE的调试器支持通常也是非常直接的，一般仅限于从下拉列表中选择调试器，并可能对一些设置进行微调。

如果你阅读了不同的MCU可能拥有的所有选项，那么同一MCU并不适合你进行的每一个项目，这一点可能并不奇怪。能够在MCU系列（甚至是供应商）之间快速移动，同时保持一个统一的界面是一个很好的优势。然而，被锁定在基于平台的方法中，硬件接口开始被定义（以及固件API），也可能是限制性的（即Arduino或MBed硬件定义）。

使用一个成熟的公司编写的中间件，可以使你摆脱面向硬件的平台只关注日光下的外设的倾向。它将重点从访问一个特定平台的引脚转移到访问适当抽象的MCU外设。这种区别是微妙的，但在涉及到设计灵活性时却相当重要。写得好的中间件将提供一致的MCU外设抽象，以及更复杂的中间件。

付费工具的缺点是货币成本，这需要根据开发时间、劳动力和延迟产品发布的机会成本进行评估。你知道通过使用中间件而不是重新发明固件轮子可以节省多少时间吗？拥有一个对你选择的任何处理器都能稳定工作的IDE所获得的时间量又是多少呢？一些基本的投资回报率（ROI）的计算，将现金支出与开发人员的时间的诚实和准确估计进行比较，通常会使中等复杂项目的天平倾向于购买中间件。当然，这是在假设有现金可以购买软件工具的情况下。

ARM/Keil uVision

Keil最初在20世纪80年代为8位8051架构开发了首批C语言编译器之一。该公司转而支持其他内核，并最终被ARM收购。他们目前为ARM Cortex-M设备提供最有效的编译器之一（Clang/LLVM）。uVision IDE的免费版本是可用的，但仅限于32KB的代码空间。集成开发环境的各种层级有多种许可选项（如永久的、基于订阅的等等）。代码模块是通过软件包添加的，这简化了项目的快速设置。一个功能非常全面的中间件堆栈可作为顶级产品，它为不同的实时操作系统提供了抽象，并在所有支持的MCU之上提供了统一的API。

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

FreeRTOS任务感知调试不可用--Keil uVision对他们自己的免费提供的CMSIS RTX RTOS有精心的支持。uVision MDK中的代码编辑器也该改头换面了。

与Keil uVision类似，IAR Embedded Workbench是另一个长期存在的嵌入式工作的IDE。

IAR Embedded Workbench

一般来说，IAR嵌入式工作台与Keil uVision有非常相似的功能集。主要的区别是，IAR没有纳入模块化软件包的高级能力。先进的调试功能在IAR中相对于uVision更容易获得和直观一些。代码编辑器同样令人失望。

下面是IAR嵌入式工作平台的快速统计：

现在我们已经涵盖了老牌的产品，我们将进入最近的产品，首先是Rowley CrossWorks。

罗利CrossWorks

Rowley Crossworks是一个比Keil和IAR价格略低的入门级产品。中间件是与IDE分开授权的。FreeRTOS意识到的基于任务的调试在IDE中是不可用的；相反，对CrossWorks任务库（CTL）RTOS解决方案的支持是可用的。

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

接下来是一个由以调试硬件闻名的公司创建的IDE： SEGGER Embedded Studio。

SEGGER Embedded Studio

SEGGER--我们将要使用的调试探头的制造商--也提供许多软件产品，包括他们自己的IDE（和RTOS）。它可以免费用于非商业用途，没有任何限制。他们也有一个完整的中间件堆栈，与IDE分开授权。FreeRTOS意识到的调试可以直接在IDE中使用，并有适当的插件。

以下是Embedded Studio的快速统计数据：

SysProgs Visual GDB

Visual GDB实际上并不是一个IDE。它是Microsoft Visual Studio和Visual Studio Code的插件。它已经存在了相当长的一段时间（从2012年开始）。Visual GDB的主要目的是提供一致的UI（Visual Studio）来与支持GDB的调试器和GNU make工具进行交互。它的主要目标用户是那些熟悉Visual Studio开发环境并希望在其嵌入式工作中继续使用该环境的程序员。

下面是Visual GDB的快速统计：

Visual GDB提供了与图形化配置工具--STM Cub--以及Arduino项目的集成，所以从不同的开发框架迁移可能会更容易一些。

选择本书中使用的IDE

现在我们已经对几个不同的IDE进行了分类，是时候考虑哪一个将被用于本书剩余部分所涉及的示例代码了。为了保持低成本的主题，以减少进入的门槛，我们将把重点放在不需要任何金钱投资的IDE上--任何可供非专业人员免费使用的东西（没有时间或代码限制）都可以考虑。这就立即排除了Keil uVision、IAR Embedded Workbench和SysProgs Visual GDB。Keil有免费版本，代码限制在32KB，但我们可能很快就用完了，这取决于我们选择在例子中包含多少中间件。

由于本书有很大一部分内容涉及用J-Link探针进行调试，我们希望有一持J-Link或GDB的IDE。在完美的世界里，IDE也会支持任务感知的FreeRTOS调试，实时变量观察，等等。正如我们将在下一章看到的那样，FreeRTOS内核感知调试并不是什么大问题，因为SEGGER Ozone包括这种能力。

最后，集成开发环境应该是多平台的，以促进任何有胆量的人的采用。鉴于这一系列标准，我们只剩下有限的选择，如图所示：

那么，我们可以从这个表格和前面的观察中得出哪些要点呢？

• Eclipse CDT是潜在的候选方案，但由于与其他一些解决方案相比需要额外的设置，所以它略显不理想。
• VS Code是可扩展的代码编辑器（开箱即用），与Eclipse类似。将需要额外的插件。
• STM32But IDE承诺提供专业级的调试能力和多任务RTOS感知调试。
• SEGGER Embedded Studio承诺提供与STM32CubeIDE非常相似的功能集。
  我们将使用STM32CubeIDE进行代码示例。由于STM32CubeIDE也包含了STM32系列MCU的代码生成器，让我们来看看使用代码生成工具的一些优势，以及要做的权衡。

考虑STM32Cube

STM32CubeIDE是两个组件的合并--IDE和STMCubeMX图形化配置和代码生成工具，用于STM32 MCU。CubeMX组件可以在开发周期的几个不同点上发挥作用。让我们来谈谈开发周期的相关阶段，确定CubeMX如何帮助，以及如何权衡。

器件选择

大多数现代MCU可以选择将外设映射到几个不同的引脚。然而，每个引脚通常在几个不同的外设之间共享。因此，在引脚受限的设备上，有可能出现所需的外设可用（存在于MCU上）但无法访问（能够被映射到一个物理引脚）的情况。硬件设计人员可以快速评估STM32 MCU的各个型号是否能突破特定应用所需的外设组合。能够快速、准确地在多个芯片上进行这些评估，可以大大节省时间。通常情况下，设计者在做出这样的决定之前，需要对每个芯片的数据手册进行密切的了解。CubeMX绝对不能替代适当的尽职调查，但它确实有助于快速缩小潜在器件的范围。

STM32 MCU上的每个外设都可以单独关闭，这可以节省电力。随着目前电池供电（和能量收集）的物联网设备的激增，尽量减少功耗是热门话题。另一种降低功耗的方法是以较低的频率为芯片计时。CubeMX允许工程师快速计算出芯片在特定配置下的耗电量。在为一个项目调查潜在的MCU时，速度和准确性都很重要。通过在CubeMX中输入外设/时钟配置来获得准确的功耗估算，比浏览数据手册和从头开始创建电子表格要快得多。

硬件启动

硬件启动是指首先启动定制设计的硬件并对其进行某种程度的验证。与开发/评估板相比，定制硬件通常有许多不同之处（毕竟是定制的！）。一个可能不同的领域是时钟硬件。STM32的时钟树是相当复杂的--单一的时钟源为许多不同的子系统供电。时钟频率会被乘法器和除法器沿途修改。CubeMX包含图形化向导，帮助正确配置STM32时钟树，并生成初始化代码，使芯片快速启动和运行。

还需要早期的固件工作来验证硬件的运行。仔细检查MCU是否可以被配置为访问电路板上所有需要的片外电路，这始终是好主意。通常情况下，快速评估硬件的可行性符合每个人的最佳利益，而不是等到固件的所有方面都完全成熟。

当需要利用STM32 MCU上的复杂外设时，CubeMX可以用来快速设置从内部外设到MCU外部引脚的引脚映射。它还包含简单的、菜单驱动的界面，用于选择外设的配置方式。初始化代码会自动生成，它使用STM的硬件抽象层（HAL）驱动程序。相关的外设中断也是为用户配置和存根的。这使得嵌入式工程师能够尽快地通过验证。

在所有的硬件被验证后，将是添加额外的固件层（中间件）的时候了，这些固件将生活在低级别的驱动程序和应用固件之间。

中间件设置

STM多年来与许多不同的中间件供应商合作，使他们的客户能够更直接地引入额外的功能。例如，FreeRTOS原件可以通过CubeMX的几个下拉菜单来选择。FAT文件系统可以被设置，还有TCP/IP协议栈、JPEG图像库和Mbed TLS。不要搞错了，这个工具不会像一个精通的程序员那样进行高级配置，但作为一个最低限度，它为评估不熟悉的库提供了一个坚实的开始。一些工程师可能会发现最初的配置直接符合他们的要求，这意味着有更多的时间来关注他们解决方案的其他部分。

所以，现在我们已经选择了一个设备，验证了硬件，并建立了一些中间件堆栈，现在一定是时候继续对最终的应用程序进行编码了！嗯......不完全是。使用所有这些提供的代码会有一些问题，让我们来看看。

中代码生成的权衡

虽然所有这些功能在理论上听起来很不可思议，但开发人员对CubeMX及其在现实世界中的应用有不同的感受。这些担忧和权衡大多涉及该工具如何融入工作流程；其他时候，挑战来自于可用性问题。

从可用性的角度来看，CubeMX通常工作得很好；其他时候，它生成的无效代码根本无法按预期工作。这似乎是它刚发布时的问题。偶尔会有一些版本会产生一些甚至无法编译的项目。然而，作为一低限度，它一直为较新的STM32设备上的高级外设的配置提供一个很好的参考点。

工程师们在将CubeMX集成到他们的工作流程中时，所面临的挑战是任何生成与用户代码紧密耦合的代码的实用程序的典型。最初，该工具可以用来创建一个大型的代码库，可以快速站起来，并提供所需功能的很大一部分。然而，随着项目的进展，调整几乎是不可避免的；保持定制的用户代码与自动生成的CubeMX代码分开可能会变得很麻烦。你可能会发现自己处于一个复制-粘贴的循环中，不断地将工作代码从一个外围复制到另一个。这是一种在我们行业中泛滥的做法。嵌入式固件工程师亟需打破复制粘贴的无限循环。第12章 "创建良好抽象架构的技巧 "涵盖了在采用这些类型的工作流程时要做哪些权衡。它也有一些关于如何设置你的代码库以实现长期增长而不是腐烂的建议。

综上所述，我们的例子中使用的部分代码将使用STMCubeMX生成的代码作为起点来实现。STM32 HAL在业界被广泛使用，所以任何曾经对STM32进行过编程的人都可能对它很熟悉。请记住，本书中的示例代码是为了让人容易掌握。它旨在强调如何实现RTOS的概念，而不是作为未来添加的可扩展的基础。使用接近STM32 CubeMX生成的代码的主要意图是使你更容易开始自己的实验。

设置IDE

STM32CubeIDE需要安装，并且需要导入源码库，以便编译和运行下面几章的示例代码。

安装STM32CubeIDE

要安装STM32CubeIDE，请遵循以下两个简单的步骤：

• 从https://www.st.com/en/development-tools/stm32cubeide.html 下载STM32CubeIDE。
• 使用默认选项安装它。

现在STM32CubeIDE已经安装完毕，我们需要导入源代码树。让我们看看如何做到这一点。

将源码树导入到STM32CubeIDE中

安装完STM32CubeIDE后，你需要把源码树导入到Eclipse工作区。工作区是Eclipse的术语，是相关项目的集合：

由于STM32CubeIDE是基于Eclipse IDE的，如果你过去使用过Eclipse，你会发现下面的说明很熟悉。

• 从https://github.com/PacktPublishing/Hands-On-RTOS-with-Microcontrollers，下载或克隆GitHub的存储库：

• 最好的做法是保持库的路径简短，没有空格；也就是说，c:\projects。

• 示例中使用的基本git路径是c:\projects\packBookRTOS。

• 打开STM32CubeIDE。

  • 导入整个Repo：
  • 转到菜单： 文件｜导入。
  • 选择General | Existing Projects Into Workspace | Next。浏览并选择包含repo的文件夹，（c:\projects\packBookRTOS），选择后应该与下面类似：
  • 点击完成。下一步 "按钮总是灰色的。
    

• 此时，项目资源管理器面板将显示所有导入的章节（下面的截图只显示第5章 "选择IDE "和第6章 "实时系统的调试工具 "的代码，因为它们是目前唯一编写的例子）：

• 为了确保一切安装正确，右击Chapter5_6并选择Build。控制台窗口中的输出应该类似于下面：

祝贺你！你现在应该可以构建Chapter5_6了！你现在应该可以构建本书所包含的FreeRTOS实例项目了!

你可能已经注意到，Eclipse项目所包含的文件夹与磁盘上的组织方式并不完全相同（也就是说，Drivers和Middleware并不是文件系统中Chapter5_6的子文件夹）。这样做的目的是为了允许跨项目/章节重复使用共同的代码。这个概念将在第12章 "创建良好抽象架构的技巧 "中更深入地阐述。
文章来源地址https://www.toymoban.com/news/detail-482596.html

到了这里，关于微控制器实时操作系统实践5选择IDE的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！