nuttx-driver-development

NuttX Driver Development

Follow the full driver lifecycle in order. Keep edits small and testable.

[!TIP] This skill can be used standalone or via the driver-workflow agent (agents/driver-workflow.agent.md) for end-to-end driver development with automated reference matching, requirements generation, and PR submission.

Table of Contents

1. Preparation
   • Clarify scope and expectations
   • Find reference drivers
   • Determine driver pattern
   • Layout driver files
2. Implementation
   • Write driver C implementation
   • Write public header file
   • Kconfig and build system integration
   • Board-level registration
3. NuttX Coding & Kernel API Rules
4. Code Review
5. References

---

Preparation

1) Clarify scope and expectations

• Identify the NuttX driver subsystem (sensor, serial, timer, analog, etc.).
• Confirm target bus (I2C, SPI, 1-Wire, etc.) and required hardware properties.
• Clarify the NuttX source tree location. The driver code lives under nuttx/drivers/.

2) Find reference drivers

[!NOTE] Two types of reference drivers serve different purposes

• 骨架参考（NuttX API 模式）: 优先使用 NuttX in-tree 同类驱动作为代码骨架，确保符合 NuttX 的 upper-half/lower-half 架构和 VFS 集成方式
• 芯片参考（寄存器/时序验证）: 优先使用 Linux/Zephyr 同芯片驱动，用于交叉验证 datasheet 的寄存器定义、初始化序列、SPI 帧格式等芯片专属知识

When used standalone: 手动搜索两类参考驱动 When used with driver-workflow agent: Step A.2 自动完成两条线的并行搜索

Always look at the in-tree NuttX drivers before doing any work. There might already be a driver that (best scenario at the top):

1. Is exactly the same part as the one you are working on
2. Targets a very similar part from the same vendor (e.g., BMP280 vs BME680)
3. Is the same device subsystem as yours (e.g., another I2C sensor)

If a reference driver is found, use it as a skeleton template:

1. Copy the source file structure (function signatures, bus access pattern, registration flow, file layout)
2. Replace all device-specific content: register definitions, chip ID values, vendor/chip names, init sequences, calibration logic
3. After generating code, grep for the original chip name — zero matches required
4. Do NOT copy register addresses or chip-specific constants — these must come from the target device's datasheet