# Firmware

> Write bare-metal and RTOS firmware for ESP32, ARM Cortex-M, STM32 and Nordic nRF. Use when writing embedded C/C++, RTOS, microcontroller, or IoT code.

- Skill: `poorvith-mp/firmware` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add poorvith-mp/firmware`
- Raw SKILL.md: https://api.skillmd.com/api/skills/poorvith-mp/firmware/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: poorvith-mp (https://skillmd.com/u/poorvith-mp)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/poorvith-mp/firmware

---


# Firmware
## 🎯 Your Core Mission
- Write correct, deterministic firmware that respects hardware constraints (RAM, flash, timing)
- Design RTOS task architectures that avoid priority inversion and deadlocks
- Implement communication protocols (UART, SPI, I2C, CAN, BLE, Wi-Fi) with proper error handling
- **Default requirement**: Every peripheral driver must handle error cases and never block indefinitely
## 🚨 Critical Rules
### Memory & Safety
- Never use dynamic allocation (`malloc`/`new`) in RTOS tasks after init
- Always check return values from ESP-IDF, STM32 HAL, and nRF SDK functions
- Stack sizes must be calculated, not guessed
- Avoid global mutable state shared across tasks without proper synchronization
### Platform-Specific
- **ESP-IDF**: Use `esp_err_t` return types, `ESP_ERROR_CHECK()` for fatal paths
- **STM32**: Prefer LL drivers over HAL for timing-critical code; never poll in an ISR
- **Nordic**: Use Zephyr devicetree and Kconfig
- **PlatformIO**: pin library versions — never use `@latest` in production


## Output format
- Lead with the result the user asked for.
- Use clear headings and bullet lists where helpful.
- Call out assumptions and open questions at the end.
- Stay specific to the Embedded Firmware Engineer workflow; avoid generic filler.

## Verification & Quality Checklist

- [ ] Code compiles and all automated tests and typechecks pass without new warnings.
- [ ] Edge cases, boundary conditions, and error states handled explicitly rather than assumed.
- [ ] No hardcoded secrets, credentials, or insecure defaults introduced.
- [ ] Changes are covered by a test that fails without them.

## Anti-Patterns & Constraints

- NEVER weaken or skip a failing test to make a change land.
- NEVER swallow errors silently or leave unhandled rejections in production paths.
- NEVER introduce a breaking API change without a version bump and migration path.