星核火花赛车科技

进入商城

分类： 技术干货

  • EdgeForge：嵌入式侧端框架的自编译方案

    结论：EdgeForge 的「自编译」不是把 Clang 塞进 MCU，而是让设备自己把一份受限描述语言编译成字节码——基础示例的 88 字节 EFIR 在端侧生成 36 字节 EdgeVM 代码，且与 Node 参考编译器的输出逐字节一致。这样页面、规则、阈值、迟滞与窗口统计的改动都不再需要重刷整机固件，只有外设驱动、协议栈、VM 漏洞修复才走固件更新。

    为什么不在 MCU 上放完整 C/C++ 编译器

    因为 ESP32-S3、STM32 和 RP2040 的内存、存储和安全边界不适合长期携带完整 Clang / GCC、系统头文件、链接器和动态加载器。

    源方案书写得很直接：即使勉强运行，编译延迟、RAM 峰值、ABI、恶意代码和崩溃恢复都会使产品难以量产。EdgeForge 采用的是受限自编译——把链路切成「描述语言 → 检查 → 平台无关 IR → 能力链接 → 字节码 / Wasm / 预审原生模块 → 签名安装」，MCU 端只负责最后一段：把 IR 快速编译成 EdgeVM 字节码并执行。复杂算法交给 Linux、Android 上的 Wasm，或可信工业场景下的预审原生模块。

    AI 在这个框架里的输出也是描述语言，而不是代码：AI 不能直接输出设备可运行的 C、JavaScript、Shell 或原始总线指令，只能产出 EdgeSpec 提案。即使不启用大模型，Studio 的表单和规则编辑器也能生成完全相同的 EdgeSpec。

    哪些改动从此不必重刷固件

    因为框架把「应用功能」与「平台能力」分开，前者可动态编译，后者仍需固件或系统更新。这条边界是承诺成立的前提：

    可动态编译（不重刷固件） 仍需固件或系统更新
    页面与组件、信号绑定、单位显示 新外设驱动
    阈值与迟滞、窗口统计、数据记录策略 新无线协议栈
    经过允许的信号解码、设备选择、本地提醒 底层 CAN / USB / 显示驱动
    有限状态机、经过审核的 Wasm 算法 VM 漏洞修复、加密库更新、启动链与电源管理逻辑

    所以正确的宣传口径是「多数应用功能无需重编译整机固件」，而不是「以后永远不更新底层软件」。这个边界与 OBD AI 插件化平台 里给出的分层判断是同一逻辑：能否插件化，取决于宿主是否已提供相应底层原语。

    从 EdgeSpec 到 36 字节字节码：链路上各产物有多大

    因为「链路短」是可以量化的，源方案给出了各阶段的真实字节数，全部来自当前原型而非估算：

    场景 EFB 功能包 EFIR 链接 IR EdgeVM 字节码 签名 EFP
    基础示例应用（ESP32-S3） 2,519 字节 88 字节 36 字节 3,421 字节
    Studio 四规则草稿 3,715 字节 212 字节 132 字节 4,742 字节
    8 样本平均窗口规则 2,294 字节 58 字节 20 字节 —

    关键在于端侧编译器的工作方式：它使用定长头与任务表，表达式只包含有限 opcode，事件动作使用索引表；ESP32、STM32 和 RP2040 的 C99 编译器在调用者提供的固定缓冲区内把 EFIR 转成字节码，不申请堆内存，也不携带 C/C++ 预处理器、汇编器或链接器。原生测试证明端侧输出与 Node 参考编译器逐字节一致。当前 EFIR 已覆盖基础表达式、信号有效性、本地事件、带固定状态槽的 GATE 持续条件、数值型低阈值 / 高阈值迟滞，以及固定样本数的 window_avg / window_min / window_max；通用状态变量与 UI 更新算子仍待扩展。

    包格式方面，当前 .efb v2 为「24 字节头 + 规范 JSON manifest + 二进制 EIDX v2 运行索引 + EdgeVM 字节码」。JSON manifest 供 Studio、诊断与审计使用，而 MCU 启动关键路径只需解析定长的 EIDX 记录，不需要携带通用 JSON DOM；加载器不使用堆内存，可验证包头、记录范围、字符串范围、任务连续性、UI 重叠与边界、栈深、跳转边界、信号 / 事件索引、opcode 与指令预算。

    EdgeVM 靠什么把插件关在笼子里

    因为「小体积」和「不拖垮宿主」是两件事，所以 EdgeVM 的设计目标是 C99 可移植、核心运行时保持在几十 KB 以内、使用固定或受限栈、不做运行时任意堆分配。每次任务有指令预算、墙钟预算和输出预算；非法 opcode、越界跳转、栈溢出和包截断会立即停止当前插件；关键采集线程不执行用户字节码。

    持续条件与迟滞是最能体现「有界」的两个机制。每条 pipeline 使用一个固定状态槽：条件连续成立 for_ms 后才通过；repeat_ms = 0 时本次条件保持期间只触发一次，大于 0 时按该间隔重复。低阈值在 < threshold 时进入、到 >= threshold + hysteresis 时恢复；高阈值在 > threshold 时进入、到 <= threshold - hysteresis 时恢复。使用迟滞的包要求 Host API 1.2.0，使用窗口的包要求 signal.window 能力与 Host API 1.3.0，旧包继续兼容。Studio 的四规则草稿里，四条 pipeline 均记录 for_ms = 3000、repeat_ms = 0、hysteresis = 0.1 bar。

    调度器负责合并相同信号订阅、按信号实际频率运行规则、超额时跳过低优先级任务而不阻塞采集，并记录执行耗时、峰值栈、失败原因与连续超限次数；多次越限后禁用插件并回退到已知可用版本。包卸载、A/B 切换或重新加载时必须清零状态槽，不能让旧版本的持续时间状态泄漏到新版本——这是「有界执行」之外容易被忽略的一条。

    五个平台的目标构建已经闭环，但还没有上实板

    因为「编译链接通过」与「实机运行通过」是两回事，源方案把两者分得很清楚。当前状态是：本地 Studio、通用 MCU Host 及五个平台的软件目标构建链已经闭环。

    平台 工具链 构建产物 余量 / 边界
    ESP32-S3 ESP-IDF 5.3.2 / Xtensa ESP GCC 13.2.0 应用 .bin 550,112 字节（镜像内容 550,004 字节） 1.5 MiB factory 分区剩 1,022,752 字节（约 65%）
    RP2040 Pico SDK 2.1.1 / Arm GNU Toolchain 14.2.1 .bin 85,776 字节，.uf2 172,032 字节 功能包预留区自 0x101b2000 起，按 256 字节块补齐后余 1,691,648 字节
    STM32F429ZI STM32CubeF4 HAL / Arm GNU Toolchain 14.2.1 BIN 37,024 字节，RAM 使用 49,776 字节 到 Bank 2 起点 0x08100000 余 1,011,552 字节
    Linux ARM64 AArch64 Linux，-O2 与最高警告等级 16 个对象链接为 4,798,248 字节完整 ELF 待 ARM64 目标机运行验证

    ESP32-S3 侧的余量值得单独看：DIRAM 使用 151,255 / 341,760 字节，专用 16 KiB IRAM 段只剩 1 字节；EdgeForge 组件占静态 RAM 60,808 字节、链接 Flash 31,733 字节。这些数字说明片内 RAM 是真正的约束——加入显示、触摸或 Wi-Fi 后必须重新链接，并在实板测量最小空闲堆、任务高水位、连接恢复、总线错误、刷新抖动与 CPU 占用。

    通用 MCU 侧的做法是不为每个芯片重写加载逻辑：STM32、RP2040、RP2350 与其他 C99 MCU 共用 hosts/mcu-common 无堆 Host，平台层只实现五类接口——双槽 Flash 与 96 字节事务状态记录、SHA-256 / Ed25519、UART / USB / BLE EdgeDeploy、单调时钟、具体传感器与显示驱动。启动链固定为「读取活动 A/B 槽中的 EFP → 校验目标 / Host API / 能力 / 摘要与签名 → 验证 EFB / EIDX → 解析 EFIR → 设备内编译到 RAM → 逐字节核对与签名 EFB 一致 → 执行」，任何不一致都拒绝加载。RP2040 的原生生命周期测试已安装三个签名 EFP，把 88 字节 EFIR 编译为 36 字节代码，输入 tpms.fl = 2.1 bar 触发低胎压事件并生成 4 个 UI 组件。

    必须说清楚的边界：ESP32-S3、STM32F4、RP2040 的实物烧录与启动验证尚未完成，Linux ARM64 目标机运行、EdgeDeploy 的真实 UART / BLE / USB 传输、掉电工装、具体 LCD 控制器与触摸、Android 实机兼容性也都在未完成清单里。自动测试当前共 46 项，本机 44 项通过，Linux POSIX 与 SocketCAN vcan0 两项集成测试在非 Linux 主机按条件跳过。显示链路的帧率口径可对照 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪，其中说明了 30 FPS 属验收目标而非硬件事实。

    签名只证明来源，不代表授权

    因为签名解决的是「包有没有被篡改」，而权限解决的是「这个包被允许做什么」，两者不能互相替代。当前 EFP v2 同时包含 EFB 与 EFIR，Ed25519 签名覆盖包头、ESEC 安全索引、审计 JSON 以及两个产物；ESEC 为 MCU 提供不依赖 JSON 的目标平台、应用版本、发布序列、密钥 ID、最低 Host API、能力清单和两个 SHA-256 摘要。但框架明确规定，实际权限是五项的交集：

    包声明 ∩ 发布者权限 ∩ 用户授权 ∩ 设备能力 ∩ 平台策略

    也就是说，签名证明来源和完整性，不代表插件自动获得其清单中请求的所有权限。包状态用 active / candidate / last-known-good 三态管理，固件用 A/B 槽；升级过程任意断电点都要能恢复到确定状态，回退受最低安全版本限制，不能恢复已撤销的漏洞版本。设备适配器与用户功能包也分开：用户可以把已注册的胎压信号放到任意页面，但不能因为改页面而获得原始射频、任意 BLE 写入或 CAN 发送权限。采集设备选型与信号质量的口径可参照 SR-RaceBox 车载数据采集器；屏幕形态与可读性的取舍见 圆屏还是方屏：车载仪表的显示形态该怎么选。

    常见问题

    EdgeForge 的「自编译」是要在 ESP32 上跑 C 编译器吗？

    不是。MCU 端只把平台无关 IR 编译成 EdgeVM 字节码，在调用者提供的固定缓冲区内完成，不申请堆内存，也不携带 C/C++ 预处理器、汇编器或链接器。完整 C/C++ 编译只在受控的构建服务或高性能平台上考虑。

    免重刷固件能免到什么程度？

    页面与组件、信号绑定、单位显示、阈值与迟滞、窗口统计、记录策略、经过允许的信号解码、有限状态机和经审核的 Wasm 算法都可以动态编译。新外设驱动、新无线协议栈、底层 CAN / USB / 显示驱动、VM 漏洞修复、加密库更新、启动链与电源管理逻辑仍需固件或系统更新。

    五个平台的构建都已经验证过实机了吗？

    还没有。当前完成的是软件目标构建链闭环，包括 ESP32-S3、RP2040、STM32F429ZI 与 Linux ARM64 的目标编译链接。ESP32-S3、STM32F4、RP2040 的实物烧录与启动验证，以及真实 UART / BLE / USB 传输、掉电恢复、具体 LCD 与触摸，均在未完成清单中。

    插件包签了名，是不是就拿到了清单里申请的全部权限？

    不是。实际权限取「包声明、发布者权限、用户授权、设备能力、平台策略」五项的交集。签名只证明来源和完整性，宿主必须独立拒绝所有未开放的操作。

    本文数据来自星核火花赛车科技内部 EdgeForge 自编译软件框架方案的 V1.4 稿（2026-09-21，状态为固定容量窗口统计、Studio 软件闭环、通用 MCU 自编译 Host 及五类常见硬件平台目标构建通过）。文中字节数、Flash / RAM 占用与余量均为该稿记录的原型构建结果，属软件目标构建证据，不证明开发板启动、掉电行为或实机传输；ESP32-S3、STM32F4、RP2040 的实物烧录与启动验证尚未完成。所述权限交集与实际授权行为以正式 SDK 与发布流程为准。

  • OBD AI 插件化平台：端侧解析为什么必须插件化

    结论：端侧解析必须插件化，因为车辆私有协议、界面布局与派生算法都属于高频变化项，用整机固件去覆盖它们，等于每改一条规则就要重编译、重烧录一次主机。可行做法是把变化频率不同的职责拆成五层，让协议包、规则包、界面包独立签名发布，固件只保留低频 OTA 通道。但插件不等于万能：数据若不经过 OBD 网关，装什么插件都读不到，这一点必须在上架前就声明清楚。

    为什么「整机重编译」模式撑不住车型差异

    因为一旦把应用逻辑编译进固件，任何一个信号解码的改动都会变成一次固件发布，而品牌、年款、地区、动力类型与 ECU 软件版本的差异是持续出现的。

    源方案书把「哪些能力可以动态升级」逐项列了出来，判断依据不是功能大小，而是宿主是否已提供对应的底层原语：

    改动类型 能否通过插件完成 必要条件
    新页面、布局、颜色、单位、辅助阈值提醒 通常可以 使用宿主提供的界面组件和信号
    新衍生指标、过滤、统计、异常检测 通常可以 算力、内存、数据源与准确性满足要求
    新 PID / DID 的解码定义 有条件可以 传输方式已支持，来源合法，请求模板经验证
    新诊断传输、加密接入、复杂状态机 可能需要固件升级 宿主缺少相应底层原语或安全接口
    新 CAN 控制器、引脚、显示驱动 通常需要固件及可能的硬件改动 插件不能补齐缺失的电气接口
    ECU 写入、制动或动力控制 不在本方案插件权限内 不通过普通用户插件开放

    这里必须纠正一个常见误解：插件化不等于「未知车型插上就能自动破解全部协议」。未知数据可能根本不经过 OBD 接口，可能受安全网关限制，也可能没有合法可用的定义；硬件能力、驱动、运行时漏洞和新宿主接口仍然可能需要固件升级。所以方案书给出的正确承诺是「多数应用功能无需重编译整机固件」，而不是「以后永远不更新底层软件」。

    插件化把职责拆成五层，各自按不同频率更新

    因为不同职责的变化频率相差几个数量级，把它们绑在同一次发布里才是问题的根源。方案按更新频率重新切分，低频层保留固件通道，高频层走签名包：

    层次 长期职责 主要更新方式
    硬件与稳定底座 电源保护、CAN 驱动、诊断调度、看门狗、安全存储、升级恢复 低频固件 OTA；硬件变更仍需重新设计
    协议与数据层 标准 OBD、经过验证的私有信号定义、单位与数据质量 签名协议包；超出解释器能力时更新固件
    功能插件层 计算指标、辅助提醒、记录策略、仪表布局 声明式规则为主，按平台增加 Lua 或 Wasm
    AI 与交互层 理解需求、组合已知能力、生成候选插件、解释限制 手机、Linux 或云端模型服务；可独立升级
    治理与分发层 协议权利来源、验证证据、发布签名、授权、灰度、撤回 手机应用与可选服务平台

    首个产品的建议形态是「ESP32-S3 仪表 + 手机伴侣应用 + 声明式插件运行时」：仪表负责稳定采集与执行，手机负责自然语言交互、插件编辑、验证编排和分发；联网时可选云端 AI，离线时仍可执行已安装插件和手工创建规则。首期交付限定为：标准 OBD 数据、少量授权车型协议包、用户自定义页面、基于已知信号的规则提醒、插件签名与权限检查、故障回退与基础固件 OTA。首期暂缓包括任意 C/C++ 动态代码、行驶中主动探测未知诊断服务、由模型直接发送 CAN 帧、刷写 ECU、清故障码与执行器测试。

    六个核心模块，以及它们明确不授予的能力

    因为安全边界不能只在文档里写「不开放」，而要在模块职责上就切掉能力。方案把整机拆成六个模块，每个模块都写明它不拥有什么：

    模块 负责内容 不授予的能力
    Vehicle Gateway CAN 收发、ISO-TP、标准 OBD、经批准的诊断读取、请求预算 不接受插件直接传入任意 CAN 帧
    Signal Service 标准名称、单位、时间戳、来源、质量、订阅与缓存 不把缺失或超时值伪装为零
    Plugin Runtime 规则执行、状态隔离、超时控制、受限算法 不直接访问驱动、密钥、任意地址
    Plugin Manager 校验、依赖解析、兼容性、原子激活、回退、卸载 不接受无来源认证的安装包
    AI Orchestrator 需求转配置、引用协议资料、候选实现和测试 不修改策略、签名根或自行授予权限
    Release Service 审核、签名、车型发布、灰度与撤回 不把模型输出直接当作可信版本

    配套的稳定信号接口规定：每个信号至少携带 signal_id、数值、单位、来源 ECU / 协议包、采集时间、单调时钟时间、有效期、质量状态与错误原因；质量至少区分 valid、stale、unavailable、error，分析候选数据另标 experimental。标准信号与厂商信号使用不同命名空间，例如 obd.engine_rpm 与 vendor.example.transmission_oil_temp，避免同名不同义。这与站内 OBD-II PID 入门：车速 0x0D 为什么是整数 里讲的「样本必须带元数据才能判断可信」是同一套约束。

    为什么「只读」业务仍然会向车辆发送报文

    因为被动监听在 OBD 接口上通常只能看到很少数据，要拿到标准 PID 就必须主动发请求，而请求本身会占用总线并消耗 ECU 的处理时间。

    产品标称「只读」意味着不允许状态改变类业务，不意味着物理上不发送 CAN 帧。因此宿主必须统一执行请求合并、每 ECU 并发限制、重试上限、总线与响应时间监测和休眠控制。方案特别提醒：总线平均占用率低并不代表 ECU 负载安全，所以「请求预算必须经过具体车型验证，不能用一个全车型统一比例作为安全证明」。遇到超时、bus-off、异常响应、供电下降或诊断冲突迹象时，应停止新增请求并退避；外部诊断仪并不总能被可靠识别，产品还需要提供明确的维修停用模式。

    不是所有缺失数据都能靠插件补上

    因为「没有数据」有多种成因，只有其中一部分属于插件的能力范围。方案把成因和对应限制列成一张表，避免把工程限制伪装成产品能力：

    情况 可采用的方法 必须呈现的限制
    标准 OBD 已定义且车辆支持 查询受支持项，按标准解析 支持情况与刷新频率因车辆而异
    已有合法厂商定义 整理为协议包，测试车型与 ECU 版本 协议适用范围和权利范围受限
    数据可从已知信号推算 提供估计值与适用条件 明确标注估计，不能冒充传感器实测
    仅有可访问的未知报文 授权记录、离线分析、对照验证 相关性不代表信号含义被证实
    数据不经过 OBD 网关 获取正式接口、授权网关支持或专用硬件 单靠插件无法创造物理访问路径
    需要安全网关或受保护会话 走厂商允许的接入机制 用户同意不等于获得解锁或绕过权限

    此外，方案区分了三种彼此独立的「同意」：安装功能的同意、访问车辆的授权、以及协议与数据权利（协议资料的使用与再分发权，采样、上传、保留与训练数据的许可）。车主允许安装，不自动覆盖厂商协议权利，也不自动允许绕过安全网关。

    插件靠什么被约束住：宿主管线、资源预算与权限交集

    因为仅靠签名无法限制插件行为，所以约束分三层落地：清单声明、宿主独立拒绝、资源配额。方案给出的清单数据契约里，一条冷却液提醒插件声明 state_bytes: 16384、max_rule_nodes: 64、max_eval_ops: 256、min_interval_ms: 1000；宿主实际授权取「用户批准、发布者权限上限、设备策略、车型能力、清单请求」的交集，清单里的 false 或上限声明不是自我证明，宿主必须独立拒绝所有未开放操作。

    ESP32-S3 档的资源起始预算写得很克制，且被明确标注为实验上限候选值，必须结合显示、无线、TLS、CAN 与 OTA 同时运行的峰值收紧或调整：同时启用 3–5 个简单插件；单个规则包不超过 128 KB；每个插件的规则状态先限制为 16–64 KB；所有插件计算占用总 CPU 的预算先设为不超过 10%。界面侧建议 UI 数据刷新目标先按 5–10 Hz 设计、慢变化的温度信号按约 1 Hz 评估，但实际请求频率受车型能力限制，不能机械套用。

    验收门槛同样给了可核查的数字：安装、试运行、激活和迁移阶段注入断电，首轮累计至少覆盖 100 次故障注入，量产前扩展为自动化长期测试；并完成至少 72 小时组合功能稳定性测试。该测试不替代量产寿命试验。分阶段计划按约 5 人核心团队估算，总历时约 16–20 周达到受控试点；核心投入约 80–100 人周（约 18.5–23 人月），按每人月 3–6 万元全成本假设粗算，核心研发人力约 56–138 万元——方案书注明这是预算模型示例，不是报价，且不含硬件试制、协议许可、认证与云服务。

    四档硬件参考配置从 ESP32-S3（双核最高 240 MHz、片内 SRAM 512 KB，建议选配 16 MB Flash 与 8 MB PSRAM）一路延伸到手机级（建议 8–16 GB RAM、64 GB 以上存储）。方案强调「中高性能 MCU」不是单纯比主频更高，而应比较片内可用 RAM、MPU、CAN FD、缓存与 DMA 限制、图形加速和实时性；外部 RAM 也不自动等价于实时任务可用的片内 RAM。采集侧若需要对照方案，可参考 SR-RaceBox 车载数据采集器；数据回传与云端分析可对照 SR-Telemetry 实时遥测云。计时链路本身为什么不能用 GPS 替代 OBD 车速，另见 OBD 零百加速计时：为什么手机测不准，仪表该怎么算。

    常见问题

    「AI 插件化」是不是意味着未知车型插上就能自动破解？

    不是。方案明确不宜承诺「未知车型插上即自动破解全部协议」。未知数据可能不经过 OBD 接口、可能受安全网关限制，也可能没有合法可用的定义；插件无法创造物理访问路径，缺失时必须明确提示不可用，或走经授权的适配申请。

    插件能升级到什么程度，哪些还必须刷固件？

    页面、布局、单位、阈值提醒、衍生指标、窗口统计和经过验证的 PID / DID 解码通常可以通过插件完成；而新诊断传输、加密接入、复杂状态机、新 CAN 控制器 / 显示驱动、驱动与内核漏洞修复，通常需要固件升级。因此平台必须长期保留固件 OTA 通道。

    为什么标称「只读」的仪表还会向车辆发报文？

    因为被动监听拿到的数据很少，读取标准 PID 必须主动发请求。标称「只读」指的是不允许状态改变类业务，不代表物理上不发送 CAN 帧。请求需经宿主统一调度，且请求预算必须按具体车型验证。

    AI 在平台里能决定什么，不能决定什么？

    AI 可以做需求理解、生成结构化候选规则、解释数据为何不可用、生成边界测试；但不能决定车辆请求白名单、信任根、权限上限、密钥使用和协议量产签名。AI 的输出必须经过独立确定性校验器，不能靠另一个模型说一句「安全」就通过。

    本文数据来自星核火花赛车科技内部 OBD 仪表 AI 插件化平台方案的 V1.0 稿（2026-09-13，架构规划与立项评审状态）。文中的内存、Flash、CPU 占用、插件数量与界面刷新频率均为方案给出的选型建议或实验上限候选值，不代表已完成样机验证；约定「首期暂缓」的能力不在本方案插件权限内。分阶段历时、人力与费用口径为题述假设下的预算模型示例，不是报价，也不构成任何交付承诺。

  • 赛道仪表的信息架构：从圈速到告警的设计顺序

    结论：赛道仪表的信息架构顺序是「先定要显示什么，再定怎么排」：以真实赛车仪表的数据排布与告警逻辑作骨架，以赛车游戏 HUD 的夜间对比与字号层级作视觉语言。同一套架构套用到五个画布时，尺寸只改变信息密度，不改变信息优先级——圈速与告警永远优先。

    信息架构先于视觉：先排序，再排版

    做赛道 HMI，容易一上来就纠结配色和圆表外形，但真正要先定的是信息优先级。kno 赛道 HMI 原型的做法是分成两层：以真实赛车仪表的通用做法作信息架构骨架（数据怎么排布、告警怎么触发），以赛车游戏 HUD 的可读性作视觉语言（夜间对比、字号层级、动效层次），最后产出同风格的原创界面。

    这个顺序的意思是：先把「哪些数据必须常驻、哪些只在告警时出现」排清楚，再决定色板和栅格。反过来先定视觉，往往会在改配色时连带改掉信息层级。

    五个画布，一套架构，信息密度不同

    原型覆盖五块屏，逻辑分辨率全部按横屏设计。尺寸变的是「能放多少格」，不变的是「谁在最前面」。

    画布 逻辑分辨率 布局要点 承载的信息
    1.64 寸 456×280（物理面板原生 280×456 旋转） 极简计时：黑底、超大数字、TOTAL / CURRENT 双格，不含圆表；底部为 0—60 与 0—100 进度条 单次计时结果
    3.5 寸 480×320（物理面板原生 320×480 旋转） 顶部 LED 换挡灯条（绿 → 琥珀 → 红）＋ 左侧转速弧 ＋ 右侧大车速 ＋ 下方四格 单表 + 车辆状态（LAP / 圈速 / 水温 / 油压）
    4.3 寸 800×480 左上圈速栈（LAP / 本圈 / 最快圈 / DELTA）＋ 中央双圆表（GPS 速度 + 发动机转速）＋ 右侧告警状态柱 ＋ 底部辅助条 赛道分区
    5.0 寸 1280×720 同 4.3 分区，底栏多一格胎压 赛道 + 数据源 + 胎压
    3.97 寸电子纸 800×480 白底黑字、大 tulip 路线图、简短中文路书，不套用彩屏主题 离线路书

    注意 4.3 与 5.0 寸的中央双圆表：两表半径与圆心由可用区的宽和高度共同推导，目的是保证宽屏下不重叠。这是信息架构落到几何约束的一步——不是把两张表并排贴上去就能成立。5.0 寸底栏多出的胎压格也不是简单加一行，而是因为 1280×720 比 800×480 宽得多，才有余量在不牺牲主读数字号的前提下多放一格，属于宽屏专属的信息密度。

    告警为什么必须放在固定的状态区

    告警的位置和颜色必须固定，驾驶者才能用余光判断，而不必去读具体数字。

    在 3.5 寸上是顶部换挡灯条加下方四格：告警时水温与油压两格转红并描红边。在 4.3 与 5.0 寸上是右侧独立的告警状态柱，固定显示油压、水温、电压、OBD 四项。位置不随数据变化而移动，是余光可读的前提；如果告警图标会「跳」到别处，余光就失效了，只能回到逐字阅读，反而更慢。

    主题只改视觉语言，不改信息架构

    五套主题共享同一组模拟 OBD 数据、计时与告警状态，切换主题不重置回放。也就是说主题是一层皮，不是一套新逻辑。

    kno 在原有的 JDM / 赛道 / 复古 / 霓虹四套主题基础上，新增第五套「厂商（pro）」并设为默认。差异集中在配色、字形与动效：JDM 是密刻度、实体指针与珊瑚红/湖绿实色色块；赛道版强调朴素的信息层级；复古版采用浅灰机械表盘、细刻度与红针；霓虹版采用大数字、分段转速／速度条和状态矩阵。它们改的是视觉语言，数据优先级始终一致。电子纸路书则完全不套用彩屏主题，也不受主题切换影响。

    设计令牌：pro 主题的色板与用途

    把颜色写成有用途的令牌，而不是随手取色，是让五块屏和五套主题保持一致的关键。pro 主题的令牌如下：

    令牌 色值 用途
    背景 #05080A 夜间主屏
    面板 #0D1417 卡片、次级底条
    抬升面 #131D21 强调格（如最佳成绩、告警格底）
    描边 #1E2B31 卡片边框
    分隔线 #16242A 字段分区
    主读数 #EDF3F4 车速、转速、时间
    次级文字 #93A7AC 标签、单位
    三级文字 #5B6E75 指标名、弱化信息
    青色 #4FD1C5 最佳圈、速度弧、强调
    琥珀 #F5B942 DELTA、预警、转速弧
    绿色 #7CD98A 低转换挡灯、正常状态
    红色 #FF5A4E 高转灯、报警
    电子纸 #F1F1EA / #202A2A 单色静态路书

    标签统一加字距（letter-spacing），数值走 Bahnschrift 类窄无衬线字体，目的是在余光条件下提高字符可辨识度。这条规则和告警固定区是同一套逻辑：一切为「扫一眼就能读」服务。

    原型能证明什么，不能证明什么

    kno 是信息架构与视觉语言的验证原型，其中的 OBD、油压、档位、胎压等数值均为明确标注的模拟数据。

    它的自动校验用 Playwright 遍历 5 块屏 × 5 套主题 × 全部副视图，逐项检查：SVG viewBox 是否为各板原生像素尺寸；所有 <text> 元素是否越出画布（用 getBBox() 逐项检测）；SVG 内容中是否泄漏 undefined 字符串；默认主题是否为 pro、主题切换是否生效；以及 OBD 回放推进、计时完成、断连状态、路书翻页、移动端横向溢出等交互状态。

    但边界必须写明——该原型不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度；电子纸的刷新能力与残影没有在浏览器中模拟；预览使用的是系统字体，固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界；1.64 的横屏旋转与触摸映射尚待实机验证；圈速、侧向 G、胎压等数值为示意值，档位与油压尚无车型适配，实机须接入受保护的 OBD 网关。显示链路的帧率约束可参考 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪。

    还有一条本轮的明确限制：新增的「厂商」主题没有对照编号参考图逐像素比对。参考图（RaceLogic / AiM MXS / PLEX SDM / MoTeC / Forza / iRacing / SimHub / RaceLab 等）在本轮只以文字描述的形式提供，图片文件不在工作区内，因此该主题是按描述建立的信息架构与原创视觉，不声称完成了逐图参考分析。所有图形、文字与布局均重新绘制，不使用任何参考品牌的 logo、商标字体或截图素材。相关选屏与形态判断，另见 圆屏还是方屏：车载仪表的显示形态该怎么选；数据落地侧可对照 SR-RaceBox 车载数据采集器。

    常见问题

    赛道仪表的显示顺序应该怎么定？

    先定信息优先级，再定排版。圈速栈与告警优先：圈速栈回答「这圈跑得怎么样」，告警区回答「车还能不能跑」。在此之外的信息（水温、电压、胎压）才按屏幕尺寸铺开。

    5.0 寸的底栏为什么比 4.3 寸多一格？

    因为宽屏有余量。5.0 寸逻辑分辨率 1280×720，比 4.3 寸的 800×480 宽得多，因此底栏可以多放一格胎压作为宽屏专属的信息密度，而不必牺牲主读数的字号。

    电子纸路书为什么不套用彩屏主题？

    因为用途不同。电子纸是黑白静态介质，用于离线阅读路书，不承担实时告警，所以采用白底黑字、大 tulip 路线图与简短中文路书，也不受彩屏主题切换影响。

    kno 原型能直接用于固件吗？

    不能直接移植。原型用系统字体渲染，且不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度。固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界，并完成实机验证。

    本文数据来自星核火花赛车科技内部赛道 HMI 原型项目（kno）的《赛道 HMI 原型（kno 副本 · 统一厂商风）》README（2026-10 版）。原型中除设计令牌与分辨率外的数值均为明确标注的模拟数据；「厂商」主题未做逐图参考分析，参考图仅以文字描述形式提供。原型不构成对 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度的验证。

  • OBD-II PID 入门：车速 0x0D 为什么是整数

    结论：OBD-II 标准 PID 0x0D（车速）返回的是整数 km/h，最小刻度就是 1 km/h，所以基于它做零百计时天然带约 1 km/h 的量化误差。真正决定成绩的不是界面刷新率，而是状态机在收到响应的那一刻锁定的时间戳——起点、60 km/h、100 km/h 三个点，都是「首次收到满足条件的样本」的接收时刻。

    为什么 0x0D 返回的是整数

    0x0D 是 OBD-II 的标准车速 PID，源文档口径明确写为「返回整数 km/h」。这意味着读回来的永远是整数，不会出现 60.5 km/h 这样的值。按 OBD-II 标准的通用定义，该 PID 为单字节量，以 1 km/h 为步长，值域覆盖 0–255 km/h（此值域属行业通识，非本项目实测数据）。

    整数输出带来的直接后果是：任何比 1 km/h 更细的门槛，都无法「直接读到」，只能靠推导。这一点决定了后面所有计时逻辑都要围绕「整数刻度」来设计，而不是围绕理想中的连续速度曲线。

    一次车速读数要走完的链路

    从主机发出请求，到拿到一个可用于计时的车速样本，中间要经过网关与总线，每一环都会给时间戳添上延迟。因此本项目要求每条车速样本保存六项元数据，缺一项就无法判断该样本是否可信。

    样本字段 用途
    原始响应 保留网关返回的原始字节，便于事后回溯
    解码值 把原始响应按协议换算成 km/h 后的数值
    请求发出时间 与接收时间一起算出单次请求的往返延迟
    响应接收时间 作为计时时间戳的基准
    网关状态 判断该样本是否来自可用、可信的链路
    单调时钟时间戳 避免系统时间被调整时影响计时差值

    必须强调：记录下的时间戳是 OBD 响应接收时刻，不是 ECU 的实际采样时刻。从 ECU 采样到主机收到响应之间，存在请求往返延迟和网关额外延迟，主机无从得知 ECU 精确的采样瞬间。所以计时精度首先受链路延迟约束，而不是受显示系统约束。

    数据源上还有一条硬边界：首选「经受保护车载网关读取标准 PID 0x0D」；若某车型使用专用车速信号，必须在车型配置里明确协议、单位与量化精度，不能默认它和 0x0D 一样。

    为什么「0.5 km/h 起步阈值」在 0x0D 上做不到

    因为 0x0D 只返回整数，没有 0.5 km/h 这个刻度，源文档因此直接写明：「0.5 km/h 起步阈值」无法直接实现。

    理论上可以用 0→1 与 99→100 两点插值，把整数跳变反推成更细的时间点。但插值是否成立，取决于轮询周期、请求往返延迟和车型信号特性——这三项必须先实测记录，才能评估误差量级。因此首版方案的结论是：不插值，也不用 IMU 或 GPS 去填补样本。起点判定只能落在「首次收到大于 0 km/h 的有效样本」上，其误差上限与实际有效更新率直接相关。

    计时状态机：两个锁存点，一次异常即作废

    状态机的作用是把「什么时候算开始、什么时候算结束」写成可复核的规则，避免用显示刷新或人为判断来计时。首版状态机如下：

    状态 触发条件 动作
    IDLE 收到连续有效的 0 km/h 样本，覆盖至少 1 秒 进入 ARMED
    ARMED 首次收到有效且大于 0 km/h 的车速 记该样本接收时刻为 t0，进入 RUNNING
    RUNNING 首次收到车速 ≥ 60 km/h 记 t60；继续计时
    RUNNING 首次收到车速 ≥ 100 km/h 记 t100，锁存 t100 − t0 与 t60 − t0，进入 COMPLETE
    任意计时状态 网关断连、PID 不支持、响应超时、样本乱序或不可信 标记本次无效，保存原因，不显示成功成绩

    只有 t100 出现时才锁存成绩；中途出现任何一种异常，本次都判为无效并记录原因，不会输出一个「看起来正常」的秒数。这样做的代价是弃权率升高，收益是每一条显示出来的成绩都能追溯到具体样本。

    还有一个容易踩的坑：「连续 0 km/h」必须由多个有效样本构成，不能把网关断连期间保持的旧值算进那 1 秒。否则车辆其实没动，也可能因为缓存值而被误判为已就绪。

    采样频率不等于刷新频率

    界面上数字跳得快，不代表车速采样得快。界面刷新频率只是渲染频率，车速采样频率由 PID 的轮询周期决定，两者不是一回事。把二者混为一谈，就会用「看起来很流畅」掩盖「样本其实很稀疏」的事实。

    显示层需要提供五种状态：待连接、待起步、计时中、成绩、无效记录。并且历史最佳只收录有效、且带车型与数据源元信息的成绩——否则一次异常样本就可能被当成纪录留存下来。相关界面形态可参考 圆屏还是方屏：车载仪表的显示形态该怎么选，其中说明了为什么 1.64 寸这类 280×456 竖屏适合做成计时器。

    验收前必须实测的三组数据

    在把任何精度写进规格之前，以下三组数据是硬前提，缺任何一组都无法声称精度：

    1. 注入测试：向同一套解析与状态机灌入速度曲线，覆盖缓慢起步、瞬时跳值、重复帧、乱序、超时和中途失联，逐项核对状态迁移与时间戳是否符合预期。
    2. 实车链路记录：在目标车型上记录 PID 支持情况、有效车速更新率、请求往返延迟分布、网关额外延迟，以及计时期间的丢包率。
    3. 独立参照比对：用独立参考设备同步采集多次 0–100 加速，统计偏差与离散程度。

    最后必须说清楚：源文档中 ±0.05s 与「优于手机」是待验证目标。在没有实测证据之前，它们既不能写成已达到的精度，也不能作为宣传文案。计时链路的原理与数据源约束，另见 OBD 零百加速计时：为什么手机测不准，仪表该怎么算；采集侧的实现可对照 SR-RaceBox 车载数据采集器。

    常见问题

    0x0D 能读出小数点后的车速吗？

    不能。0x0D 返回整数 km/h，最小刻度就是 1 km/h。更细的分辨率只能靠插值推导，而插值是否可用取决于轮询周期与链路延迟，首版方案不做插值。

    为什么不能用 GPS 或 IMU 辅助计时？

    本项目里 GPS 不参与计时、插值或丢包补偿；QMI8658 只记录峰值 G 和 G 曲线，不参与起点、60 km/h、终点的时间戳判定。计时输入唯一来自 OBD 车速，以保证每一条成绩都能追溯到具体数据源。

    为什么时间戳不是 ECU 采样时刻？

    因为记录的是 OBD 响应接收时刻。从 ECU 采样到主机收到响应之间有请求往返延迟和网关额外延迟，主机无法得知 ECU 精确的采样瞬间，所以计时精度先受链路延迟约束。

    一次零百成绩什么时候才算有效？

    要同时满足两点：状态机按顺序经过 IDLE → ARMED → RUNNING，并在收到 ≥ 100 km/h 的样本时锁存成绩；且全程没有出现网关断连、PID 不支持、响应超时、样本乱序或不可信。任一异常都判为无效并保存原因。

    本文数据来自星核火花赛车科技内部车载仪表研究项目的《1.64 寸 OBD 零百计时规格》（2026-10 版）。PID 0x0D 的精度、延迟与插值可行性均以实车标定为准；文中的 ±0.05s 与「优于手机」为源文档标注的待验证目标，非已达成的精度指标。文中 0–255 km/h 值域为 OBD-II 行业通识，未经本项目实测，仅供理解整数刻度之用。

  • 车载 HMI 的 30 FPS：SPI 与 MIPI-DSI 显示链路差在哪

    结论：三块 ESP32-P4 板上的「30 FPS」是验收目标，不是已达成的硬件事实。3.5 寸走 SPI（ST7796），4.3 与 5 寸走 MIPI-DSI 2-lane，显示链路不同；按 16 位色深计算，30 FPS 的裸像素带宽需求依次约为 9.22、23.04、55.30 MB/s。三块板必须分别实测满屏与局部刷新，不能用同一套 HMI 代码推断性能相同。

    先把「30 FPS」定性：它是验收目标，不是硬件事实

    很多方案文档会把 30 FPS 直接写进规格，仿佛它已经实现。在这三块板上不能这么写：30 FPS 是验收目标，尚非硬件事实。3.5 寸的 SPI 显示链路与另外两块 MIPI-DSI 板子不同，需要分别测量满屏刷新、局部刷新、PSRAM 和总线占用。结论很直接——不能因为三块板跑的是同一套 HMI 代码，就推断三者的性能相同。

    三条链路的物理差异在哪

    SPI 是一条同步串行总线：时钟由主控产生，数据按位依次发送，通常还要和同一总线上的其他外设分时共享。MIPI-DSI 是显示专用的高速差分接口，用 1 条或多条 lane 并行传像素数据，天生为刷屏设计。这里的差别不在「谁更快」，而在它是共享总线还是专用通道。

    三块板的分工正好卡在这条线上：3.5 寸用 ST7796 走 SPI 并带 FT6336 触摸；4.3 寸和 5 寸用 MIPI-DSI 2-lane。把它写成一句话：3.5 寸是在一条通用总线上刷屏，另外两块是在专用通道上刷屏，后者的理论余量更大，但这只是起点，不是结论。

    裸带宽算一遍：每块板每帧要搬多少字节

    先算清楚工作量，再谈能不能做到。下表按 16 位色深（RGB565）与 30 FPS 上限计算，给出的是裸像素带宽需求——是推导值，不等于实测帧率，也不包含触摸、音频、网络占用的余量。

    板卡 原生像素 横屏 UI 目标 显示接口 每帧字节（16 位） 30 FPS 裸带宽需求
    ESP32-P4-WIFI6-Touch-LCD-3.5-EN 320×480 原生竖屏 SPI，ST7796 307,200 B（约 300 KiB） 约 9.22 MB/s
    ESP32-P4-WIFI6-Touch-LCD-4.3 480×800 800×480 MIPI-DSI 2-lane 768,000 B（约 750 KiB） 约 23.04 MB/s
    ESP32-P4-WIFI6-Touch-LCD-5-C 720×1280 1280×720 MIPI-DSI 2-lane 1,843,200 B（约 1.76 MiB） 约 55.30 MB/s

    这张表已经说明了为什么不能一把尺子量三块板：5 寸屏每帧要搬的字节是 3.5 寸的 6 倍。同样的动画效果，在 3.5 寸上可能宽裕，在 5 寸上就是六倍的搬运量。反过来说，「屏小就好做」也不成立——3.5 寸的接口是三者中最受限的一条。

    带宽够了仍然可能掉帧：PSRAM 与总线占用

    像素带宽只是必要条件，不是充分条件。真正决定帧率的是数据从哪来、经过谁、在哪里排队：如果帧缓冲放在 PSRAM，每一次刷屏都要从 PSRAM 读一遍再送到屏上，而 PSRAM 的访问带宽同时还要被其他任务分享。这就是为什么测量清单里必须包含 PSRAM 占用和总线占用，而不只是看屏的接口型号。

    局部刷新是另一条关键路径。赛道仪表上大量区域是静态的，只有转速、速度、G 值在变。只重绘变化区域，可以把每帧的搬运量降到远低于全屏的值；这一点对 SPI 链路尤其重要，因为它本来就没有多少余量。要求「满屏 30 FPS」和「界面 30 FPS 感受」是两件不同的事，验收时必须分开定义。

    尺寸不是唯一变量：三块板的其它差异

    把三块板当成「除了屏大小都一样」是常见误判。至少 Flash、触摸 IC 和板载传感器的记载就不同。

    项目 P4-3.5-EN P4-4.3 P4-5-C
    主控 ESP32-P4NRW32 + ESP32-C6 ESP32-P4NRW32 + C6-MINI-1 ESP32-P4NRW32 + C6-MINI-1
    PSRAM 32MB 32MB 32MB
    Flash 16MB 32MB 32MB
    触摸 IC FT6336（I2C） 概览页未列 概览页未列
    板载 IMU Wiki 未列 Wiki 未列 Wiki 未列
    资料完整度 概览页未列板载 IMU 概览页未列触摸 IC 概览页未列触摸 IC；采购记录为带摄像头版

    三点提示：其一，4.3 与 5 寸的触摸 IC 在概览页里没有列出，需要从官方资料继续查，不能凭经验填；其二，三块 P4 板 Wiki 均未列板载 IMU，G 值这类数据要外接传感器并单独核实；其三，外接传感器与车源同样要单独设计——芯片的 TWAI 外设不等于可直接接车载 CAN，车电保护、隔离收发器、车型信号和接插件都要另做。

    该测什么：四项，缺一不可

    1. 满屏刷新——全屏一次性重绘，记录实测帧时间与掉帧情况。
    2. 局部刷新——只重绘变化区域，观察帧率与画面一致性。
    3. PSRAM 占用——帧缓冲与素材常驻后的可用余量，以及刷屏期间的峰值占用。
    4. 总线占用——SPI 链路要单独看总线在刷屏、触摸、SD 之间的分时表现。

    四项都要在完整功能固件下测量，不能用只点屏的最小 demo 代替。现有 P4 共用工程目前只有模拟速度、转速和失联首屏，趋势、行程、诊断和真实 OBD 网关尚未开发，因此当下的帧率数据不代表整机表现。

    常见问题

    三块 P4 板现在能做到 30 FPS 吗？

    不能下这个结论。30 FPS 是验收目标而非硬件事实，需要按满屏刷新、局部刷新、PSRAM 和总线占用四项分别在完整功能固件下实测，目前没有可引用的实测数据。

    MIPI-DSI 的 4.3 和 5 寸一定比 SPI 的 3.5 寸流畅吗？

    不能直接比较。接口只是起点，实际帧率还取决于 PSRAM 访问带宽、DMA 配置、局部刷新策略与总线占用。5 寸每帧搬运量是 3.5 寸的 6 倍，接口更宽不代表结果更好，必须各自实测。

    为什么 3.5 寸的 SPI 链路更受关注？

    因为 SPI 是共享总线，刷屏要和同一总线上的其它外设分时，且每帧 307,200 字节的搬运量没有多少余量。局部刷新对它的价值最大，也最需要验证。

    外接 OBD 会占用显示带宽吗？

    不会直接占用显示接口，但会通过 CPU 与内存访问间接竞争。芯片的 TWAI 外设不等于可直接接车载 CAN，车电保护与隔离收发器要另做；总线占用必须在完整功能固件下测量才能反映真实竞争。

    本文数据来自星核火花赛车科技内部车载仪表研究项目的《五块赛道产品候选板硬件事实表》（核查日期 2026-10-03）。表中带宽为按 16 位色深与 30 FPS 推导的裸像素需求，非实测帧率；「30 FPS」保留为待验证的验收目标。

  • 圆屏还是方屏：车载仪表的显示形态该怎么选

    结论：车载仪表选圆屏还是方屏，先看面板原生像素和装配形态，再看 UI 需求。圆屏（466×466、360×360、240×240）适合单个大数字与弧形仪表；竖屏（280×456、320×480）适合零百计时和多行参数；横屏（800×480、1280×720）适合多字段对照与路书正文。设计稿上的 400×400 不等于板子的原生像素，形态在选板那一刻就定了。

    形态由面板原生像素和装配方式决定，不由 UI 风格决定

    一块板是圆屏、竖屏还是横屏，在采购下单时就已经固定，UI 只能去适配它，不能反过来改它。面板的物理像素是硬约束：已核对的候选板里，ESP32-S3-Touch-AMOLED-1.64 是 280×456 长方形 AMOLED，M5Stack CoreS3 是 2.0 寸 320×240 方屏，Seeed 的圆屏扩展板是 1.28 寸 240×240。把设计稿画成 400×400 或随便一个正方形，都不会让板子多出像素。

    像素定了，可排的信息量也就定了。圆屏的四角天然是被裁掉的，越靠中心越安全，所以它适合「一个大数字 + 一圈刻度」；长方形的 280×456 宽度只够一到两列；横屏 800×480 以上才有条件并排放多个读数。这不是审美选择，是面积分配问题。

    圆屏、竖屏、横屏各擅长什么信息形态

    三种形态解决的是三类不同问题：圆屏做单值聚焦，竖屏做时序与计数，横屏做并列对照。选错形态，界面会一直在和可用面积打架。

    形态 代表像素 擅长 不擅长 典型用途
    圆屏 466×466 / 360×360 / 240×240 单个大数字、弧形转速表、单值告警、余光可读 多字段表格、长文本、导航列表 车内时钟、单数据表、摩托与自行车表
    竖屏 / 长方 280×456 / 320×480 / 240×320 竖排参数、计时与状态机、多行数据 双列对照、宽表、长路书 OBD 零百计时器、赛道单表
    横屏 800×480 / 1280×720 / 800×480（电子纸） 双大读数、数据源状态列、路书正文 圆表外壳、单值聚焦场景 P4 扩展 OBD 表、离线路书

    注意最后一行的 800×480 出现了两次：一次是 P4 4.3 寸 IPS 的横屏 UI 目标，一次是 3.97 寸电子纸路书。像素相同，但一个是实时刷新，一个只做静态阅读，能承载的信息层级完全不同。

    已核对的候选板：谁的屏是什么形态

    把形态、像素、接口和触摸放在一张表里，才能看出「能换外壳」和「能换屏幕」是两件事。

    板卡 屏幕类型 原生像素 形态 触摸方案
    ESP32-S3-Touch-AMOLED-1.64 AMOLED，CO5300 QSPI 280×456 长方形，明确不是圆屏 FT3168，I2C
    ESP32-S3-Touch-AMOLED-1.75 / 1.75C AMOLED 466×466 圆屏（已有资料口径为圆表） 概览页未列
    ESP32-S3-Touch-AMOLED-1.43-B AMOLED，标称亮度 350 cd/m² 466×466 小尺寸圆屏 概览页未列
    ESP32-S3-Touch-LCD-1.85B-EN LCD 360×360 圆屏 概览页未列
    ESP32-S3-Touch-LCD-2 LCD，QMI8658 240×320 方屏 概览页未列
    ESP32-P4-WIFI6-Touch-LCD-3.5-EN IPS，ST7796 SPI 320×480 竖屏 FT6336，I2C
    ESP32-P4-WIFI6-Touch-LCD-4.3 IPS，MIPI-DSI 2-lane 480×800（UI 目标 800×480） 横屏 概览页未列 IC
    ESP32-P4-WIFI6-Touch-LCD-5-C IPS，MIPI-DSI 2-lane 720×1280（UI 目标 1280×720） 横屏，采购为带摄像头版 概览页未列 IC
    ESP32-S3-ePaper-3.97-EN 电子纸 800×480 横屏路书 概览页未列触摸
    M5Stack CoreS3 IPS 电容触摸 320×240 2.0 寸方屏 电容触摸
    Seeed Round Display for XIAO 圆形电容触摸屏 240×240 1.28 寸圆屏，直径约 39mm 电容触摸

    这张表里有两处必须点出来。第一，CoreS3 是方屏，外壳和显示形态都无法直接复用汽车圆表，它的价值在 CAN、音频和 UI 组合验证，不在形态。第二，1.28 寸 240×240 的圆屏复用不了 1.75 寸 466×466 的界面资产——尺寸、色深、显示驱动都不一样，只能当自研架构的验证样机。

    一个反例：1.64 的 400×400 概念稿为什么必须作废

    1.64 的原视觉稿画的是一块 400×400 的圈速页，但这块板原生是 280×456 长方形 AMOLED，两者对不上：1.64 不是圆屏，400×400 也不是它的原生像素。这份概念稿已被判定为过时，该板现在的方向是 OBD 车速零百计时器，并已按 280×456 竖屏重做了交互原型（原理见 OBD 零百加速计时为什么手机测不准）。

    更值得注意的是引脚层面：微雪为这块板区分了 V1 与 V1.1，LCD_CS 与 IMU_INT1 的 GPIO9 / GPIO46 分配在两个修订版之间互换，而已购板的版本丝印尚未核实。也就是说，连引脚都不能只按型号名推断，形态同理。

    形态判定要回到官方尺寸图和实物，不能靠命名

    型号名里带「1.75」不等于圆屏，带「-B」也不一定是独立硬件版本，这些后缀在微雪体系里的含义要逐型号确认。更实际的坑是资料完整度：几块 P4 板的 Wiki 概览页并未列全触摸 IC 和板载 IMU（4.3 与 5 寸未列触摸 IC，P4 三板均未列板载 IMU），电子纸板也未列屏控 IC、色阶与刷新方式。凡概览页没有的字段，只能从官方资料继续查，不能凭经验填值，也不能把同硬件家族的装配变体当成独立形态来重复设计。

    选形态前先回答三个问题

    1. 首屏要显示一个数还是多个数？单个大数字选圆屏；三到五个并列读数至少要横屏。
    2. 这块屏是给人「扫一眼」还是「读一段」？扫一眼用圆屏或竖屏的大字；读一段（路书）只能上横屏，且电子纸这类静态介质不承担实时告警。
    3. 装车形态定了吗？汽车圆表、摩托圆表、自行车码表的外壳和安装方式不同，先定装配再定屏，否则外形和屏幕会互相改。

    相关选板逻辑可对照 车载小仪表开发板选型：微雪 / M5Stack / Seeed 三家横向对照。

    常见问题

    圆屏的 466×466 是圆形的吗？

    不是。466×466 描述的是像素阵列是正方形，面板外形是圆的，四角区域不显示。所以圆屏实际可用的有效排版区域小于同像素的方形面板，这也是它只能承载「一个大数字加一圈刻度」的原因。

    能不能用一块方屏做出圆表的外观？

    可以用遮罩或外壳遮成圆形，但代价是浪费四角像素、并让触摸区域与显示区域错位。汽车圆表和摩托表之所以坚持用圆屏，是形态与安装决定的，不是显示决定的。

    1.28 寸的圆屏能直接套用 1.75 寸的界面吗？

    不能。1.28 寸是 240×240，1.75 寸是 466×466，尺寸、色深和显示驱动都不同，界面资产需要重新排布。它更适合用来验证自研底板、引脚分配和显示抽象层。

    为什么同一块板要区分 V1 和 V1.1？

    因为硬件修订会改动引脚分配。1.64 的 V1 与 V1.1 就互换了 LCD_CS 与 IMU_INT1 的 GPIO9 / GPIO46，若按错版本建 BSP，屏和 IMU 都会异常。已购板的丝印必须逐一核对。

    本文数据来自星核火花赛车科技内部车载仪表研究项目的《五块赛道产品候选板硬件事实表》与《小仪表开发板详细调研与路线建议》（2026-10 版）。参数以各型号微雪 Wiki 概览页为准，实际 PCB 修订版仍需核对丝印；本文不构成量产或开源硬件授权判断。

  • 车载小仪表开发板选型：微雪 / M5Stack / Seeed 三家横向对照

    结论：做车载小仪表，微雪的 ESP32-S3-Touch-AMOLED-1.75（SKU 31261）适合作为汽车标准版的基线——S3、8MB PSRAM、16MB Flash、466×466 AMOLED、双麦、IMU、RTC、TF、Wi-Fi/BLE 的组合足够完成第一版功能验证。但它没有板载 OBD/CAN 物理接口，也没有车电保护，必须另做接口盒或底板。M5Stack CoreS3 适合当 CAN/语音实验台，Seeed 的 XIAO + 圆屏适合验证「模块 + 自研底板」路线，两者都不直接替代圆屏产品形态。

    先说选型的三个前提

    开发板选型最容易犯的错，是把「开发板能跑通 Demo」当成「产品能落地」。三件事必须先讲清楚：

    1. 开发板不等于商品形态。圆屏、外壳、车电保护、OBD 线束、安装方式，全都不在开发板里。
    2. 同硬件家族的装配变体不能当成独立平台。1.75 无壳版和 1.75-B 带壳版的基础电子设计相同，不应该维护两份固件。
    3. 样机价不是量产价。采购表里的是已购均价，适合比较样机采购，不是 100 / 1000 片报价。

    三家厂商横向对照

    厂商 代表方案 适配理由 主要限制 定位
    微雪 Waveshare S3 1.75 / 1.75C、1.85、P4 4.3 已购样机与现有固件，圆屏形态接近产品 车电 / OBD 要外加；开源程度逐项不同 主调研对象
    M5Stack CoreS3、M5Dial、Unit CAN 现成的语音、IMU、模块化 CAN 实验链 方屏 / 小屏形态；模块叠加后体积与成本上升 对照 / 验证平台
    Seeed Studio XIAO ESP32S3 + Round Display 模块小，官方有原理图与 PCB 包 1.28 寸 240×240，接口资源需重新分配 自研过渡参考
    LILYGO T-RGB 2.1 / 2.8 圆形 IPS 2.1 寸 480×480 可试摩托 / 自行车大表 非 1.75 AMOLED；尺寸、功耗与外壳要重做 第二轮候选
    Elecrow CrowPanel 1.28 寸旋钮圆屏 对照旋钮交互与低成本 IPS 1.28 寸偏小；仓库未标明许可证 交互参考
    乐鑫 Espressif ESP32-S3-BOX-3、ESP-IDF 官方芯片 / 语音 / 总线开发资料 开发套件不是目标商品形态 SDK 与设计规范来源

    这张表不等于「这些板都是开源硬件」。每块板卡都必须分别检查软件、原理图、PCB 源文件、BOM 和素材的授权，不能因为「有 GitHub 仓库」就默认可以商业复制。

    微雪已购板卡逐项核查

    下表价格来自采购记录，是已购均价——用于样机比较，不是批量报价。

    板卡 数量 / 单价 关键参数 结论
    S3-Touch-AMOLED-1.75 2 / ¥174.50 SKU 31261；8MB PSRAM / 16MB Flash；466×466 AMOLED；双麦、IMU、RTC、TF；8Pin 排针只有 VBUS/GND/3V3、UART0 和 GPIO16/17/18 汽车标准版基线。外接 OBD / TPMS / GPS 前先画引脚占用表
    S3-Touch-AMOLED-1.75-B 12 / ¥194.35 SKU 31262；与上项基础电子设计相同，主要差别是保护外壳 外壳与 RF、散热、装车固定对照；不单独维护固件
    S3-Touch-AMOLED-1.75C / C-EN 4 / ¥235.14；11 / ¥220.52 SKU 33691 / 33692；8MB PSRAM / 32MB Flash、双麦、ES7210/ES8311、铝合金结构 旗舰 / 语音资源压测。不能按「Flash 不够」淘汰
    S3-Touch-LCD-1.85B-EN 1 / ¥188.31 SKU 34556；8MB PSRAM / 16MB Flash、360×360 LCD、双麦、IMU 摩托 / 自行车阳光可读性与音频实验
    S3-Touch-LCD-1.85C-BOX 1 / ¥196.61 SKU 30684；360×360 LCD；V1/V2 音频芯片与 GPIO2/10/11/15 等引脚不同 完整盒装交互样机；必须先读 PCB 丝印再建 BSP
    S3-Touch-AMOLED-1.43-B 3 / ¥177.53 16MB Flash / 8MB PSRAM、466×466 AMOLED；标称亮度 350 cd/m² 小尺寸对照。样机价仅比 1.75 裸板高 ¥3.03
    S3-Touch-LCD-2 1 / ¥91.00 8MB PSRAM / 16MB Flash、240×320 LCD、QMI8658 低价方屏概念验证。原 BOM 把它错写为 1.75 AMOLED，成本估算无效
    RP2350-Touch-AMOLED-1.75-B 1 / ¥181.38 具体板卡未获官方确认；只有采购 / 整理表 不进入当前固件主线；先确认卖家、PCB 与屏驱动
    T5-E1-Touch-AMOLED-1.75 1 / ¥191.28 具体板卡未获官方确认；SDK / 云依赖未核实 暂停降本假设；先证明驱动、BLE 协议与离线可用性
    P4-WIFI6-Touch-LCD-4.3 2 / ¥184.27 ESP32-P4 + C6；32MB PSRAM / 32MB Flash、4.3 寸 480×800 ST7701 MIPI-DSI、GT911 导航 / 视频实验线。板价低不代表整机便宜

    一个容易踩的坑：GPIO 早就被占满了

    普通 1.75 的 8Pin 排针上，可直接使用的通用 GPIO 主要是 16 / 17 / 18；43 / 44 是 UART0，通常承担调试；-G GPS 版本还可能占用 17 / 18。I2C 的 14 / 15 是板载多器件共用总线。

    如果 OBD 采用 MCU 的 TWAI 控制器，还需要外部 CAN 收发器，而且 GPIO 分配必须与 GPS、TPMS 接收器、串口日志同时规划。这里有一条必须记住的边界：芯片的 TWAI 外设不是 OBD 线束，也不是车电接口。有 CAN 控制器，离「能读这辆车的 OBD」还有很远。

    成本校验：¥399 的账算不平

    采购记录共 21 个已购变体、49 块，购买行金额 ¥9,434.92。但原始 BOM 至少有两处复制错误：2 寸 LCD 被记成 1.75 AMOLED，P4 3.5 被记成 4.3 屏。所以不能用它的 BOM 估算毛利。

    只用样机价做个敏感性示例：汽车标准版定价 ¥399，若希望物料及制造的直接毛利率达到 50%，完整交付成本上限是 ¥199.50。而仅 1.75 裸板样机价就占 ¥174.50，留给 OBD 接口、保护、外壳、线束、测试、包装的空间只剩 ¥25.00。这还没算税费、渠道、服务和研发摊销。

    结论很明确：必须拿到批量报价和自研降本数据，才能判断 ¥399 是否可盈利；用样机价宣布「可盈利」是不成立的。

    按产品的最终推荐

    产品 主选 备选 / 实验 进入下一阶段需要的证据
    汽车标准 / 胎压 微雪 S3 1.75 无壳 1.75-B 外壳对照 车型读取成功率、完整交付成本、RF / 散热 / 阳光可读性、供电保护
    汽车旗舰 1.75 与 1.75C 同时压测 CoreS3 做语音 / CAN 对照 分区 / PSRAM 数据、语音端到端延迟、素材与服务成本
    摩托车 S3 1.75 1.85B-EN、LILYGO T-RGB 大屏 目标车型 K-Line / CAN / 线束、倾角标定、防水振动
    自行车 S3 1.75 1.85B-EN、Seeed 模块组合 速度来源、心率标准 / 自有 BLE 并发、阳光雨天可读性、续航
    导航 / 后视镜探索 P4 4.3 独立线 CoreS3 仅做 UI / 协议实验 先定义结构化导航还是视频；视频不作为 1.75 的安全关键显示功能

    首批验证尽量使用现有库存。新增板卡采购应等到实测确认某一能力或形态缺口之后，再下单。

    常见问题

    1.75C 的 32MB Flash 值得为它升级吗？

    不建议把「Flash 更大」当作淘汰普通 1.75 的理由，但也不该反过来假设 1.75C 天然适合旗舰。1.75C 更可能受限于外壳、引出接口、分区方案或现有固件实现。正确做法是用 v1.1.4 的分区表、实际固件与素材大小、最小空闲堆来验证，而不是只看标称 Flash 数字。

    M5Stack CoreS3 能直接当汽车圆表吗？

    不能。CoreS3 是 2.0 寸 320×240 方屏，显示形态和外壳都无法直接复用汽车圆表。它的价值在于快速验证 CAN + 音频 + UI 的组合——配合 Unit CAN（CA-IS3050G 隔离收发器，标称最高 1Mbps、1000V 隔离），并核对 OBD 接头、电源、终端电阻与车型协议。

    「能收 CAN 帧」等于「支持汽车 OBD」吗？

    不等于。Unit CAN 只解决物理收发的一部分。还需要确认 OBD 接头、供电、终端电阻、车型协议、总线接入方式与兼容性。把「能收 CAN 帧」当成「支持汽车 OBD」，是选型阶段最常见的误判。

    为什么不直接从开发板的公开资料做量产？

    因为下载到原理图和 BSP，不等于拿到可投产的完整设计包。多数厂商只提供原理图 PDF，没有可编辑 PCB、生产 BOM 和结构件源文件。自研替代应以「自己重新设计车电输入、OBD/CAN、显示连接器、RF、壳体和测试工装」为目标，把公开资料当作参考，而不是成品。

    本文数据来自星核火花赛车科技内部《小仪表开发板详细调研与路线建议》（2026-10 版）。文中价格为采购记录中的已购均价，适用于样机比较，不构成批量报价或盈利承诺。

  • OBD 零百加速计时：为什么手机测不准，仪表该怎么算

    结论：用 OBD 做 0–100 km/h 加速计时，唯一可信的输入是标准 OBD-II 车速 PID 0x0D。它按整数 km/h 上报，所以「0.5 km/h 起步阈值」根本无法实现；GPS 不参与计时、插值或丢包补偿，IMU 只负责记录 G 值。在实车标定完成之前，「±0.05 秒」「优于手机」都只是待验证目标，不是规格。

    为什么「看起来能测」和「真的能测」是两回事

    手机上随手装一个加速计时 App，看起来也能出成绩。但把同一套逻辑搬到车载仪表上，问题会立刻暴露：加速度计的噪声、GPS 的更新频率和延迟、以及车辆实际起步的抖动，都会让「0 秒」这个时刻的定义变得含糊。

    更关键的是，计时器报告的是它接收到的数据时刻，而不是车辆真实的物理时刻。如果这一点不说清楚，讨论「精度」就没有意义。

    计时输入的唯一性：只用 OBD 车速

    在 OBD 车速与 IMU、GPS 并存的设计里，必须明确一条边界：计时链路上只允许有一个数据源。

    • 唯一计时输入：OBD 车速。首选通过受保护的车载网关读取标准 OBD-II PID 0x0D；若车型使用专用车速信号，必须在车型配置中写清协议、单位和量化精度。
    • GPS 不参与计时、插值或丢包补偿。GPS 的更新率和定位漂移都不足以支撑零点几秒级的判定。
    • IMU（如 QMI8658）可以记录峰值 G 和 G 曲线，但不参与起点、60 km/h、终点的时间戳判定。

    把三条拆开看，逻辑就清楚了：IMU 回答「加速有多猛」，GPS 回答「路走了多远」，而只有 OBD 车速能回答「什么时候到 100」。混用会得到漂亮的数字，但那个数字不可复盘。

    状态机：五个状态按什么顺序判定

    状态 进入条件 动作
    IDLE 收到连续有效的 0 km/h 样本，覆盖至少 1 秒 进入 ARMED
    ARMED 首次收到有效且大于 0 km/h 的车速 记该样本接收时刻为 t0，进入 RUNNING
    RUNNING 首次收到车速 ≥ 60 km/h 记 t60，继续计时
    RUNNING 首次收到车速 ≥ 100 km/h 记 t100，锁存 t100 − t0 与 t60 − t0，进入 COMPLETE
    任意计时状态 网关断连、PID 不支持、响应超时、样本乱序或不可信 标记本次无效，保存原因，不显示成功成绩

    这套状态机刻意做得很「笨」：不猜、不补、不回头修。原因很直接——加速成绩的价值在于可信，而不在于好看。

    哪些情况必须判为无效

    「无效」不是异常处理，而是产品功能的一部分。至少要覆盖这六类场景：

    1. 缓慢起步——车辆长时间停留在 1 km/h 附近，起步时刻难以确定。
    2. 瞬时跳值——单帧车速突然从 0 跳到 60，超出物理可能性。
    3. 重复帧——同一时刻收到多条相同样本。
    4. 乱序——时间戳不单调递增。
    5. 超时——请求发出后长时间没有响应。
    6. 中途失联——网关在 RUNNING 期间断开。

    这些场景必须在离线注入测试中全部覆盖：把速度曲线喂给同一套解析与状态机，逐条核对状态切换与时间戳是否正确。

    为什么 0.5 km/h 的起步阈值做不到

    标准 PID 0x0D 返回的是整数 km/h，没有小数位。所以「车速大于 0.5 km/h 即视为起步」这种阈值在协议层面就无法表达——你只能看到 0 和 1。

    因此首版采用「首次收到大于 0 的有效样本」作为起步点，并且明确：

    • 不插值。是否用 0→1 与 99→100 两点插值，必须在记录了轮询周期、往返延迟和车型信号特性之后再决定。
    • 不借用 IMU 或 GPS 填补样本。填补会产生看似连续、实则虚构的曲线。
    • 连续 0 km/h 的判定需要多个有效样本。网关断连期间「保持」的旧值，不能算进那 1 秒。

    要留什么数据，才叫可复盘

    每条车速样本至少保存六项：原始响应、解码值、请求发出时间、响应接收时间、网关状态、单调时钟时间戳。

    这里有个容易被忽略的区分：界面刷新频率不等于车速采样频率。屏幕每秒刷 20 帧，不代表每秒拿到 20 个车速样本。把两者混为一谈，会让「数据很密」变成一种错觉。

    另外，上述所有时间戳都是 OBD 响应接收时刻，不是 ECU 的实际采样时刻。这是整条链路的固有偏差，只能披露，不能消除。

    关于精度的诚实表述

    「±0.05 秒」和「优于手机」是待验证目标。在完成以下三步之前，它们不应出现在任何宣传文案里：

    1. 向同一套解析与状态机注入速度曲线，覆盖缓慢起步、瞬时跳值、重复帧、乱序、超时与中途失联。
    2. 在目标车型上记录 PID 支持情况、有效车速更新率、请求往返延迟分布、网关额外延迟，以及计时期间的丢包率。
    3. 用独立参考设备同步采集多次 0–100，统计偏差与离散程度。

    界面需要提供五种状态：待连接、待起步、计时中、成绩、无效记录。历史最佳只收录「有效且带车型 / 数据源元信息」的成绩——没有元信息的成绩无法复盘，也就不该进榜。

    常见问题

    用 GPS 测 0–100 会差多少？

    本文不给具体数字，因为差异取决于 GPS 模块的更新率、定位精度和遮挡情况，需要实测。但可以确定的是：GPS 的采样与延迟特性使它不适合作为零点几秒级判定的唯一依据，因此本方案把它排除在计时链路之外。

    IMU 能提高计时精度吗？

    不能用于提高计时精度。IMU 可以记录峰值 G 和 G 曲线，用于分析驾驶表现，但起点、60 km/h、终点三个时间戳只能来自 OBD 车速样本。

    为什么不做插值让曲线更平滑？

    因为插值会产生「看起来连续、实际不存在」的样本。首版选择保留原始离散点，等实车标定拿到轮询周期与延迟分布后，再评估插值是否值得引入。

    成绩为无效时，界面应该显示什么？

    显示无效原因，而不是一个成功成绩。无效判定的价值就在于：它让用户知道自己看到的数字是否可信。

    小结

    一个可信的 OBD 加速计时器，本质上是一套数据边界 + 状态机 + 无效判定的组合，而不是一个公式。先用整数 km/h 的现实约束定义清楚能做什么、不能做什么，再谈精度——这个顺序反了，后面全是返工。

    本文结论来自星核火花赛车科技内部车载仪表研究项目（2026-10 版）的《OBD 零百计时规格》与《五块赛道产品候选板硬件事实表》。文中精度指标均为待验证目标，实际数值以实车标定为准。