企业官网建设流程全解析

【嵌入式软件AI编程】（1）面向 AI 协同开发的硬件设计资源分析
【嵌入式软件AI编程】（2）使用 altium-monkey-mcp 提取硬件设计信息
【嵌入式软件AI编程】（3）面向 AI 协同开发的 STM32 硬件信息标准化
【嵌入式软件AI编程】（4）提取 STM32 硬件信息工作流的建立与使用

1. 引言

在 STM32 嵌入式软件开发中，从原理图、PCB 设计文件和开发板用户手册等原始硬件资料中提取的信息，通常还不能直接满足 AI 协同开发的需要。MCU 引脚映射、板载硬件资源、外设接口及器件连接关系等信息，需要经过进一步整理、规范化和结构化组织，才能形成便于 AI 理解、检索和使用的硬件信息资源。

本文在前文硬件设计资源分析和 Altium 设计信息提取工作的基础上，重点研究 STM32 硬件信息的标准化方法，设计统一的数据结构，并采用 Markdown（.md）和 JSON（.json）等格式组织和保存硬件信息，形成由核心硬件上下文和完整硬件参考数据组成的两级文件体系。同时，以 NUCLEO-G431RB 开发板为实例，介绍从硬件事实整理、文件生成到数据关联与一致性检查的具体过程，为 AI 在 STM32 项目需求整理、初始工程分析、任务规划和代码实现等不同开发阶段提供准确、规范、可复用的硬件信息支持。

2. 硬件信息标准化的总体设计

2.1 设计目标与总体结构

设计目标
硬件信息标准化的目标，是将从原始硬件设计资料中提取的分散信息，整理为结构统一、内容准确、便于检索和复用的硬件信息资源。通过统一数据结构和组织方式，规范表达 MCU 引脚映射、板载硬件资源及器件连接关系，减少不同开发板硬件信息描述方式的差异。

标准化后的硬件信息应能够适应 AI 协同开发的不同阶段，既能提供简明、直观的核心硬件上下文，也能支持对完整硬件连接信息的按需查询，为项目需求整理、初始工程分析、任务规划和代码实现提供可靠的硬件依据。

总体结构

标准化硬件信息由**核心硬件上下文（Hardware Context）和参考硬件网表（Hardware Netlist）**两部分组成。

1. 核心硬件上下文：
   核心硬件上下文作为默认读取的硬件信息入口，提供开发过程中常用的硬件信息。
   采用精简、易读的方式组织，主要包括开发板及 MCU 信息、MCU 引脚映射、板载硬件资源、接口功能及必要的硬件使用条件等，供 AI 在项目需求整理、初始工程分析、任务规划和代码实现等阶段使用。

2. 参考硬件网表：
   参考硬件网表作为补充查询依据，保存完整的硬件连接数据，在核心上下文信息不足或需要进一步查询时按需读取。
   保存从 Altium 设计资料中提取的完整硬件连接数据，主要包括元器件信息、网络及其连接端点、MCU 引脚反向索引等，供 AI 查询具体器件属性、网络连接及完整引脚连接关系。

两部分相互关联、各有侧重，共同构成兼顾信息可读性、完整性和查询效率的标准化硬件信息体系。

2.2 数据结构设计

介绍标准化硬件信息的数据结构设计，分别说明 MCU 引脚映射信息、板载硬件资源信息和完整硬件连接信息的组织方式，定义各类数据的字段及其用途，明确不同数据之间的关联关系。

2.2.1 MCU 引脚映射表

MCU 引脚映射信息用于描述开发板 MCU 引脚与板级硬件资源之间的连接关系，是 AI 识别 GPIO、外设信号及其硬件用途的基础。采用表格形式组织，每条记录对应一个 MCU 引脚，主要包含以下字段：

其中，Pin、Net和Connection描述 MCU 引脚的物理标识及连接关系，Board Function描述引脚在开发板上的用途，Condition补充连接关系之外的硬件使用条件，Status则用于标识信息的确认情况。

例如，NUCLEO-G431RB 的 PA5 引脚用于控制板载绿色用户 LED，其记录如下：

通过上述结构，可以将 MCU 引脚标识、网络连接、板级用途和硬件使用条件集中组织，既保留必要的连接事实，也为 AI 理解引脚的实际用途提供依据。

需要说明的是，核心硬件上下文仅收录开发过程中需要重点关注的 MCU 引脚。未列出的引脚不代表其不存在或可以直接使用；需要查询其他引脚及其完整连接关系时，可进一步查阅参考硬件网表。

2.2.2 板载硬件资源表

板载硬件资源信息用于描述开发板上的按键、LED、晶振、调试接口及通信接口等硬件资源，以及这些资源与 MCU 引脚之间的关联关系。与 MCU 引脚映射表侧重引脚连接不同，硬件资源表以板载资源为组织对象，描述其功能、组成器件、接口类型及使用条件。

采用表格形式组织，每条记录对应一个硬件资源，主要包含以下字段：

对于由多个器件组成的硬件资源，Connection用于记录其主要组成器件，MCU Pins则建立资源与 MCU 引脚映射表之间的关联。两者相互补充，避免仅通过单个 MCU 引脚描述复杂的板载硬件资源。

例如，NUCLEO-G431RB 的用户按键 B1 具有 PC13 和 PA0 两条可选输入路径，其资源记录如下：

通过硬件资源表，可以从资源功能出发，快速了解其关联的 MCU 引脚、组成器件及必要的使用条件。表一与表二通过MCU Pins字段建立关联，使 AI 既能够从 MCU 引脚查找对应的硬件连接，也能够从板载资源了解其涉及的 MCU 引脚及相关硬件条件。

2.2.3 硬件连接信息的数据结构

完整硬件连接信息用于保存从 Altium 设计资料中提取的元器件属性和网络连接关系，为核心硬件上下文提供完整的参考数据。采用 JSON 格式组织，按照统一的数据规范，将信息划分为metadata、components、nets和mcu_pin_index四个部分。

1. metadata：元信息
   记录开发板及硬件设计的基本信息，包括开发板标识、实际目标 MCU、原理图设计基准 MCU、目标 MCU 对应的元器件位号、数据规范版本及原始网表来源等，用于说明参考数据的适用对象和来源。

2. components：元器件信息
   以元器件位号为键，记录原理图中各元器件的基本属性，包括器件类型（type）、器件值（value）、封装（footprint）和来源页（source_page）。通过该部分可以根据器件位号查询元器件的基本信息及其原始设计来源。

3. nets：网络连接信息
   以原始网络名称为键，记录每条网络的全部连接端点（endpoints）及其来源页（source_pages）。连接端点采用统一格式：目标 MCU 引脚使用完整的物理引脚编号和引脚名称，其他器件引脚采用“器件位号.引脚号”的形式。该部分保留完整的网络连接事实，可用于查询某一网络涉及的全部器件及连接关系。

4. mcu_pin_index：MCU 引脚反向索引
   以 MCU 完整引脚值为键，为每个已连接的目标 MCU 引脚建立索引记录，包含引脚值（pin）、所属网络（net）及该网络的全部连接端点（endpoints）。该部分由网络连接数据生成，用于根据 MCU 引脚快速查询其所属网络及完整连接关系。

四个部分各有侧重：metadata提供数据来源和适用对象信息，components保存元器件属性，nets保存完整网络连接，mcu_pin_index则提供面向 MCU 引脚的快速查询入口。其中，mcu_pin_index是由nets派生的索引数据，不改变原始网络连接事实。对于多个 MCU 引脚共用同一网络的情况，每个引脚分别建立索引，并保留相同的完整网络端点列表。

通过上述结构，完整硬件连接信息既保留了原始设计中的器件与网络关系，也提供了面向不同查询需求的数据访问方式，为 AI 按需获取详细硬件连接信息提供支持。

本章从 MCU 引脚映射、板载硬件资源和完整硬件连接三个方面，建立了标准化硬件信息的数据结构，为后续采用 Markdown 和 JSON 格式组织、生成及使用硬件信息文件奠定了基础。

2.3 文件组织与格式设计

介绍标准化硬件信息的文件组织与格式设计，分别说明核心硬件上下文和完整硬件参考数据的文件结构、组织方式及其适用场景。

2.3.1 核心硬件上下文（hardware_context.md）

核心硬件上下文文件（hardware_context.md）采用 Markdown 格式保存，作为标准化硬件信息的主要入口，供 AI 在项目需求整理、初始工程分析、任务规划和代码实现等阶段默认读取。文件以开发板为单位组织，采用标题、表格和简要说明相结合的方式，集中描述软件开发所需的关键硬件信息。

核心硬件上下文主要包含以下内容：

1. 元信息：记录开发板型号、实际开发目标 MCU、Altium 原理图设计基准 MCU、参考网表文件及版本等基本信息，明确硬件资料的适用对象和来源。
2. 开发约束与缺失处理规则：说明目标器件、硬件事实的资料依据、连接条件、默认配置及待确认信息的处理要求。
3. MCU 引脚映射表：以 MCU 引脚为组织对象，记录关键引脚的网络名称、板级功能、连接端及必要的硬件使用条件。
4. 板载硬件资源表：以板载硬件资源为组织对象，记录资源功能、关联 MCU 引脚、接口类型、组成器件及使用条件。
5. 参考数据检索指引：说明参考硬件网表的文件位置、数据组织方式和按需查询条件，为获取完整硬件连接信息提供指引。
6. 原始资料索引与待确认事项：保留原始硬件设计资料的索引，并对确实缺少且影响开发的关键信息进行登记。

其中，MCU 引脚映射表和板载硬件资源表构成核心硬件上下文的主体。前者从 MCU 引脚出发描述其板级连接和用途，后者从硬件资源出发建立与 MCU 引脚及外围器件的关联。两张表相互补充，共同提供开发过程中常用的硬件信息。

对于完整器件属性及网络连接等低频查询信息，不在该核心文件中重复展开，而是通过参考网表按需获取。

2.3.2 参考硬件网表（hardware_netlist.json）

完整硬件参考数据保存为参考硬件网表文件（hardware_netlist.json），采用 JSON（.json）格式，按照统一的数据规范组织元器件属性、网络连接及 MCU 引脚索引等信息。参考硬件网表主要用于保存完整的硬件连接事实，支持 AI 根据具体开发任务查询所需的器件和网络信息。

JSON 文件采用统一的顶层结构，包含以下四个部分：

1. metadata：元信息，记录开发板标识、目标 MCU、原理图设计基准 MCU、原始网表来源及数据规范版本等信息。
2. components：元器件信息，以器件位号为键，记录器件类型、器件值、封装和原理图来源页等基本属性。
3. nets：网络连接信息，以原始网络名称为键，记录网络的全部连接端点及其来源页，保留完整的器件连接关系。
4. mcu_pin_index：MCU 引脚反向索引，以完整 MCU 引脚值为键，记录引脚所属网络及该网络的全部连接端点，便于根据 MCU 引脚快速查询相关硬件连接。

其中，components和nets保存主要的硬件设计数据，mcu_pin_index则由网络连接信息生成，作为面向 MCU 引脚的查询索引。对于连接到同一网络的多个 MCU 引脚，分别建立索引记录，并保留相同的完整网络端点列表，以减少查询时的额外检索操作。

采用 JSON 格式可以利用对象、数组和键值对表达元器件、网络及其连接关系，便于程序读取、数据处理和自动化检查。同时，统一的字段定义和数据组织方式也为不同开发工具及 AI 应用提供了通用的数据接口。

参考硬件网表按照统一规范生成，并通过元器件数量、网络数量、连接端点及 MCU 引脚索引等一致性检查，保证数据结构和连接关系的完整性。具体使用时，AI 无需每次读取整个 JSON 文件，而是根据核心硬件上下文提供的检索指引，按需查询相关器件、网络或 MCU 引脚信息。

2.3.3 文件的职责分工与协同使用

**核心硬件上下文（hardware_context.md）和参考硬件网表（hardware_netlist.json）**相互关联、各有侧重，共同构成标准化硬件信息资源。

• 核心硬件上下文（hardware_context.md）：作为默认读取的硬件信息入口，提供开发过程中常用的 MCU 引脚映射、板载硬件资源、接口功能及必要的硬件使用条件，满足 AI 在不同开发阶段对常用硬件信息的获取需求。
• 参考硬件网表（hardware_netlist.json）：作为补充查询依据，保存完整的元器件属性和网络连接关系。当核心硬件上下文未包含任务所需信息，或需要查询具体器件及完整连接关系时，再按需读取。

两类文件通过 MCU 引脚、网络名称和器件位号等信息建立关联。AI 通常优先读取核心硬件上下文（hardware_context.md），仅在必要时查询参考硬件网表（hardware_netlist.json），从而兼顾硬件信息的可读性、完整性和查询效率。
后续章节介绍从原始硬件设计资料到标准化硬件信息文件的完整处理流程。

• 首先核查原始资料，依据统一的数据规范，使用自动化转换程序生成参考硬件网表；
• 随后结合标准化网表、Altium 原理图和开发板用户手册，提取与整理 MCU 引脚映射及板载硬件资源等信息，生成核心硬件上下文；
• 最后对两类文件进行数据关联与一致性检查，确保标准化硬件信息的完整性和准确性。

3. 原始资料核查与标准化输入

硬件信息标准化首先需要核查原始资料，确认开发板型号、硬件设计版本及各类资料的对应关系。以 NUCLEO-G431RB（MB1367）为例，主要使用以下资料。

（1）Altium Designer 原理图工程

• 工程文件：mb1367.PrjPcb
• 工程目录：BoardDesignPack/Altium_Designer/
• 关联设计文件：工程中的.SchDoc原理图文件及.PcbDoc文件。

首先使用 Altium 工程文件识别整个设计项目，并获取其元器件及网络连接信息。具体原理图不要求全部逐一分析，而是根据硬件信息整理任务，按需查阅相关.SchDoc文件，分析 MCU 引脚、外围器件及电路连接关系。本次标准化处理不涉及 PCB 布局信息的提取。

（2）Altium 导出网表

• 原始网表：mb1367_netlist.json

该文件是使用altium-monkey-mcp对 Altium 原生设计文件进行识别和提取后导出的 JSON 网表，详见前文《【嵌入式软件AI编程】使用 altium-monkey-mcp 提取 STM32 硬件设计信息》。

导出的原始网表包含元器件、MCU 引脚及网络连接等信息，是后续参考硬件网表标准化转换的主要输入，但尚未按照本文定义的数据规范完成标准化处理。

（3）ST 官方开发板用户手册

• NUCLEO-G431RB_User_Manual_UM2505.pdf

该手册用于补充开发板的默认配置、焊桥、板载按键、LED 和外部接口等使用信息。

（4）MCU 参考手册

• STM32G4_Reference_Manual_RM0440.pdf

该手册作为可选参考资料，仅在必要时查阅，用于辅助理解 MCU 外设功能、寄存器及相关硬件工作机制，不作为每次硬件信息整理的必读资料。使用时应注意其适用的 MCU 型号和范围，不能将原理图设计基准 MCU 的信息直接套用于实际开发目标 MCU。

完成上述资料收集后，核对 Altium 工程中的开发板标识、硬件版本及设计变体，确认导出网表与原始工程相对应，并确认开发板用户手册适用于当前开发板。完成资料核查后，确定本次硬件信息标准化处理的输入资料。

4. 参考硬件网表（hardware_netlist.json）的自动化生成

本章介绍参考硬件网表规范的制定、转换程序的实现及其使用方法。

4.1 参考硬件网表规范（hardware_netlist_spec_v1.1.md）

为统一不同开发板的硬件连接数据结构，制定参考硬件网表规范hardware_netlist_spec_v1.1.md。该规范定义了标准化 JSON 文件的顶层结构、字段含义、命名规则、数据关联及一致性检查要求，为自动化转换程序提供统一的实现依据。

规范 v1.1 的主要内容如下：

1. 用途与边界2. 顶层结构3. 字段定义3.1`metadata`3.2`components`3.3`nets`3.4`mcu_pin_index`4. 目标 MCU 引脚名称规范化5. 缺失、冲突与一致性检查6. 规范冻结结论

其中，规范明确规定：

• components以原始器件位号为键。
• nets以原始网络名称为键。
• mcu_pin_index以目标 MCU 完整引脚值为键。
• 目标 MCU 引脚端点采用物理编号/引脚名格式，例如19/PA5。
• 其他器件引脚采用器件位号.引脚号格式，例如SB6.1。
• 网络端点必须保留完整连接关系，MCU 引脚自身也必须包含在对应网络的端点列表中。

通过制定统一规范，可以避免不同开发板的网表在字段定义、命名方式和数据组织上出现差异，为后续自动化处理和跨项目复用提供基础。

4.2 开发自动化转换程序（generate_hardware_netlist.py）

在确定 JSON 数据规范后，使用 Python 开发自动化转换程序generate_hardware_netlist.py，将altium-monkey-mcp导出的原始 JSON 网表转换为符合规范的参考硬件网表。

程序主要完成以下工作：

1. 元器件信息整理：提取原始网表中的全部元器件，以器件位号为键，记录器件类型、器件值、封装及原理图来源页等属性。
2. 网络连接整理：提取全部网络及其连接端点，按照规范统一 MCU 引脚和其他器件引脚的表示方式，并对端点去重、排序。
3. MCU 引脚索引生成：根据网络连接数据，自动生成目标 MCU 的引脚反向索引，记录每个 MCU 引脚所属网络及该网络的完整连接端点。
4. 数据一致性检查：检查器件位号、网络名称、连接端点及 MCU 引脚索引之间的关联关系，识别结构性错误和数据缺失。

对于重复网络名称、无法解析的连接端点及索引矛盾等结构性错误，停止生成并报告异常；对于器件属性或来源页缺失等情况，则按照规范保留null或空数组，并在检查报告中记录。

程序最终生成两个文件：

• 标准化参考硬件网表：hardware_netlist.json。
• 网表生成与校验报告：hardware_netlist_validation.md。

4.3 使用转换程序生成标准化参考硬件网表

以 NUCLEO-G431RB（MB1367）为例，使用上述转换程序生成标准化参考硬件网表。

1. 准备输入文件
   将以下两个文件放在同一工作目录中：

hardware_netlist/ ├── mb1367_netlist.json └── generate_hardware_netlist.py

其中，mb1367_netlist.json 是通过 altium-monkey-mcp 导出的原始 JSON 网表。详见《【嵌入式软件AI编程】使用 altium-monkey-mcp 提取 STM32 硬件设计信息》。

2. 运行转换程序
   在 Windows 环境下，使用 VS Code 打开上述工作目录，启动集成终端。

首先检查 Python 环境：

python--version

转换程序使用 Python 标准库，无需安装额外的第三方依赖。

可以通过以下命令查看程序支持的参数：

python .\generate_hardware_netlist.py--help

针对 MB1367，执行以下命令：

python .\generate_hardware_netlist.py`--input.\mb1367_netlist.json`--output.\g431rb_hardware_netlist.json`--report.\g431rb_hardware_netlist_validation.md`--board-name mb1367`--target-mcu STM32G431RBT6`--design-mcu STM32G474RET6 ` --mcu-component U13

其中，主要参数的含义如下：

3. 检查生成结果

程序执行成功后，在工作目录中生成两个文件：

hardware_netlist/ ├── mb1367_netlist.json ├── generate_hardware_netlist.py ├── mb1367_hardware_netlist.json └── mb1367_hardware_netlist_validation.md

其中：

• mb1367_hardware_netlist.json：标准化参考硬件网表。
• mb1367_hardware_netlist_validation.md：网表生成与校验报告，记录数据统计、属性缺失、多 MCU 引脚共网情况及一致性检查结果。

程序同时在终端输出转换统计信息。本次 NUCLEO-G431RB（MB1367）的实际转换结果如下：

对于器件属性或来源页缺失的情况，程序按照规范保留相应的空值，并在校验报告中记录；对于重复器件位号、无效网络端点、MCU 引脚归属冲突等结构性错误，程序会报告异常并终止转换。

检查通过后，将生成的mb1367_hardware_netlist.json统一命名为g431rb_hardware_netlist.json，保存至：C:\AI4MCU-STM32-Codex\hardware\nucleo-g431rb\。

通过上述操作，即可将 Altium 导出的原始 JSON 网表转换为符合统一数据规范的参考硬件网表。对于其他 STM32 开发板，可以复用相同的规范和转换程序，根据实际工程调整输入文件、开发板标识及 MCU 相关参数。

5. 生成核心硬件上下文（hardware_context.md）

在生成核心硬件上下文之前，首先需要整理 MCU 引脚映射和板载硬件资源等关键信息，形成结构化的硬件事实记录。在此基础上，通过 Codex 对话生成核心硬件上下文初稿，并经过多轮审阅与修订，最终形成正式版本。

5.1 硬件事实整理记录

在生成核心硬件上下文之前，首先对前期提取的 Altium 硬件设计信息进行整理，形成硬件事实整理记录文件g431rb_hardware_facts.md，作为后续核心硬件上下文生成的中间资料。

本阶段主要使用以下资料：

1. Altium 原始网表：mb1367_netlist.json，包含元器件属性、网络名称及完整连接端点。
2. MCU 引脚查询结果：通过 altium-monkey-mcp 的 get_component 查询 U13 获得的64个引脚及其网络连接信息，相关操作和返回结果记录于 TEST_altium-monkey-mcp.txt。
3. 开发板用户手册：NUCLEO-G431RB_User_Manual_UM2505.pdf，用于补充板载资源功能、默认配置及硬件使用条件。

硬件事实整理通过与 AI 助手多轮对话完成，主要包括 整理 MCU 引脚映射表 和 整理板载硬件资源表 两个方面。指令索引如下：

上述指令通过多轮对话逐步执行，并根据开发者反馈调整整理结果，最终形成包括MCU 引脚映射表和板载硬件资源表的g431rb_hardware_facts.md。该文件作为核心硬件上下文生成的中间成果，为后续 Codex 对话提供了结构化的硬件事实输入。

1. ** MCU 引脚映射表**
   以 MCU 引脚为索引，从已提取的引脚和网络连接记录中筛选与开发板关键硬件资源相关的引脚，整理其物理引脚编号、引脚名称、网络名称、板级功能及连接端等信息。
   本次从 U13 的引脚记录中选取 16 条关键记录，形成 MCU 引脚映射表。对于按键、LED、晶振、调试接口及通信接口等相关引脚，分别整理其连接关系和必要的硬件使用条件。

2. 板载硬件资源表
   以板载硬件资源为对象，根据已提取的元器件及网络连接记录，将相关器件归纳为独立资源，整理其功能、关联 MCU 引脚、接口类型和组成器件等信息。
   本次共整理 9 项关键硬件资源，包括用户按键 B1、MCU 复位 B2、用户 LED LD2、晶振 X2 和 X3，以及 SWD、SWO、VCP_UART 和 BOOT_CONFIG 等资源。

5.2 通过 Codex 对话生成核心硬件上下文

完成硬件事实整理后，将相关文件提供给 Codex，利用自然语言对话生成核心硬件上下文初稿。与直接从原始网表生成文档不同，本方法以已经整理的硬件事实为主要输入，并结合标准化参考网表和开发板资料，逐步明确文档内容及组织方式。

（1）准备输入资料

将以下文件准备在 Codex 可以访问的工作目录中：

其中，g431rb_hardware_facts.md提供已经整理的核心硬件事实，参考硬件网表用于补充完整连接信息，两者共同构成核心硬件上下文生成的主要数据基础。

（2）提出核心文件生成任务

在 Codex 对话中，首先明确开发板型号、目标 MCU 和文件生成任务，要求根据提供的硬件资料生成核心硬件上下文文件。

对话中主要明确以下要求：

• 以 NUCLEO-G431RB 为目标开发板，实际软件开发目标 MCU 为 STM32G431RBT6。
• 以硬件事实整理记录中的 MCU 引脚映射表和板载硬件资源表为基础。
• 保留已经确定的硬件事实和字段定义，不随意改变连接关系。
• 将完整硬件参考数据保存在独立的 JSON 文件中，核心上下文不重复收录全部元器件和网络信息。
• 采用 Markdown 格式组织文档，使其便于开发者阅读和 AI 在不同开发阶段使用。

（3）通过多轮对话完善文档内容

在 Codex 生成初步内容后，通过后续对话逐步明确文档的组织方式和内容要求，主要涉及：

• 开发板及 MCU 基本信息；
• MCU 引脚映射表；
• 板载硬件资源表；
• 硬件连接条件及必要的使用约束；
• 参考硬件网表的文件位置和查询说明；
• 原始硬件资料及信息缺失处理规则。

根据对话结果，逐步补充和调整 Markdown 文档内容，最终生成核心硬件上下文的初始版本g431rb_hardware_context.md，作为后续审阅与修订的基础。

5.3 内容审阅与修订

核心硬件上下文初稿生成后，通过 Codex 对话进行多轮审阅和修订。主要包括 MCU 引脚与板载硬件资源审阅，以及硬件配置和信息记录原则的修订。

（1）MCU 引脚与板载硬件资源审阅

以g431rb_hardware_facts.md为依据，逐项检查初稿中的 MCU 引脚映射和板载硬件资源记录，重点关注引脚编号、网络名称、连接端、板级功能及硬件使用条件。发现问题后，向 Codex 提出修改意见，逐项讨论并确认。

例如，审阅 MCU 引脚2/PC13时，可以使用如下提示词：

请检查核心硬件上下文中 2/PC13 的记录。 结合硬件事实表和参考硬件网表，核对其网络、 连接端、板级功能及硬件使用条件。 指出存在的问题和建议修改内容，暂时不要 直接修改文件，等待我确认。

采用逐项审阅的方式，完成16条 MCU 引脚记录和9项板载硬件资源的修改与确认。

（2）硬件配置与信息记录原则修订

在多轮对话中，进一步明确焊桥、跳帽等可选配置的记录原则：通常按照开发板官方资料规定的默认状态处理，不要求逐项核验实物；开发过程中发现实际行为与资料不一致时，再针对具体问题处理。

例如，可以使用如下提示词：

请按照以下原则修订核心硬件上下文： 1. 通常情况下，不假设开发板经过改装， 也不怀疑设计文件与实物不一致。 2. 对于用户手册说明的焊桥、跳线等默认配置， 按默认状态记录。 3. 特殊情况下发现实物与资料不一致时， 在具体开发过程中解决。 4. 不要将所有可选配置统一登记为待实物核验事项。

经过多轮审阅、修改和确认，核心硬件上下文逐步完善，最终形成正式版本。

5.4 核心硬件上下文最终版本

经过多轮对话生成、审阅和修订，最终形成 NUCLEO-G431RB 的核心硬件上下文文件：g431rb_hardware_context.md，版本为v0.6（正式版）。

该文件主要包含以下内容：

1. 基本信息与开发约束：记录开发板型号、实际开发目标 MCU、原理图设计基准 MCU，以及硬件信息使用和缺失处理规则。
2. MCU 引脚映射表：记录16条关键 MCU 引脚的物理编号、网络名称、板级功能、连接关系及使用条件。
3. 板载硬件资源表：整理9项关键硬件资源，包括用户按键、复位、LED、晶振、调试接口、虚拟串口及启动配置等。
4. 参考硬件网表说明：记录参考硬件网表文件的位置、数据用途及按需查询方式。
5. 原始资料索引与待确认事项：提供相关硬件资料的索引，并保留 HCF（Hardware Confirmation）机制，用于登记确实影响开发且现有资料无法确认的问题。

核心硬件上下文（g431rb_hardware_context.md）作为默认读取的硬件信息入口，集中提供开发过程中常用的硬件信息；参考硬件网表（g431rb_hardware_netlist.json）作为补充查询依据，保存完整的元器件属性和网络连接关系。两者相互关联，共同构成 NUCLEO-G431RB 的标准化硬件信息资源。

至此，完成了从原始硬件资料、结构化硬件事实到核心硬件上下文的整理与生成。

5.5 数据关联与一致性检查

核心硬件上下文生成后，需要对其与参考硬件网表之间的数据关联关系进行检查，确保两类文件中的 MCU 引脚、网络连接和板载器件引用保持一致。

本次检查以g431rb_hardware_context.md（v0.6）和g431rb_hardware_netlist.json（Schema v1.1）为对象，主要包括以下内容：

1. MCU 引脚映射检查：检查核心硬件上下文中的16条 MCU 引脚记录是否存在于参考网表的mcu_pin_index中，并核对引脚对应的网络名称和连接端点。
2. 板载资源关联检查：检查9项板载硬件资源引用的 MCU 引脚是否能够在引脚映射表中找到对应记录，同时检查相关器件位号是否存在于参考网表的components中。
3. 参考网表内部一致性检查：检查 MCU 引脚索引、网络名称及完整连接端点之间的对应关系，确保mcu_pin_index与nets中的数据保持一致。

检查结果表明，16条 MCU 引脚映射记录全部通过检查，9项板载硬件资源的16次 MCU 引脚引用均有效，相关器件引用及参考网表内部索引检查通过。

最终生成《G431 硬件上下文与参考网表联合审核报告（g431rb_hardware_context_netlist_joint_review）》，记录检查范围、检查结果及相关文件版本，为标准化硬件信息的正式归档提供依据。

需要说明的是，本次检查主要针对两类标准化文件之间的数据关联和结构一致性，不包括重新解析 Altium 原理图或核查开发板实物装配状态。

6. 总结

本文以 NUCLEO-G431RB 开发板为例，建立了从原始硬件设计资料提取、整理到标准化硬件信息生成的处理流程，最终形成两类标准化硬件信息文件。

本项目的主要成果包括：

1. 核心硬件上下文（g431rb_hardware_context.md）：
   采用 Markdown 格式，记录开发板基本信息、MCU 引脚映射、板载硬件资源及必要的硬件使用条件。本例整理了16条关键 MCU 引脚记录和9项板载硬件资源，作为 AI 开发时默认读取的硬件信息入口。
2. 参考硬件网表（g431rb_hardware_netlist.json）：
   按照制定的规范组织完整硬件连接数据，包含元器件信息、网络连接及 MCU 引脚索引。本例收录202个元器件、143个网络、653个网络连接端点及64条 MCU 引脚索引，作为完整硬件参考数据和补充查询依据。

在 STM32 嵌入式软件开发中，可将这两个文件放入对应开发板的硬件资料目录。开始 AI 协同开发时，首先提供核心硬件上下文，使 AI 了解开发板的 MCU 引脚分配、板载资源及硬件使用条件；当需要查询完整网络连接、外围器件或特定引脚的连接关系时，再根据需要查询参考硬件网表。两类文件相互配合，为工程分析、外设配置、任务规划和代码实现等开发阶段提供硬件信息支持。

上述处理流程和数据规范不依赖特定 AI 工具。更换 STM32 开发板时，可以复用已有的数据规范和自动化转换程序，重新整理对应开发板的硬件事实并生成核心硬件上下文，从而逐步建立可复用、可查询的 STM32 标准化硬件信息资源。

版权声明：

欢迎关注 youcans@xidian【嵌入式软件AI编程】专栏
转发必须注明原文链接：
【嵌入式软件AI编程】（3）面向 AI 协同开发的 STM32 硬件信息标准化
Copyright by ai4mcu@qq.com
Crated：2026-10