1

概述：本节描述了我们的工作流程。

  • IDE：STM32CubeIDE
  • 版本控制：git

在 git 中，我们跟踪：以及我们的 Src 的其他文件夹

  • .c项目
  • 。项目
  • 调试.cfg
  • 调试启动
  • 我的项目.ioc
  • STM32H743ZITX_FLASH.ld
  • STM32H743ZITX_RAM.ld
  • 核心（文件夹）

使用 CubeIDE 和 git，我们能够成功克隆、生成 .ioc 并成功构建我们的项目。生成正确地引入了 Drivers 文件夹，并生成了核心内容。这也使对 .cproject 的任何手动更改保持不变。我们更喜欢遵循 ​​git 工作流程来不跟踪生成的文件，因为它们可以很好地生成。

问题：

1：我们需要在我们的软件中进行多种配置，以支持我们拥有的硬件的各种版本/需求。这样，我们就有了一个代码库，用于我们拥有的产品的多个类似软件/硬件版本。这将包括使用#define 或类似标签在构建中包含/删除的软件功能，以支持不同的产品功能/执行。在我看来，这似乎相当简单。

2：变得更加困难的部分是处理 .ioc/project 差异和生成。某些版本可能不使用我们正在使用的外围设备的完整列表，我们希望禁用这些外围设备生成/构建项目。

3：在尝试解决这个问题时，我想到了持续集成 (CI)，比如 Jenkins 之类的工具。这将使我们能够自动化多个构建，以确认一个项目的更改确实会破坏另一个项目。有没有人成功使用 Jenkins 的 STM32CubeIDE 工具链？我发现了一些关于该主题的帖子寻求帮助，但几乎没有任何有用的结果。更多信息会有所帮助。

注意：我尝试了 CubeMX 命令行生成（ST 文档 UM1718 V31 Dec19），但发现项目生成命令会覆盖 .cproject 手动设置，IDE 在我们当前的设置中没有这样做。

4：我们正在寻找有关如何修改我们的工作流程、git repo 或工具链的意见，以更好地实现这一目标。

潜在的解决方案：

A：使用当前 git repo 跟踪文件生成构建所需的代码，使用构建选项配置软件选项。 优点：

  • 在 IDE 中工作

缺点：

  • 如果不重写我们所做的手动 .cproject 更改，我们无法让 CubeMx cli 正常工作，因此 Jenkins 不容易实现。

  • 不支持基于产品版本的 .ioc 配置（至少据我所知）

B：使用当前的 git repo 跟踪文件，但包括一个公共源文件夹和一个项目文件夹，其中每个版本的产品都有单独的项目文件夹。

优点：

  • 应该与IDE一起使用
  • 允许多个 .ioc 配置能够从不使用它的产品中删除某些外围设备。

缺点：

  • 跟踪项目和版本的 git 复杂性更高。
  • 构建仍然是手动的（无 CI/Jenkins），因此常见的源更改需要用户手动构建多个项目以确认稳定性。
  • 如果不重写我们所做的手动 .cproject 更改，我们无法让 CubeMx cli 正常工作，因此 Jenkins 不容易实现。

关于工作流/工具链限制和改进或其他工作流/工具链的建议会有所帮助。

4

0 回答 0