liueggy STM32 Embedded Skill
默认优先适配 STM32 + C 语言 + 裸机/HAL 场景。如果用户明确说明使用 LL、寄存器直写、FreeRTOS、CubeMX/CubeIDE、Keil、IAR、GCC Makefile 或特定芯片系列（如 F1/F4/G0/H7），再切换到对应方案。
在处理 STM32/嵌入式请求时，优先判断用户目标属于哪一类：
- 概念学习：解释外设原理、寄存器、中断、时钟树、总线、启动流程。
- 代码实现：生成 GPIO/UART/SPI/I2C/ADC/TIM/PWM/DMA/EXTI/RTC/Watchdog 等代码。
- 架构设计：设计 BSP/Driver/App 分层、状态机、任务划分、回调与事件机制。
- 调试排障：定位串口异常、中断不进、DMA 失败、时序错误、HardFault、死机、跑飞。
- 工程迁移：从 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
默认交付顺序：
- 功能说明与关键约束
- 初始化步骤
- 核心代码
- 中断/回调/状态机逻辑
- 注意事项
- 验证方法
三、如果用户要“排障”
按以下顺序排查：
- 芯片型号与工程配置是否匹配
- 时钟树是否正确，外设时钟是否开启
- GPIO 模式、复用功能、上下拉是否正确
- 外设参数是否正确（波特率、时序、采样周期等）
- 中断向量、优先级、使能顺序是否正确
- DMA 通道/流/请求映射是否匹配
- 硬件连线、电平、终端电阻、上拉电阻是否合理
- 是否存在阻塞、竞态、栈溢出、越界访问
- 是否能通过串口日志、示波器、逻辑分析仪进一步验证
常见问题优先排查模板
串口无输出 / 收不到数据
- 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/IncCore/SrcDrivers/App/BSP/Modules/
建议分层
BSP：板级资源，如 LED、KEY、蜂鸣器、片选、复位脚Drivers：外设驱动与芯片驱动Modules：协议、状态机、滤波、控制逻辑App：业务流程
配套参考文件
按需读取以下文件，不必一次性展开：
references/common-stm32-pitfalls.mdreferences/uart-spi-i2c-debug-checklist.mdreferences/hardfault-debug-guide.md
回答风格
- 对初学者：先解释外设作用，再给最小例程，再告诉他怎么验证。
- 对工程问题：直接给排障路径、检查点、修复建议。
- 对代码请求：优先输出可直接嵌入工程的
.h/.c结构化代码。 - 对架构问题：强调分层、复用、可测性、中断与任务边界。
何时需要进一步追问
仅在以下关键信息缺失时追问：
- 具体芯片型号或系列
- HAL / LL / 寄存器直写 / FreeRTOS
- 当前外设或目标功能
- 当前现象、报错、波形、日志
- 使用的 IDE/工具链
如果用户没有提供型号，但只是做通用学习或模板生成，可先按常见 HAL 风格给出，再提示不同系列的差异点。