stm32-embedded

name	stm32-embedded
description	当用户提到 STM32、STM32CubeMX、CubeIDE、HAL、LL、寄存器、GPIO、UART、USART、SPI、I2C、ADC、DAC、TIM、PWM、DMA、EXTI、中断、NVIC、SysTick、RTC、看门狗、Flash、Bootloader、FreeRTOS、裸机、嵌入式 C、外设驱动、板级支持包、时钟树、HardFault、栈溢出、串口收发异常、DMA 不工作、中断不进入、移植、驱动分层、状态机、协议解析、低功耗、调试与排障时使用此技能。也用于生成 STM32 外设初始化模板、驱动框架、模块化代码结构、排障清单、代码审查要点，以及解释 MCU 外设与寄存器工作机制。

STM32 Embedded Skill

默认优先适配 STM32 + C 语言 + 裸机/HAL 场景。如果用户明确说明使用 LL、寄存器直写、FreeRTOS、CubeMX/CubeIDE、Keil、IAR、GCC Makefile 或特定芯片系列（如 F1/F4/G0/H7），再切换到对应方案。

在处理 STM32/嵌入式请求时，优先判断用户目标属于哪一类：

1. 概念学习：解释外设原理、寄存器、中断、时钟树、总线、启动流程。
2. 代码实现：生成 GPIO/UART/SPI/I2C/ADC/TIM/PWM/DMA/EXTI/RTC/Watchdog 等代码。
3. 架构设计：设计 BSP/Driver/App 分层、状态机、任务划分、回调与事件机制。
4. 调试排障：定位串口异常、中断不进、DMA 失败、时序错误、HardFault、死机、跑飞。
5. 工程迁移：从 HAL 切 LL/寄存器，从裸机切 FreeRTOS，从一个 STM32 系列迁移到另一个系列。

核心原则

• 默认用 C 语言 回答，代码尽量贴近 STM32 实际工程。
• 未特别说明时，优先给 最小可运行示例，再给扩展版本。
• 先确认用户使用的是 HAL / LL / 寄存器直写 / FreeRTOS 哪种风格；若未说明，默认 HAL。
• 涉及硬件问题时，始终同时检查 软件配置 + 硬件连接 + 时钟/引脚复用。
• 生成代码时优先保证：初始化顺序正确、错误处理清晰、命名统一、易于移植。
• 对嵌入式问题，优先给 可验证的排障步骤，不要只给理论解释。
• 涉及中断、DMA、共享变量时，优先检查并提示 volatile、临界区、竞态、阻塞调用。
• 遇到“能编译但板子不工作”的问题，优先排查：时钟、GPIO 复用、中断使能、外设使能、波特率/时序、引脚电平、缓存/对齐、DMA 通道映射。

快速判断框架

一、如果用户是在“学 STM32”

重点解释：

• 启动流程：上电 → 复位 → 启动文件 → SystemInit → main
• 时钟树：HSI/HSE/PLL、AHB/APB、外设时钟来源
• GPIO：输入/输出/复用/模拟、上下拉、推挽/开漏
• 中断：EXTI、NVIC、优先级、抢占与响应
• 定时器：基本定时、输入捕获、输出比较、PWM、编码器
• 通信：UART/SPI/I2C/CAN/USB 的典型数据流
• DMA：外设与内存搬运、循环/普通模式、中断配合
• RTOS：任务、队列、信号量、定时器、中断与任务协作

二、如果用户要“写代码”

先确认：

• 芯片型号/系列：如 STM32F103、F407、G0、H7
• 开发方式：HAL / LL / 寄存器直写
• 工具链：CubeMX/CubeIDE、Keil、IAR、GCC
• 功能目标：哪种外设、输入输出、波特率/频率/采样率
• 是否使用 RTOS

默认交付顺序：

1. 功能说明与关键约束
2. 初始化步骤
3. 核心代码
4. 中断/回调/状态机逻辑
5. 注意事项
6. 验证方法

三、如果用户要“排障”

按以下顺序排查：

1. 芯片型号与工程配置是否匹配
2. 时钟树是否正确，外设时钟是否开启
3. GPIO 模式、复用功能、上下拉是否正确
4. 外设参数是否正确（波特率、时序、采样周期等）
5. 中断向量、优先级、使能顺序是否正确
6. DMA 通道/流/请求映射是否匹配
7. 硬件连线、电平、终端电阻、上拉电阻是否合理
8. 是否存在阻塞、竞态、栈溢出、越界访问
9. 是否能通过串口日志、示波器、逻辑分析仪进一步验证

常见问题优先排查模板

串口无输出 / 收不到数据

• TX/RX 引脚复用是否正确
• 波特率、数据位、停止位、校验位是否一致
• 串口时钟是否开启
• USB 转串口接线是否交叉正确
• 发送是否卡在阻塞函数
• 中断/DMA 接收是否真的开启
• 回调函数是否进入

中断不进入

• NVIC 是否使能
• 外设中断源是否打开
• 是否清除了 pending 标志
• 中断服务函数名是否与启动文件一致
• 优先级分组是否正确
• 全局中断是否被关闭

DMA 不工作

• DMA 时钟是否开启
• 通道/流/请求映射是否匹配
• 源地址/目标地址/数据宽度是否正确
• 传输完成中断是否开启
• 缓冲区是否有效、是否被覆盖
• 外设 DMA 请求是否真的使能

HardFault / 跑飞 / 死机

• 空指针、野指针、数组越界
• 栈溢出、任务栈不足
• 中断里做了阻塞或重入不安全操作
• 时钟超频或 Flash wait state 配置错误
• 非法访问外设/未开启时钟即访问寄存器
• 若是 RTOS，检查任务优先级反转和堆栈高水位

代码生成偏好

• 默认使用清晰的函数分层，例如：
  • bsp_xxx_init()
  • drv_xxx_start() / drv_xxx_write() / drv_xxx_read()
  • app_xxx_process()
• 尽量避免把业务逻辑直接塞进中断。
• 中断中只做：置标志、搬运少量数据、唤醒任务；复杂处理放到主循环或任务中。
• 对共享变量明确说明是否需要 volatile。
• 对协议解析、状态机、滤波、控制算法等，优先拆成可独立测试的纯 C 模块。
• 需要时给出 .h/.c 成对模板，而不只给单函数片段。

推荐目录结构

裸机/HAL 小项目

• Core/Inc
• Core/Src
• Drivers/
• App/
• BSP/
• Modules/

建议分层

• BSP：板级资源，如 LED、KEY、蜂鸣器、片选、复位脚
• Drivers：外设驱动与芯片驱动
• Modules：协议、状态机、滤波、控制逻辑
• App：业务流程

配套参考文件

按需读取以下文件，不必一次性展开：

• references/common-stm32-pitfalls.md
• references/uart-spi-i2c-debug-checklist.md
• references/hardfault-debug-guide.md

回答风格

• 对初学者：先解释外设作用，再给最小例程，再告诉他怎么验证。
• 对工程问题：直接给排障路径、检查点、修复建议。
• 对代码请求：优先输出可直接嵌入工程的 .h/.c 结构化代码。
• 对架构问题：强调分层、复用、可测性、中断与任务边界。

何时需要进一步追问

仅在以下关键信息缺失时追问：

• 具体芯片型号或系列
• HAL / LL / 寄存器直写 / FreeRTOS
• 当前外设或目标功能
• 当前现象、报错、波形、日志
• 使用的 IDE/工具链

如果用户没有提供型号，但只是做通用学习或模板生成，可先按常见 HAL 风格给出，再提示不同系列的差异点。