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/嵌入式请求时，优先判断用户目标属于哪一类： 概念学习：解释外设原理、寄存器、中断、时钟树、总线、启动流程。 代码实现：生成 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/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 风格给出，再提示不同系列的差异点。