MCU flashing integration
MCU flashing integration 表示项目通过 espflash 管理 ESP32 系列,通过 probe-rs 管理 STM32/其他 probe-supported MCU,并把这些 backend 接入项目配置或明确的本地操作入口。Topic token 使用可复用工程模式命名;espflash 与 probe-rs 作为具体工具名放在定义和证据里。 这个 Topic 关注的是“硬件操作入口可复现且可审计”。
- 硬件
- 工具
目录
Definition
MCU flashing integration 表示项目通过 espflash 管理 ESP32 系列,通过 probe-rs 管理 STM32/其他 probe-supported MCU,并把这些 backend 接入项目配置或明确的本地操作入口。Topic token 使用可复用工程模式命名;espflash 与 probe-rs 作为具体工具名放在定义和证据里。
这个 Topic 关注的是“硬件操作入口可复现且可审计”。它不只是记录某个 README 命令,而是要求项目把 MCU target、chip、artifact、probe/serial selector、reset/monitor 策略和后端差异写成可维护配置或 operation record,减少 Agent 在真实硬件上猜命令的风险(projects/loadlynx.md、projects/pd-sink-stm32g431cbu6-rs.md)。
When to use
当项目 snapshot 中该模式影响运行、交付、硬件操作或跨仓库复用时使用;如果只是一次性脚本或历史残留,先保留在项目笔记里,不急着提升为 Topic。
当项目需要自动 flash、monitor、reset、串口日志、probe-rs attach、ESP32 bootloader 或多 target 切换时使用。若仓库只有 firmware 代码但没有可复用 flashing 入口,应先在项目快照中记录证据缺口,而不是声称已经完成集成(projects/flux-purr.md、projects/pd-sink-stm32g431cbu6-rs.md)。
Habits / defaults
- 每个 MCU target 明确
backend、chip、artifact_elf和 backend-specific 参数。 - ESP32 target 默认记录 log format、baud、reset 策略;STM32 target 默认记录 SWD、speed、connect-under-reset。
- 真实硬件操作前要确认 selector cache 和串口/probe 归属,避免多 Agent 争用。
- 把 flashing 入口和设备项目配置绑定,让 Agent 能从项目资料定位 target,而不是要求用户重新解释板子、端口和 artifact(
projects/loadlynx.md、projects/pd-sink-stm32g431cbu6-rs.md)。 - 对双 MCU 或多板项目,默认把每个 target 的职责写清楚。ESP32-S3 UI/联网侧与 STM32G431 电源/模拟侧不能共享一套模糊命令(
projects/loadlynx.md)。 - 默认在操作前复核 artifact 是否来自当前源码和目标芯片;旧 ELF、错误 profile 或跨 target 复用 build 目录都会让 flash 看似成功但设备行为错误(
projects/loadlynx.md)。
Reference implementations
projects/loadlynx.md:ESP32-S3 digital + STM32G431 analog 双 target,适合验证每个 target 的 backend、chip、artifact 和 selector 是否独立可追溯。projects/flux-purr.md:ESP32-S3 frontpanel target,适合说明 firmware build、flash/monitor 记录和 host preview 不能共享模糊的验证结论。projects/pd-sink-stm32g431cbu6-rs.md:STM32G431 USB PD sink/PowerVista firmware,适合验证 probe-rs、artifact 和板级风险如何进入项目记忆。projects/mains-aegis.md:设备项目中 firmware、Web UI 与 docs 共存,适合说明 flashing integration 只是硬件操作链路的一环,不能替代产品行为验证。
Failure modes
- 把 flashing 命令散落在 README 或 shell history,后续 Agent 会误操作。
- chip id 写错可能导致连接失败或刷错目标。
- 日志/monitor 生命周期没有统一管理,会让硬件调试难以复盘。
- 多 Agent 同时操作同一串口或 probe 会造成不可预测失败;执行前必须确认资源归属,并在项目配置或操作记录中保留 selector 证据(
projects/loadlynx.md)。 - 把 CI build 通过误认为 flash 成功,会污染硬件项目状态。项目快照应区分 compile proof、flash proof 和真实设备行为 proof(
projects/loadlynx.md、projects/flux-purr.md)。
Evidence index
projects/loadlynx.mdprojects/flux-purr.mdprojects/pd-sink-stm32g431cbu6-rs.md
相关内容
Flux Purr
项目实践Flux Purr 是 embedded firmware + React control console 的设备 mono-repo。README.md 将仓库组织为 firmware/、web/、tools/flux-purr-devd/、docs/specs/、docs/hardware/、.
IsolaPurr USB Hub
项目实践IsolaPurr USB Hub 是带 USB-C 上行、USB-C 下行和 USB-A 下行的有源 USB 集线器/供电模块。README.md 记录 CH334P、URB2405S、CH224Q、TPS55288、SW2303/IP6557、DC5025 输入和理想二极管 OR-ing 等硬件方案,说明这是硬件/固件/Web/文档一体的 device mono-repo。
IsolaRail
项目实践IsolaRail 是当前 V3 四口 USB hub 的 owner-facing control plane 仓库。README.md 把它定义为 ESP32-S3 + CH335F + M24C64@0x50 + EN1..
LoadLynx
项目实践LoadLynx 是 STM32G431 + ESP32-S3 便携式电子负载。README.md 明确采用分体式架构:STM32G431 执行快速电流/功率闭环与保护,ESP32-S3 负责 UI/Wi-Fi/OTA/记录/标定及上位机桥接。这是典型 device mono-repo,不能只从一个 firmware 目录理解。
Mains Aegis
项目实践Mains Aegis 是 UPS / power-management 设备 mono-repo:它把硬件行为文档、ESP32-S3 固件、Web 管理界面、docs-site、前面板/音频预览工具和质量门禁放在同一个维护边界里。PRODUCT.md 明确把 Web 管理界面定义为面向多设备 UPS 的只读运维控制台,首要目标是让维护者快速判断设备健康、离线、后备供电和告警状态,而不是做可写控制台。
MCU Agentd
项目实践MCU Agentd 是可配置 MCU 管理工具,包含每项目 daemon/CLI mcu-agentd 和用户级辅助 daemon mcu-managerd。README.md 明确它通过 mcu-agentd.toml 定义多个 MCU target,并基于 espflash 与 probe-rs 执行操作,当前 v1 只支持 ELF artifact 和固定策略。
PowerVista PD Sink Firmware
项目实践PowerVista PD Sink Firmware 是 STM32G431CBU6 上的多功能实时电源监控与 USB PD sink 固件。README.md 的项目名是 PowerVista,功能清单包括电压/电流/功率实时显示、PPS request、保护策略、重力感应旋转和配置存储;catalog slug pd-sink-stm32g431cbu6-rs 只是仓库 ID,不应作为人类标题。