C firmware

C firmware 表示仓库以 C 为主要固件实现语言，并围绕 Make/CMake、板级目录、手写 bring-up 文档和硬件资产协同建立了稳定维护方式。这里关注的是 C firmware 的工程形态，而不是简单的语言标签。

它通常和 Device mono-repo、ESP32 firmware、PCB assets 一起出现，但不替代这些 Topic：C firmware 解释的是 C 侧 build/runtime/board-level 维护契约，其他 Topic 才解释设备形态、芯片家族或硬件资产组织（projects/display-ambient-light-board.md、projects/whisker-breeze.md）。

当 README、project snapshot、Makefile、CMakeLists.txt、firmware/ 目录或板级说明文档明确表明仓库主要维护的是 C 固件时使用。若 C 只是小型辅助模块、SDK 片段或历史目录，则不应抬成 Topic。

如果一个改动会影响 build entrypoint、board bring-up、硬件资源分配、编译选项、烧录路径、固件与 PCB/文档的同步方式，就应该命中 C firmware。若问题主要在芯片家族、设备分体式架构或硬件资产组织，则应再借助相邻 Topic 收边界。

• Make/CMake 入口本身就是知识的一部分，不能省略。很多 C 固件仓库的“怎么构建、怎么刷写、怎么切板型”都写在这些入口和文档里，而不是语言本身。
• C firmware 常和 PCB、docs、脚本共仓，说明维护动作不是单纯改代码，而是同时管理硬件定义和板级验证（projects/whisker-breeze.md）。
• 回答此 Topic 时，应优先写清 build 系统、板级目录和 bring-up 文档，而不是泛泛地说“固件项目”。C 固件最容易丢的是入口和环境，而不是概念定义。
• 对 how-to 导向的项目，README/INSTALL/board notes 往往比代码结构更能表达当前真相；维护时不能只读源码就下结论（projects/display-ambient-light-board.md）。
• 如果仓库同时保留硬件资产，Topic 里应写明哪些文件是电路真相、哪些是固件入口、哪些是制造/装配辅助，避免后续维护者误改错误层。

• projects/display-ambient-light-board.md：偏 ESP-IDF/CMake 风格，适合说明 how-to 文档和 build 入口怎样成为固件契约。
• projects/whisker-breeze.md：偏 firmware + PCB 共仓，适合说明 C 固件常常和硬件资产一起维护。

• 只因为仓库里有 .c 文件就打 C firmware，会把 SDK、脚本和真正的固件入口混在一起。
• 把 C firmware 当成整个仓库的总括标签，忽略 Device mono-repo、ESP32 firmware、PCB assets 等相邻 Topic，会让后续 Agent 无法判断真正该看的是构建入口、芯片家族还是硬件资产。
• 不写 Make/CMake/板级入口，会让维护者根本不知道从哪里开始验证。
• 把 how-to 文档当作可有可无的补充，也会误判项目真相；很多 C 固件项目的关键上下文并不在代码注释里。

• projects/display-ambient-light-board.md
• projects/whisker-breeze.md
• skills/style-playbook/references/data/topics/c-firmware.json