53 lines
1.9 KiB
Markdown
53 lines
1.9 KiB
Markdown
|
# 可复用模式
|
||
|
|
|
||
|
|
## 目的
|
||
|
|
|
||
|
|
记录开发过程中发现的可持续复用的模式和做法。
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## P-001: 测试→LL→HAL 提炼路径
|
||
|
|
|
||
|
|
**上下文**: 每个功能单元从寄存器测试到最终 SDK 驱动的演进
|
||
|
|
**问题**: 测试代码和 SDK 驱动如何衔接，避免重复劳动
|
||
|
|
**方案**: 三步提炼路径：
|
||
|
|
1. **寄存器测试代码** → 直接操作寄存器地址和位域，验证功能正确性
|
||
|
|
2. **LL 层提炼** → 将测试中的寄存器操作封装为内联函数+宏，零开销
|
||
|
|
3. **HAL 层封装** → 在 LL 层之上加句柄+状态机+回调，高抽象可移植
|
||
|
|
|
||
|
|
**关键约束**: 测试代码必须结构化（用宏封装寄存器操作，不用硬编码地址），否则提炼成本极高
|
||
|
|
|
||
|
|
**何时用**: 每个功能单元完成后
|
||
|
|
**何时不用**: 纯软件功能（无寄存器操作）
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## P-002: 勘误驱动规避
|
||
|
|
|
||
|
|
**上下文**: 芯片 bring-up 中发现的硅缺陷
|
||
|
|
**问题**: 如何让 SDK 驱动自动规避已知勘误
|
||
|
|
**方案**:
|
||
|
|
1. 勘误记录在 Test/errata/ 中，结构化格式（影响外设、触发条件、规避方法）
|
||
|
|
2. LL 层代码中在受影响操作处加 workaround 注释
|
||
|
|
3. HAL 层代码中自动执行规避逻辑（对调用方透明）
|
||
|
|
|
||
|
|
**何时用**: 发现勘误后立即记录，LL/HAL 代码同步更新
|
||
|
|
**何时不用**: 确认无硅缺陷的功能
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## P-003: 跨 AI 上下文交接
|
||
|
|
|
||
|
|
**上下文**: 不同 AI 可能在不同时间、不同平台介入同一项目
|
||
|
|
**问题**: 如何确保任何 AI 随时能接手
|
||
|
|
**方案**:
|
||
|
|
1. AGENTS.md 是通用上下文锚点
|
||
|
|
2. dashboard.md 记录当前状态，任何 AI 读到即知全貌
|
||
|
|
3. task 文件自包含（输入/输出/约束/验收），不依赖对话历史
|
||
|
|
4. Git commit 记录所有变更，Git 是唯一的历史来源
|
||
|
|
|
||
|
|
**核心原则**: 对话是易失的，文件是持久的。每个判断产生后立即写入文件。
|
||
|
|
|
||
|
|
**何时用**: 每次 AI 会话
|
||
|
|
**何时不用**: 无（这是基础模式，始终适用）
|