EEPW论坛

介绍

STMCube™是意法半导体的一项原始计划，旨在通过以下方式使开发人员的生活更轻松。减少开发工作量，时间和成本。 STM32Cube涵盖了整个STM32产品组合。 STM32Cube包括：

• STM32CubeMX，一种图形软件配置工具，允许生成 使用图形向导的C初始化代码。

• 每个STM32微控制器都提供全面的STM32Cube MCU软件包 系列（例如STM32F4系列的STM32CubeF4），具有：
  

• STM32Cube HAL，一种STM32抽象层嵌入式软件，可确保 最大化STM32产品组合的可移植性。 HAL适用于所有外围设备
  

• 底层API（LL）提供了快速轻量的面向专家的层，该层是 比HAL更接近硬件。 LL API仅适用于一组外设。

• 一套一致的中间件组件，例如RTOS，USB，TCP / IP和 图形

• 所有嵌入式软件实用程序，随附全套示例

此外，STM32Cube扩展软件包包含嵌入式软件组件，这些组件补充了STM32Cube MCU软件包的功能，或者使能够在各种应用领域中使用大量ST器件以及最合适的STM32微控制器，或者同时使用这两者。 本文档介绍了STM32Cube扩展软件包开发的兼容性要求，该兼容性要求确保与STM32Cube MCU软件包和工具的正确匹配，以及STM32Cube生态系统内的总体一致性，从而能够基于经过验证的软件元素快速进行应用程序开发。 本文档的读者必须熟悉STM32Cube架构，HAL和LL API以及编程模型。完整的文档集可从http://www.st.com上的STM32Cube MCU软件包页面获得。

1. 总体信息

STM32Cube MCU软件包和STM32Cube扩展软件包在基于Arm®Cortex®-M处理器的STM32 32位微控制器上运行。

2. 参考和首字母缩写词

http://www.st.com上的以下文档同时用于STM32Cube扩展包的开发： 1. STM32Cube扩展包（UM2312）的开发清单 表1列出了与更好地理解本文档有关的首字母缩写词的定义。

3. STM32Cube MCU软件包和STM32Cube扩展软件包

STM32Cube解决方案由工具部分STM32CubeMX和STM32Cube MCU软件包组成，后者提供了受益于STM32微控制器功能的软件模块。 除了STM32CubeMX和STM32Cube MCU软件包之外，STM32Cube扩展软件包还通过补充插件丰富了整个STM32Cube生态系统。

3.1 STM32Cube MCU软件包

STM32Cube MCU软件包（例如STM32F4系列中用于微控制器的STM32CubeF4）提供了使用STM32微控制器硬件功能所需的所有必要软件模块。 STM32Cube MCU软件包主要包含：

• STM32外设驱动程序

– HAL（硬件抽象层） – LL（低级API）

• 涵盖STM32外设的中间件

– RTOS，TCP / IP，TLS / SSL，USB，图形，文件系统，JPEG等

• STM32开发板的外部组件驱动程序（BSP）

–评估板 –发现套件 –核心板

• 丰富的示例集旨在展示STM32硬件以及相关的嵌入式软件功能和用法

STM32Cube嵌入式软件以Mix Liberty + OSS +第三方V1混合许可模式分发，如http://www.st.com所述。

图2展示了STMicroelectronics分发，维护和支持的STM32Cube MCU软件包的顶层结构。

3.2 STM32Cube扩展软件包

STM32Cube扩展软件包包含用于补充STM32Cube MCU软件包功能的附加软件组件，用于：

• ·新的中间件堆栈

• ·新的硬件和电路板支持（BSP）

• ·新实例

• ·上面的几个项目扩展包分为两类：一些STM32Cube扩展包由意法半导体开发，维护和支持，而另一些则由不属于意法半导体的第三方开发，维护和分发。

4. 包装要求

STM32Cube MCU软件包是任何STM32Cube扩展软件包的基础。 因此，应始终组织文件夹和文件结构，而不修改原始文件夹结构，如第9页上的图3所示。 STM32Cube扩展包开发清单文件[1]中提供了STM32Cube扩展包内容的详细要求。

4.1 使用STM32CubeMX开发示例

在STM32Cube扩展包中，应使用STM32CubeMX工具开发示例。此要求意味着开发满足以下规则：

• ·STM32CubeMX工具应用于配置STM32器件和开发板，并生成相应的初始化代码

• ·在生成的 .h和 .c源文件中，用户应在/ * USER CODE BEGIN * /和/ * USER CODE END * /标记所限制的部分内添加应用代码

• ·关联的*。 ioc文件应在示例根目录下可用

• 如果使用其他STM32CubeMX项目设置，则。 extSettings文件应与保持同一级别。 ioc文件的位置和命名约定。 ioc在图3中进行了描述。

4.2 STM32Cube MCU软件包驱动程序和中间件的扩展

在某些特定情况下，可能会需要STM32Cube扩展软件包的开发人员更新STM32Cube MCU软件包中提供的本机驱动程序（HAL / LL，CMSIS和BSP）或中间件（例如，用于扩展已实现的功能，在正式ST版本之前及早修复错误或其他）。 在这种情况下，用户应按以下步骤进行： 1. 在ApplicationN Name存储库下，创建一个文件夹\ Extension，将要修补的文件复制到该文件夹中。 此复制操作必须遵守文件夹层次结构。如果保留默认文件夹层次结构会导致长路径问题，则无论如何都可以减少子文件夹的数量。 2. 通过附加_patch后缀来重命名要修补的文件。 3. 在项目中使用修补的文件而不是原始文件。

图4提供了一个示例，其中以红色概述的文件是自定义的，以实现USB设备音频流应用程序所需的特定功能，而STM32Cube MCU软件包本身不支持这些功能。

5. 新的中间件集成5.1 要求

中间件组件是位于STM32硬件和用户应用程序之间的固件层。基本上，任何新的中间件组件都必须符合以下要求：

• ·必须实现模块化体系结构，将复杂性分解为更简单的块或文件。

• ·必须独立于硬件（设备和板）。

• ·与硬件驱动程序和其他中间件堆栈的连接应通过接口文件进行。

• ·接口文件应作为模板提供在中间件文件夹中，以供用户自定义。

5.2 组织

中间件组件通常由以下组成：

• ·模块：模块是通用功能子层，可以单独添加或删除。例如，TCP / IP堆栈由TCP / IP核心以及DHCP，HTTP和FTP组件组成。每个组件都被视为一个模块。可以通过启用或禁用它的配置文件中的特定定义/宏来添加或删除它。

• ·核心：这是组件的内核；它管理主库状态机，并管理各个模块之间的数据流。

• ·接口层：接口层通常用于将中间件核心组件与较低的层（例如HAL，LL和BSP驱动程序）链接。

根据中间件组件的不同，接口层可以属于以下类别之一：

• ·与CPU的接口仅取决于所用的STM32内核

• ·与HAL，LL和BSP驱动程序的接口

与CPU的接口仅取决于所使用的STM32内核：在这种情况下，接口文件应位于Middlewares目录中，并由使用同一内核的所有应用程序使用。 FreeRTOS可以作为示例，因为它为每个ARM Core（例如Cortex @ -M3，Cortex @ -M4或其他）和每个编译器提供了移植文件，因为需要一些汇编代码来处理上下文切换和寄存器。保存和还原机制。 接口文件在中间件结构中的位置如图6所示。

与HAL，LL和BSP驱动程序的接口：在某些中间件组件中，该接口是一组空的或几乎空的功能，用户需要填充这些功能才能将其与HAL和LL层链接。通常，接口文件与中间件组件一起作为模板文件提供。必须在应用程序层中复制和自定义它们。

接口文件在中间件结构中的位置如图7所示。

每个子文件夹必须包含一个Inc文件夹和一个\ Src文件夹，分别位于头文件（“ .h）和源文件（” .c）的位置。

如果中间件组件很简单；子文件夹\ Core，Modules和\ Porting可以删除；然后，仅应在中间件组件根级别提供Inc和\ Src子文件夹。

5.3 以对象格式交付

当中间件库以二进制或对象格式交付时，它必须符合一组最低要求：

• ·应提供头文件以将库接口API导出到最终应用程序

• ·应提供发行说明

• ·所有支持的编译器均应以对象格式提供库。如果库对象是编译器相关的，则必须在对象文件名中明确指出支持的编译器。

例如，LibraryNameV_CMx_C_O.a是一个库对象文件名，其中： - V：模块版本（例如，对于V0.1版本，V = 01） - x：CMx核心类（CM0，CM3，CM4，CM7，CM23，CM33） - C：编译器（IARTM，Keil？，GCC） - O：指定编译器优化 - < empty >：高尺寸优化 - Ot：高速优化 - Ontsc：无大小限制的高速优化 - Ob：高平衡优化

6. 软件质量要求

在STM32Cube扩展包（与STM32Cube MCU包相关的附加组件）中开发的BSP驱动程序，中间件和项目必须满足以下最低要求：

• ·确保在Windows和Linux平台上使用所有受支持的编译器（EWARM，MDK-ARM和SW4STM32）进行编译，而不会出现错误或警告

（仅当扩展组件的开发者不拥有的SW组件上存在警告时，才接受警告）。

• ·执行功能测试时不会遗留任何已知的错误（如果在组件发行说明中有记录，则可接受次要错误），并提供证据报告。

BSP驱动程序和中间件必须符合以下附加要求：

• ·符合MISRAC®标准和静态代码分析，并提供证据报告

• ·MISRAC®不合规规则偏差应合理。

来源：网络版权归原作者所有，如有侵权，请联系删除。