embedded-stm32-labs-windows

name	embedded-stm32-labs-windows
description	Use when Codex needs to complete SWJTU intelligent embedded systems STM32F103ZCT6 course labs for Windows users via command line: read lab guide tasks, create or modify experiment projects, build with ARM GNU Toolchain/Make/OpenOCD/CMSIS-DAP, flash boards, drive serial tests, write Chinese reports/operation guides, and minimize GUI work and repeated flashing.

Embedded STM32 Labs Windows

Use this skill to act as the lab operator for the SWJTU embedded programming course. Prefer command-line work on Windows, make the code, flash when asked, and let the student only observe the board and report physical symptoms.

Core Workflow

1. Locate the course repo and read AGENTS.md first if present.
2. Read the target lab task list from the repo docs/guides/guide-kb/tasks/experiment-XX-tasks.md, or from bundled references/guide-kb/tasks/experiment-XX-tasks.md if the repo does not include the guide knowledge base.
3. Use bundled references/guide-kb/raw/experiment-XX.md for original guide wording. Use the PDF in assets/guides/ only when page-level or image-level verification is needed.
4. Use the known board facts in references/board-facts.md; do not rediscover stable pin mappings.
5. Prefer a single multi-mode firmware per experiment when it reduces flashing and still maps clearly to the guide tasks.
6. Reuse the closest existing project as a template before starting from scratch.
7. Build, fix compiler errors, and run board checks with command-line tools.
8. Flash only when the user asks or when hardware validation is required.
9. For physical validation, give one short action at a time and ask the student to report board/serial behavior.
10. Produce an operation guide and report draft after the firmware is usable.

Windows Command Line Defaults

Read references/windows-command-line.md before setting up or debugging Windows tooling. Default to:

• PowerShell 7 or Windows PowerShell
• ARM GNU Toolchain arm-none-eabi-*
• Make via mingw32-make, make, MSYS2, or bundled project wrapper
• OpenOCD with cmsis-dap
• Python 3 + pyserial for serial automation
• No Keil/CubeMX GUI unless the user explicitly requires screenshots matching the teacher route

Use / paths inside Makefiles where possible. In PowerShell examples, quote paths containing spaces.

Lab References

Use only the files needed for the requested experiment:

• references/lab-map.md: task summaries for experiments 1-8 and implementation strategy.
• references/guide-kb/tasks/: task lists extracted from the official experiment guide PDF.
• references/guide-kb/raw/: per-experiment raw text extracted from the official experiment guide PDF.
• references/board-facts.md: MCU, peripherals, pins, active levels, known pitfalls.
• references/windows-command-line.md: Windows setup, build, flash, serial workflow.
• references/implementation-playbook.md: how to implement, validate, and explain each lab quickly.
• references/report-patterns.md: Chinese report and operation-guide structure.
• assets/guides/智能嵌入式系统设计实验指导书（2026）.pdf: original guide PDF for source verification.

Scripts

Use scripts without loading their source unless patching is needed:

• scripts/windows_env_check.ps1: check Windows tools, connected CMSIS-DAP, and serial ports.
• scripts/serial_tool.py: send text or HEX frames over COM ports for USART/DMA labs.
• scripts/package_skill.py: create a distributable zip of this skill folder.

Implementation Rules

• Keep changes scoped to the requested experiment directory.
• Do not revert unrelated user work.
• Prefer HAL-based code matching existing projects unless the repo uses another pattern.
• Put hardware pin macros in headers so board variants can be changed quickly.
• Use ring buffers or DMA buffers for serial labs; avoid fragile blocking loops that break display scan.
• For interrupt/DMA labs, explain classroom demo choices separately from production best practice.
• Generate README.md, OPERATION_GUIDE.md, notes/implementation-notes.md, and report/report-draft.md for each completed experiment unless the user asks for code only.

Student Interaction Pattern

When hardware behavior is needed, ask for concrete observations:

• Which COM port appears?
• What does serial output show?
• Which LED/RGB/7-seg/buzzer/motor changed?
• Did reset change the mode?
• Is tio, PuTTY, or another serial tool occupying the port?

Give one board action at a time. Do not ask the student to edit code by hand unless unavoidable.