Imported from zhengzhang11/AAA_NUEDC_Train (校赛/skills(将里面两个skills移植到.claude的skills文件夹中)/atk-f407-bsp/SKILL.md). Install upstream with npx skills add zhengzhang11/AAA_NUEDC_Train --skill atk-f407-bsp. Copyright stays with the author.

ATK-F407 BSP Code Borrowing Skill

Purpose

When the current project (实验28 触摸屏实验 or any other working project under the same SDK) lacks a BSP driver, peripheral config, or middleware, follow this 3-phase workflow:

1. SEARCH — keyword-match the need against the experiment index below
2. READ — navigate into the matched experiment, read its BSP source files
3. ADAPT or GENERATE — integrate adapted code, or generate from scratch if no good match is found

Phase 0 – Decide whether search is needed

Before searching the library, check the current project:

Drivers/BSP/<module>/    ← already exists?  If yes, skip search.
User/<feature>.c/.h      ← already custom-coded?  If yes, skip search.

Only invoke the library search when the driver/feature is genuinely missing.

Phase 1 – Keyword → Experiment mapping

Base path of the experiment library

E:\2026电赛\【正点原子】探索者STM32F407开发板V3 资料盘(A盘)\2，标准例程-HAL库版本\2，标准例程-HAL库版本\

All 60 experiments live directly under this base path. Use Glob / Bash ls to list them when needed.

Full experiment index (keyword → folder name)

Note on sub-experiments: folders with \实验N-M sub-folders contain multiple variants. When searching, check the parent folder first, then descend into the most relevant sub-folder.

Phase 2 – Reading BSP source files

Standard directory layout inside each experiment

实验N XXXXX/
├── Drivers/
│   ├── BSP/               ← primary target: one sub-folder per peripheral
│   │   ├── LCD/           ← lcd.h, lcd.c, lcdfont.h
│   │   ├── KEY/           ← key.h, key.c
│   │   ├── LED/           ← led.h, led.c
│   │   ├── TOUCH/         ← touch.h, touch.c, ctiic.h, ctiic.c …
│   │   ├── SRAM/          ← sram.h, sram.c
│   │   ├── SPI/           ← spi.h, spi.c
│   │   ├── IIC/           ← myiic.h, myiic.c
│   │   ├── RS485/         ← rs485.h, rs485.c
│   │   ├── CAN/           ← can.h, can.c
│   │   ├── W25QXX/        ← w25qxx.h, w25qxx.c
│   │   ├── NORFLASH/      ← norflash.h, norflash.c
│   │   ├── SDIO/          ← sdio_sdcard.h, sdio_sdcard.c
│   │   ├── ES8388/        ← es8388.h, es8388.c (audio codec)
│   │   ├── OV7670/        ← ov7670.h, ov7670.c
│   │   └── …
│   ├── CMSIS/             ← ARM core headers (no modification needed)
│   └── STM32F4xx_HAL_Driver/ ← HAL library (no modification needed)
├── Middlewares/           ← FATFS, FreeRTOS, LWIP, USB if present
├── User/
│   ├── main.c
│   ├── usart.c / usart.h  ← USART1 printf redirect
│   ├── adc.c  / adc.h     ← if ADC used
│   └── …
├── Projects/              ← Keil .uvprojx
└── readme.txt             ← always read this first for pin / config notes

Reading order

1. readme.txt — confirms the peripheral's function and any board-specific notes
2. Drivers/BSP/<module>/<module>.h — macro defines, struct types, API prototypes
3. Drivers/BSP/<module>/<module>.c — initialization, IRQ handlers, core logic
4. User/main.c lines near /* USER CODE BEGIN 2 */ — how the module is initialized and called

Phase 3 – Adapt or Generate

When to ADAPT from the reference experiment

Adapt when ALL of these are true:

• A clear keyword match exists in the index (Phase 1)
• The BSP folder for the module is found in Drivers/BSP/
• The peripheral's core logic is portable (not tightly coupled to a specific demo task that conflicts with the current project)

Adaptation checklist:

When to GENERATE fresh code

Generate when ANY of these is true:

• No experiment in the index matches the needed peripheral
• The matched experiment's BSP code is deeply coupled to its own demo (e.g. photo capture demo calling SD card + FATFS simultaneously)
• Adapting would require changing more than ~40 % of the source lines
• The user explicitly prefers fresh code

Generation standards:

/* Template for a new BSP driver file */

/**
 * @file  bsp_<module>.c
 * @brief <Module> driver for ATK Explorer STM32F407 V3.
 *        HAL library.  All comments ASCII (Keil GBK-safe).
 */

#include "bsp_<module>.h"

/* ---- private macros ---------------------------------------------------- */
/* ---- private types ----------------------------------------------------- */
/* ---- private variables ------------------------------------------------- */
/* ---- private function prototypes --------------------------------------- */

/* ======================================================================== */
/* Public API                                                                */
/* ======================================================================== */

/**
 * @brief Initialize <module>.
 * @retval 0 OK, 1 error
 */
uint8_t bsp_<module>_init(void)
{
    /* clock enable */
    /* GPIO init */
    /* peripheral init */
    return 0u;
}

Rules for generated code:

• Pure ASCII comments (no Chinese in .c/.h to stay Keil GBK-safe)
• HAL-based (not bare register) unless performance demands it
• Defensive uint8_t return values (0=OK, 1=error)
• No dynamic allocation — use static buffers
• No printf inside BSP drivers — return status codes; let the application print

Integration checklist (both adapt and generate)

[ ] Header .h placed in Drivers/BSP/<MODULE>/
[ ] Source .c placed in Drivers/BSP/<MODULE>/
[ ] Include path added in Keil: Options → C/C++ → Include Paths
[ ] Source file added to Keil project tree (right-click group → Add existing)
[ ] Corresponding #include added in the calling .c file
[ ] Pin conflicts checked against atk-f407 skill conflict table
[ ] IRQ priorities set (lower number = higher priority; do not clash with TIM6 used by delay)
[ ] Tested with a minimal call in main() before wiring into the full application

Quick decision flowchart

Need peripheral X in current project?
│
├─ Already in Drivers/BSP/ or User/?  → Use it as-is.
│
└─ Missing
   │
   ├─ Keyword match in index?
   │   ├─ YES → Read readme.txt + BSP source
   │   │         ├─ Easily portable (< 40% changes)?  → ADAPT
   │   │         └─ Deeply coupled to demo?           → GENERATE
   │   │
   │   └─ NO  → GENERATE fresh code directly
   │
   └─ After adapt/generate: run Integration checklist

Common peripheral keyword shortcuts

Notes on the current working project (实验28 触摸屏实验)

• This project already has: LCD, TOUCH (resistive + capacitive), KEY, LED, USART1 (printf), USART3 (motor data), TIM (delay), SRAM (if needed)
• Do NOT copy the entire BSP from another experiment — copy only the specific driver sub-folder needed
• usart.c owns HAL_UART_RxCpltCallback for USART1. Any new UART peripherals must use direct ISR (USARTx_IRQHandler) with raw SR/DR register access to avoid HAL callback conflicts
• The project uses GBK source encoding in Keil. All new .c/.h files must be ASCII-only comments (or explicit GBK byte arrays as done in chinese_font.c)