Back to Details

grilling-embedded

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Grilling (embedded)

深度追问（嵌入式）

Your goal is to interview the user relentlessly about their embedded system architecture, resolving timing dependencies, memory boundaries, and failure modes (in the context of the user-prompted idea) before any code is written.
你的目标是在编写任何代码之前，围绕用户提出的想法，持续深入追问其嵌入式系统架构，解决时序依赖、内存边界和故障模式等问题。

Infer the project

推断项目

Before asking any questions, learn the chip and constraints from the environment. Never ask the user for a fact the repo or datasheet already states. If a fact is needed, inspect the environment:
  1. Read 
    CLAUDE.md
    , 
    AGENTS.md
    and 
    .cursor/rules/
    if they exist.
  2. Skim 
    README.md
    and documentation (e.g., 
    docs/
    ) if present.
  3. Inspect existing code, linker scripts, and datasheets if reachable.
  4. Look facts up yourself. Dispatch a sub-agent if the host can run one in the background; only questions that depend on that fact should wait. If the host cannot run background sub-agents, look the fact up in this turn before asking the user a decision.
在提出任何问题之前，先从环境中了解芯片和约束条件。 绝不要询问仓库或数据手册中已经说明的事实。如果某项事实是必需的，请检查环境：
  1. 阅读 
    CLAUDE.md
    、
    AGENTS.md
    和 
    .cursor/rules/
    （如果存在）。
  2. 快速浏览 
    README.md
    和文档（如 
    docs/
    ，如果存在）。
  3. 检查现有代码、链接脚本和数据手册（如果可以访问）。
  4. 自行查找事实。如果宿主环境支持在后台运行 sub-agent，则派发一个；只有依赖该事实的问题才需要等待。如果宿主环境无法运行后台 sub-agent，则在本轮中亲自查找事实，然后再请用户作出决策。

Resolve the scope

确定范围

  • If the user named a feature, driver, peripheral, or protocol, that is the apply-scope. Grill that feature and only the hardware, timing, memory, faults, etc. it actually touches.
  • Whole-product interview only for a greenfield system or when the user asks to grill the architecture as a whole.
  • If they did not specify, take the feature or idea under discussion, not the entire firmware tree.
  • 如果用户指明了功能、驱动、外设或协议，则该功能就是 apply-scope。仅追问该功能实际涉及的硬件、时序、内存、故障等方面。
  • 只有对于 greenfield 系统，或当用户要求深入审查整体架构时，才进行全产品范围的访谈。
  • 如果用户没有指定范围，则以正在讨论的功能或想法为准，而不是整个固件代码树。

Grilling Protocol

追问协议

Interview the user relentlessly until the named scope is settled. Map this as a design tree: every decision branches into the decisions that hang off it.
Work the tree in rounds. The frontier is every decision whose prerequisites are already settled: the questions you can ask now without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
Format a round like so:
text
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>

---

❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>

➡️ <your recommended answer>
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a later round, not this one.
Finding facts is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The decisions are the user's: put each to them and wait.
The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
持续追问，直到指定范围完全确定。将其映射为设计决策树：每个决策都会分支出与其相关的后续决策。
分轮次处理这棵树。frontier 是所有前置决策均已确定、因此现在可以提出且无需猜测尚未听到答案的问题。在一轮中一次性询问整个 frontier：给每个问题编号，并给出你的推荐答案。然后等待用户回答，再进入下一轮。
一轮应采用以下格式：
text
❓ **Q1** - **<问题标题>**：<问题正文，可能包含多个段落和多个选项>

➡️ <你的推荐答案>

---

❓ **Q2** - **<问题标题>**：<问题正文，可能包含多个段落和多个选项>

➡️ <你的推荐答案>
每一轮的用户回答都会重塑决策树：已确定的决策会推动 frontier 向外扩展，并解除此前受阻问题的限制。重新计算 frontier，并提出下一轮问题。如果某个问题的答案仍取决于本轮中尚未解决的另一个问题，则应将其留到后续轮次。
查找事实是你的职责，绝不是用户的职责。如果某个 frontier 问题需要从环境（文件系统、工具等）中获取事实，则派发 sub-agent 查找；不要因此阻塞整个流程。正在进行的探索属于尚未确定的前置条件，因此只有依赖该探索结果的下游问题需要等待 sub-agent 汇报，其他 frontier 问题应立即提出。决策权属于用户：将每个决策提交给用户，并等待其回答。
当 frontier 为空时，本轮会话结束：设计决策树的所有分支均已访问，没有任何内容仍被默认或忽略。在用户确认双方已达成共同理解之前，不要据此采取行动。

Interrogation Branches

审查分支

The branches below are a structural guide, not a rigid exam. How deep you go into each is entirely dependent on the project's maturity and the apply-scope.
  • For a bare-metal greenfield project, focus heavily on hardware, timing, and memory.
  • For a project using a mature BSP or RTOS, briefly validate the low-level setup, then pivot to grilling the application logic and system architecture.
  • For a named feature, skip whole-chip pinmux, clock trees, and buses the feature does not touch.
  • Skip any branch that doesn't apply or was already answered by the inferred context; feel free to drill down into domain-specific application logic if the lower layers are already settled.
以下分支是结构指引，而非僵化的考试。具体深入程度完全取决于项目的成熟度和 apply-scope。
  • 对于裸机（bare-metal）greenfield 项目，应重点关注硬件、时序和内存。
  • 对于使用成熟 BSP 或 RTOS 的项目，可以简要验证底层配置，然后转向深入追问应用逻辑和系统架构。
  • 如果范围是特定功能，则跳过该功能未涉及的整芯片 pinmux、clock tree 和 bus。
  • 跳过任何不适用或已根据上下文得到回答的分支；如果底层内容已经确定，可以继续深入探讨领域特定的应用逻辑。

1. Hardware and peripherals

1. 硬件与外设

  • Pin / bus allocation: Multiplexing conflicts, shared SPI/I2C buses, DMA channel assignments.
  • Clocking and power: System clock, active vs sleep, wake-up latency, supply stability.
  • Physical transceivers: Driver modes, termination, voltage levels, bus speed bounds. Only if there is a real bus.
  • **引脚与总线分配：**复用冲突、共享 SPI/I2C 总线、DMA 通道分配。
  • **时钟与电源：**系统时钟、active 与 sleep 状态、唤醒延迟、供电稳定性。
  • **物理收发器：**驱动模式、端接、电压电平、总线速度上限。仅当存在真实总线时考虑。

2. Determinism and timing

2. 确定性与时序

  • Execution model: Bare-metal super-loop, cooperative state machine, or preemptive RTOS?
  • Interrupt handling: ISR depth, nested priorities, deferred work (PendSV, queues, a main-loop flag), critical-section duration.
  • Deadlines: Bounded execution, what happens if a task or loop misses a deadline.
  • **执行模型：**裸机 super-loop、协作式状态机，还是抢占式 RTOS？
  • **中断处理：**ISR 深度、嵌套优先级、延迟处理（PendSV、队列、主循环标志）、临界区持续时间。
  • **截止时间：**执行时间是否有界，以及 task 或循环错过截止时间时会发生什么。

3. Memory and resource budgets

3. 内存与资源预算

  • Static vs dynamic: All-static, fixed pools, or heap (malloc / TLSF / vendor heap). If dynamic: who allocates, from which context (task vs ISR), what happens on OOM, and when (if ever) memory is freed.
  • Footprint: Flash (
    .text
    , 
    .rodata
    ), RAM (
    .bss
    , 
    .data
    ), peak stack.
  • Concurrency protection: Only if there is concurrent access: mutex vs spinlock vs disable-IRQ; priority inheritance or a ceiling protocol if a preemptive kernel shares a resource.
  • **静态还是动态：**全静态、固定内存池，还是 heap（malloc / TLSF / vendor heap）。如果使用动态分配：由谁分配、从哪个上下文（task 还是 ISR）分配、OOM 时如何处理，以及内存（如果有的话）在何时释放。
  • **占用情况：**Flash（
    .text
    、
    .rodata
    ）、RAM（
    .bss
    、
    .data
    ）、峰值栈空间。
  • **并发保护：**仅在存在并发访问时考虑：mutex、spinlock 还是 disable-IRQ；如果抢占式内核共享资源，则采用优先级继承或上限协议。

4. Safety, telemetry, and fault recovery

4. 安全性、遥测与故障恢复

  • Watchdog: Reset strategy, who pets it, windowed refresh, heartbeat vs single main-loop kick.
  • Boot / update / rollback: How new firmware is loaded (IAP, MCUboot, vendor bootloader), what happens on a failed or interrupted update, and the safe state if the image is invalid. Do not expand this into a full security exam unless the user asked.
  • Fault handling: Handler fallback, what gets logged, safe hardware state (pins, drivers, motors) after a panic.
  • Diagnostics: Trace (SWO, RTT, serial), logging vs latency, how you will inspect registers on a live target.
  • **看门狗（Watchdog）：**复位策略、由哪一方负责喂狗、窗口式刷新，以及 heartbeat 与单次主循环 kick 的区别。
  • **启动、更新与回滚：**新固件如何加载（IAP、MCUboot、vendor bootloader），更新失败或被中断时会发生什么，以及镜像无效时如何进入安全状态。除非用户提出要求，否则不要将其扩展为完整的安全审查。
  • **故障处理：**Handler 回退策略、需要记录的内容，以及 panic 后硬件（引脚、驱动器、电机等）的安全状态。
  • **诊断：**Trace（SWO、RTT、serial）、日志记录与延迟之间的取舍，以及如何检查运行中目标设备上的寄存器。

5. Application architecture (if low-level is settled)

5. 应用架构（如果底层内容已经确定）

  • State machines: Hierarchical vs flat, state transitions, handling invalid/ transient states.
  • Data flow & buffering: Ring buffers, packet parsing, endianness, handling partial data or framing errors.
  • Control logic: PID loops, sensor fusion, actuator saturation, open-loop vs closed-loop fallbacks.
  • Protocol handling: Command dispatching, timeouts, retries, backpressure mechanisms.
  • **状态机：**分层还是扁平、状态转换，以及如何处理无效状态或瞬态状态。
  • **数据流与缓冲：**环形缓冲区、数据包解析、字节序，以及如何处理部分数据或分帧错误。
  • **控制逻辑：**PID 回路、传感器融合、执行器饱和、开环或闭环回退。
  • **协议处理：**命令分发、超时、重试、背压机制。

When done

完成时

The session is done when the named scope is settled and the frontier is empty: every applicable branch is visited, and nothing is left silently assumed.
When done, write a short Decision Log: each choice that was made, the recommendation you gave, and what was skipped as N/A. Do not start implementing from that log unless the user asks.
当指定范围已经确定且 frontier 为空时，本轮会话结束：所有适用分支均已访问，没有任何内容仍被默认或忽略。
完成后，编写一份简短的 Decision Log：记录每个已作出的选择、你给出的建议，以及哪些内容因不适用而被跳过。除非用户提出要求，否则不要根据该日志开始实施。