Agent skill · mindrally
embedded-stm32
Best practices for embedded C/C++ development on STM32 microcontrollers using the HAL, covering peripherals, DMA, interrupts, memory constraints, and hardware-focused testing. Use when writing STM32 HAL code, configuring peripherals generated by STM32CubeMX, working with interrupts or DMA, debugging with SWD/JTAG, managing memory-constrained firmware, or writing hardware-in-the-loop or host-build tests for embedded C.
What it needs
About 5k tokens when loaded.
What this skill does
Embedded STM32 / HAL Development This skill covers firmware development for STM32 microcontrollers using the STM32 HAL, including project structure, peripheral and interrupt handling, memory and timing constraints, and testing strategies for hardware-focused code. Workflow for STM32 HAL Firmware Development 1. Configure the hardware in CubeMX — Set up clocks, pins, and peripherals in the .ioc file; generate the HAL initialization code. 2. Separate generated and hand-written code — Keep CubeMX-generated files untouched except in their designated USER CODE BEGIN/END blocks; put application logic in separate files. 3. Initialize peripherals once — Centralize HALInit() calls in main()/MXInit() and avoid ad hoc reconfiguration elsewhere in the code. 4. Write interrupt handlers — Keep ISRs (HALCallback functions, EXTI/DMA/timer IRQ handlers) short; set flags or push to a queue and defer real work to the main loop or an RTOS task. 5. Use DMA for high-throughput I/O — Configure DMA for UART/SPI/I2C/ADC transfers that would otherwise block or burn CPU cycles on polling. 6. Add timeouts everywhere — Every blocking HAL call and every hardware wait loop needs a timeout and an explicit error path. 7. Test in layers — Unit-test pure logic on a host build (no hardware dependency), then validate peripheral behavior with hardware-in-the-loop tests. 8. Flash and debug — Use SWD/JTAG (ST-Link, OpenOCD, or J-Link) with a debugger, plus rate-limited serial logs, to verify behavior on real hardware. Project Structure Keep board support (pin/clock configuration), drivers, middleware (e.g., FreeRTOS, USB stack), application logic, and tests in clearly separated directories. Isolate CubeMX-generated or vendor code (Core/Src/main.c, Drivers/) from hand-written application code so regenerating with CubeMX doesn't clobber custom logic — only edit inside / USER CODE BEGIN / ... / USER CODE END / markers in generated files. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills mindrally/embedded-stm32