标签: HMI

  • 仪表市场对照:ScanGauge / Beeline / CHIGEE / Wahoo / Karoo

    结论:汽车、摩托、自行车是三种不同需求,一块屏通吃不了。汽车 OBD 用户买的是可读车型、线束适配与故障状态,摩托买的是耐候导航,自行车买的是导航加传感器生态。抽查 7 款在售产品,官网展示价从 £179.99 到 US$525.00 不等;但本轮没有购买、拆机或实测,所有性能参数均为厂商官网宣称。

    三条需求线:为什么不能把竞品放在一张表里排名

    因为这三类产品的交付物根本不是同一种东西。汽车 OBD 监测卖的是「可读车型 + 线束 + 安装 + 故障状态」,用户第一问是「我的车能不能读」;摩托导航卖的是「在雨里、震动中、戴着手套也能看清的转向提示」,第一问是「续航和防水够不够」;自行车码表卖的是「导航 + 数据记录 + 传感器生态」,第一问是「能不能连我的心率带和功率计」。

    这条判断直接决定首发形态。首发商品数量应当少于已购板卡种类——把开发板上能点亮的尺寸都做成商品,等于同时用三种互不相同的售后与适配体系去服务三批互不相同的用户。站内关于显示形态与链路的讨论,另见 圆屏还是方屏:车载仪表的显示形态该怎么选 与 车载 HMI 的 30 FPS:SPI 与 MIPI-DSI 显示链路差在哪。

    七款在售产品的官网对照

    因为竞品页面的可核对信息有限,对照只收录官网当时页面能直接看到的能力与标价,不做推测性补齐:

    场景 在售产品 官网可核对的能力 官网展示价 对本项目的设计启示
    汽车 OBD 监测 ScanGauge 3 OBDII 车辆数据、彩色触控、故障码读取 / 清除;页面强调 1996 年后的 OBDII 车辆兼容 US$269.95(含所列吸盘支架) 用户买的是可读车型、OBD 线束、安装与故障状态;单纯圆屏 UI 不构成完整竞品,中国车型覆盖须另测
    摩托小型导航 Beeline Moto II 手机配合的逐路口导航、骑行数据与数字速度;官网标称防水、抗震与 14 小时续航 £179.99 小屏可以卖清晰的转向提示,但必须解决手机后台链路、支架、雨天与手套交互;它不承诺读取摩托 ECU
    摩托手机互联屏 Carpuride W702 无线 CarPlay / Android Auto、双蓝牙、IP67、官网标称 1000 nit US$269.99 若「导航投屏」指完整手机互联,那是 7 寸防水屏系统;1.75 / 1.85 寸板更适合结构化转向信息
    摩托高亮大屏 CHIGEE AIO-6 Max 6 寸 1280×720 IPS;官网标称 2300 nit、专用骑行系统与安装套件 US$499.00 户外可读性、供电、安装、振动与生态附件才是产品主体;大屏实验线需单独验证
    自行车导航码表 Wahoo ELEMNT ACE 大触屏 GPS 码表;官网介绍手机 App 设置与骑行智能功能 US$499.99 高端码表是导航、数据记录、传感器与 App 的闭环,不宜把显示板当成完整码表
    自行车生态码表 Hammerhead Karoo 高分辨率触屏、导航、自定义数据页、SRAM AXS 集成 US$525.00 自行车联动要有明确的传感器兼容与数据页设计;自有协议不能替代通用心率服务
    汽车视频大屏 Carpuride W903 双摄版 9.3 寸车载多媒体屏、手机互联、前后摄像头与语音控制 US$249.99 后视影像与导航属于另一个尺寸 / 安全边界;5 寸板只能先做非安全关键演示,不宜纳入圆形 OBD 表首发

    查阅日期为 2026-10-03。表中的链接与标价均指向各厂商官网当时的具体商品页;币种横跨美元与英镑,配件、税费与售后各不相同。

    为什么这些价格不能直接用来推导自家定价

    因为「官网展示价」和「中国到手价」之间隔着汇率、关税、套装内容与渠道毛利四道变量,而这个项目真正要面对的是其中最后一道。把 US$269.95 按汇率换成人民币,得到的不是竞品的成本,也不是自己产品的成本上限。

    也正因如此,队列里提到的「STACK ¥399」缺少确切品牌商品链接、SKU 与套装内容,暂不列为已核实竞品;M5Stack 的开发板也不是这个价格锚点的已证实来源。真要建立一个可信的成本锚,需要的是「同类形态 + 明确 SKU + 明确套装内容 + 中国实际到手价」四要素齐全的样本。硬件选型与成本结构的基础参照,可先看 车载小仪表开发板选型:微雪 / M5Stack / Seeed 三家横向对照。

    三处必须承认的空白

    因为厂商宣称与第三方实测是两种证据等级,这个对照目前只完成了第一层。本轮没有购买任何竞品,也没有做拆机、亮度、续航、协议解析与中国车型兼容性测试。因此以下三类数据在本文中一律标注为厂商宣称,不作为可引用的实测结论:

    宣称项 出现在哪款产品 原文表述 本文口径
    亮度 1000 nit Carpuride W702 官网标称 厂商宣称,未实测
    亮度 2300 nit CHIGEE AIO-6 Max 官网标称 厂商宣称,未实测
    14 小时续航 / 防水抗震 Beeline Moto II 官网标称 厂商宣称,未实测
    1996 年后 OBDII 兼容 ScanGauge 3 页面强调 厂商宣称;中国车型覆盖须另测

    还有一处空白值得单独说:这些竞品绝大多数不承诺读取中国市场的私有 CAN 报文。ScanGauge 页面强调的是 OBDII 通用兼容,Beeline 明确不承诺读 ECU,自行车码表则完全走 BLE 传感器生态。所以「能读多少中国车型的私有字段」这件事,在现有竞品页面上找不到可直接对标的答案——这既是机会,也意味着没有现成的分母可以抄。相关的证据分层方法,见同批发布的 竞品功能点数据库:怎么量化 Car Scanner 的字段覆盖度。

    差异化验证该测什么

    因为「宣称差异化」和「验证差异化」只差一步,而这步必须落在可对照的实测项上:

    产品线 首版主张 必须与竞品对照的实测项 暂不承诺
    汽车 OBD 小表 紧凑的可配置转速 / 车速 / G 值与清晰失联状态 目标车型 PID 覆盖、刷新率、夜间与日光可读性、安装与完整交付成本 通用适配所有车型、靠主控板直接连 OBD、未核实的故障诊断能力
    摩托小表 手机路线转向 + 倾角,车型适配后才加入发动机数据 防水振动、手套交互、手机后台可靠性、目标车型线束与协议 1.85 寸完整 CarPlay / Android Auto、所有摩托通用 OBD
    自行车码表 轮速 / GPS 速度、转向提示、标准 BLE 心率优先 速度来源、心率兼容、续航、阳光可读、雨天操作 仅凭 IMU 算出可靠骑行速度、未经证明的自有心率广播协议
    大屏探索 结构化导航 / 摄像头链路技术样机 阳光亮度、延迟、供电、环境可靠性与安装遮挡 可代替后视镜或安全关键影像显示

    注意首版主张里都刻意不写「对标某竞品」:因为对标的前提是拿到同一条件下的实测数据。在完成上述对照项之前,对外主张应停留在形态与能力边界,而不是性能领先。离线路书这类形态之所以用黑白电子纸,是另一种「先确认能力边界再定形态」的例子,见 电子纸路书:3.97 寸离线路书为什么用黑白。若产品要回传数据做复盘,云端链路的对照基线可参考 SR-Telemetry 实时遥测云。

    常见问题

    这几款竞品里,哪个最值得对标?

    没有单一对标对象,因为三者需求不同。汽车 OBD 侧可对标 ScanGauge 3 的「可读车型 + 线束 + 故障状态」交付形态;摩托侧可对标 Beeline Moto II 的耐候与转向提示;自行车侧可对标 Wahoo / Karoo 的传感器与 App 闭环。选择哪条线,取决于目标用户先问的那个问题。

    官网标的亮度、续航可以直接写进宣传吗?

    不可以。这些数字在本文中一律标注为厂商宣称,本轮没有做亮度、续航、防水或协议测试。在完成同条件实测之前,不能把竞品官网标称值当作已核实的对比依据,更不能反过来用它论证自家产品领先。

    为什么 ¥399 的价格锚点暂时不算竞品?

    因为它缺少四项要素:确切品牌商品链接、SKU、套装内容与中国实际到手价。官网展示价又横跨美元与英镑,无法按汇率直接推导。要用它做成本锚,必须先补齐这四项,否则只是一个人名或传闻级的数字。

    「能读中国车型私有字段」算不算现成的差异化点?

    方向上算,但目前没有可直接对标的现成分母。现有竞品页面多数只强调 OBDII 通用兼容或 BLE 传感器生态,不承诺读取私有 CAN 报文。这意味着机会存在,但也意味着覆盖度分母必须自建,且要按证据等级分层对外表达。

    本文数据来自星核火花赛车科技内部「车载小仪表开发板调研」项目的市场产品对照文档(查阅日期 2026-10-03)。所有价格均为各厂商官网当时页面展示价,币种横跨美元与英镑,不等于中国到手价、销量、长期零售价或本项目的成本;官网可能按地区、促销和套装改变价格。表中性能参数(如 1000 nit、2300 nit、14 小时续航、防水抗震)均为厂商官网标称,本轮未购买竞品,未做拆机、亮度、续航、协议解析与中国车型兼容性测试,不作为实测结论。「STACK ¥399」因缺少确切商品链接、SKU 与套装内容,暂不列为已核实竞品。

  • 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 与发布流程为准。

  • 电子纸路书:3.97 寸离线路书为什么用黑白

    结论:3.97 寸电子纸路书的定位是离线静态阅读,而不是实时仪表,所以它采用白底黑字、单色大 tulip 图与简短中文路书,并且不套用彩屏的五套主题。它的刷新方式、局刷能力与残影表现目前仍是待实测项——微雪概览页未列出屏控 IC、色阶与刷新方式。

    电子纸路书为什么用黑白,而不是彩屏

    因为角色不同:彩屏承担实时仪表与告警,电子纸只承担离线阅读路书,所以它不参与彩屏主题体系。在 kno 赛道 HMI 原型里,3.97 寸是唯一一块白底黑字、大 tulip 路线图、简短中文路书的画布,并明确不套用彩屏主题、不受主题切换影响。它的色彩令牌也只有两个值:#F1F1EA 与 #202A2A,用途写的是「单色静态路书」。

    这个取舍是有道理的。路书是上车前要记住、上车后偶尔翻一眼的东西,不是需要每秒刷新的数据。把它放在电子纸上,好处是静态内容在强光下可读、断电也不丢画面;代价则是放弃实时性——电子纸不承担圈速、转速、告警这类必须实时的信息。彩屏侧的信息架构与告警设计另见 赛道仪表的信息架构:从圈速到告警的设计顺序。

    3.97 板上的硬件事实有哪些?

    这块板的官方概览页确认了主控、存储、屏幕分辨率与板载外设,但没有列出屏控 IC、色阶与刷新方式。下表逐项列出,方便核对。

    项目 官方概览页事实 备注
    采购型号 ESP32-S3-ePaper-3.97-EN -EN 为采购记录中的语言 / 销售后缀;实际 PCB 修订版需核对丝印
    主控与存储 ESP32-S3-WROOM-1-N16R8;8MB PSRAM,16MB Flash —
    屏幕 800×480 电子纸,横屏路书 概览页未列屏控 IC、色阶与刷新方式
    触摸 概览页未列触摸 不作为交互假设
    板载外设 Micro SD、PCF85063 RTC、QMI8658 IMU、SHTC3、ES8311、TG28 RTC 与 IMU 是板上实际存在的外设
    供电与接口 3.7V 电池接口 / 充电、USB-C —

    需要强调的是表格的空白项也是一种事实。「概览页未列屏控 IC、色阶或刷新方式」意味着这些参数不能凭经验填值——同厂的彩屏板型号各不相同,把彩屏驱动方案套到电子纸上没有依据。按项目现有的核对流程,这类缺失项要回到该型号的官方资料继续查,而不是估算。

    离线路书在原型里怎么组织?

    原型用「18 页示意路书 + 3 张示意 tulip 图循环」来组织,并用上一页 / 下一页切换;刷新能力与残影没有在浏览器中模拟。

    这里有两层信息要分开看。第一层是内容结构:18 页路书、3 张示意 tulip 图循环复用,说明路书在原型里的组织单位是「页」,而不是滚动列表——这符合电子纸的阅读方式,一次刷一整页。第二层是验证边界:浏览器里的翻页只是布局与分页逻辑的演示,它不产生任何关于刷新速度、残影或功耗的数据。tulip 是路书里的示意图形代号,本轮使用的是示意图,不是真实赛道的测量路书。

    如果要把示意路书换成真实赛道路书,数据侧可对照 SR-Track 中国赛道数据包;赛道几何与长度基准可参考 珠海国际赛车场。选屏形态(圆屏还是方屏、黑白还是彩色)的判断逻辑另见 圆屏还是方屏:车载仪表的显示形态该怎么选。

    电子纸的刷新能力为什么还算「待实测」?

    因为概览页没有给出屏控 IC、色阶与刷新方式,所以局部刷新、200 次翻页后的残影、以及休眠电流都只能列为实测项目,不能写成已达成。

    这是本项目在数据分寸上的一条硬规则:在确认波形与刷新能力之前,不把「部分刷新」写成必然支持。电子纸的刷新行为高度依赖具体屏体与波形配置——同一块 800×480 面板,全刷与局刷的表现、刷新耗时与残影积累都可能完全不同。缺了屏控 IC 与刷新方式这两项前提,任何关于「支持局刷」的结论都是推断而非事实。

    维度 彩屏(1.64 / 3.5 / 4.3 / 5.0 寸) 电子纸(3.97 寸)
    介质 彩色 AMOLED / IPS 单色电子纸 800×480
    角色 实时仪表、圈速、告警 离线静态路书
    主题 五套主题可切换 不套用彩屏主题,不受切换影响
    色彩令牌 背景层 / 文字层 / 语义四色 #F1F1EA / #202A2A 双色
    刷新与功耗 原型未验证实机帧率(30 FPS 为验收目标) 局刷、200 次翻页残影、休眠电流均为待实测

    顺带说明:这块板上另有 RTC(PCF85063)与六轴 IMU(QMI8658)。它们的存在不等于已经用上——在路书场景里,RTC 与 IMU 的用途需要在固件阶段单独设计,目前原型并未把它们接入路书的展示逻辑。另外,原型的预览使用系统字体,固件移植前同样须选定允许嵌入式再分发的字体并重新检查文字边界。

    常见问题

    3.97 寸电子纸路书支持局部刷新吗?

    目前不能下结论。微雪的概览页未列出该型号的屏控 IC、色阶与刷新方式,因此局刷能力、200 次翻页后的残影表现和休眠电流都列为实测项目。在确认波形与刷新能力之前,不把「部分刷新」写成必然支持。

    电子纸路书为什么不用彩屏的那五套主题?

    因为用途不同。五套彩屏主题(厂商 / JDM / 赛道 / 复古机械 / 霓虹遥测)服务的是实时仪表与告警,靠颜色表达状态;电子纸是单色静态介质,只负责离线阅读路书,不承担实时告警,因此保持白底黑字、单色 tulip 图与简短中文路书,也不受主题切换影响。

    原型里的 18 页路书是真实赛道数据吗?

    不是。原型使用的是示意路书:18 页内容与 3 张循环使用的示意 tulip 图,用于演示分页与布局逻辑。真实的赛道路书需要接入赛道测量数据后重新生成。

    浏览器里的翻页效果等于实机刷新效果吗?

    不等于。原型在浏览器中翻页只是布局与分页逻辑的演示,刷新能力与残影没有在浏览器中模拟。实机的刷新耗时、残影积累与功耗必须实机实测。

    本文数据来自星核火花赛车科技内部两个项目:赛道 HMI 原型项目(kno)的《赛道 HMI 原型(kno 副本 · 统一厂商风)》README(2026-10 版),以及车载小仪表开发板调研项目的《五块赛道产品候选板:硬件事实表》(核查日期 2026-10-03,参数以微雪各型号 Wiki 概览页为准)。硬件参数为官方概览页标称值,不代表实机测试完成;局部刷新、200 次翻页残影与休眠电流为源文档明确标注的待实测项目,文中未写成已达成。原型中除分辨率与色彩令牌外的数值均为明确标注的模拟数据。

  • 五套赛道 HMI 主题:配色、栅格与余光可读性

    结论:五套赛道 HMI 主题(厂商 / JDM / 赛道 / 复古机械 / 霓虹遥测)只改视觉语言,不改信息架构:它们共享同一组模拟 OBD 数据、计时与告警状态,切换主题不重置回放。决定余光可读性的不是配色本身,而是固定位置的告警区、统一字距的标签与窄无衬线大数值。

    五套主题改的是视觉语言,不是信息架构

    五套主题的差异只落在配色、字形与动效这一层,数据优先级与告警逻辑完全一致。这一点在 kno 赛道 HMI 原型里是硬约束:五套主题共享同一组模拟 OBD 数据、计时与告警状态,切换主题不重置回放。换句话说,主题是一层皮,不是一套新逻辑。

    这条约束的价值在于可验证性。如果每个主题各带一套自己的数据流或计时状态,就没法判断「同一个工况下五种视觉是否都读得出来」——变量太多。把主题限制在视觉层,才能让「换主题」这件事变成纯粹的视觉对照。信息架构本身的设计顺序另见 赛道仪表的信息架构:从圈速到告警的设计顺序。

    五套主题分别在强调什么?

    五套主题各有明确取向:厂商主题求统一克制,JDM 与霓虹求动效层次,赛道与复古求朴素可读。下表是各主题的视觉规则与数据驱动的动效。

    主题 视觉规则 数据与动效
    厂商 pro(默认) 统一深底、统一字距标签、窄无衬线大数值、青 / 琥珀 / 绿 / 红告警色板 换挡灯条与转速弧由 RPM 驱动;右侧告警柱与底栏随工况变色
    JDM 深底、压缩展示字、机械刻度、红针、湖绿车速色块 RPM 驱动分段换挡灯与指针;车速驱动进度块
    赛道 中性深底、大数字和清晰分隔线 优先突出 OBD 车速、圈速和告警
    复古机械 中性浅色表盘、细刻度、红针、衬线数字 指针随车速和转速变化,状态以文字和颜色双重表达
    霓虹遥测 深色数码排版、青 / 蓝 / 粉色量化条、模块化信息区 速度和转速用分段色块推进;报警区随工况变色

    「厂商」是这一轮新增并设为默认的主题。它的参考对象(RaceLogic / AiM MXS / PLEX SDM / MoTeC / Forza / iRacing / SimHub / RaceLab 等)在本轮只以文字描述的形式提供,图片文件不在工作区内,因此该主题是按描述建立的信息架构与原创视觉,未做逐图参考比对。所有图形、文字与布局均重新绘制,不使用任何参考品牌的 logo、商标字体或截图素材。

    颜色为什么必须写成「有用途的令牌」,而不是随手取色?

    把颜色写成有用途的令牌,是让五块屏、五套主题保持一致的前提;pro 主题的令牌按背景层、文字层、语义层三级组织。

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

    把颜色分成三层,解决的是「改一处、乱一片」的问题。背景层只负责层次,五档灰阶拉开卡片与底条的关系;文字层只负责可读性,主读数与次级、三级文字之间有明确的亮度落差;语义层只负责含义,青 / 琥珀 / 绿 / 红各自绑定一种状态,不参与装饰。语义色一旦被拿去当装饰,告警就不再可靠——这是配色表里最需要守住的一条。

    余光可读性靠哪三条规则保证?

    余光可读性靠三条可执行的规则:告警位置固定、标签统一加字距、数值走窄无衬线大字号。它们都是可检查的工程约束,不是审美偏好。

    第一条是告警位置固定。赛道驾驶时不可能逐字阅读,只能靠余光判断颜色和位置:在 3.5 寸上是顶部换挡灯条加下方四格,告警时水温与油压两格转红并描红边;在 4.3 与 5.0 寸上是右侧独立的告警状态柱,固定显示油压、水温、电压、OBD 四项。位置不随数据变化而移动,是余光可读的前提——告警一旦会「跳」,余光就失效了。

    第二条是标签统一加字距(letter-spacing)。中文标签在深底窄间距下容易糊成一团,统一拉开字距能让字符边界在余光下更清楚。

    第三条是数值走 Bahnschrift 类窄无衬线字体。窄无衬线在相同物理宽度内能塞下更大的字号,这对 1.64 寸这类小画布尤其关键。

    这些主题目前能证明什么、不能证明什么?

    能证明的是信息架构与视觉语言的自洽性,不能证明的是任何实机显示与计时性能。原型的自动校验用 Playwright 遍历 5 块屏 × 5 套主题 × 全部副视图,逐项检查:SVG viewBox 是否为各板原生像素尺寸;所有 <text> 元素是否越出画布(用 getBBox() 逐项检测);SVG 内容中是否泄漏 undefined 字符串;默认主题是否为 pro、主题切换是否生效;以及 OBD 回放推进、计时完成、断连状态、路书翻页、移动端横向溢出等交互状态。

    但边界必须写明——这套原型不证明 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度。显示链路的帧率约束可参考 车载 HMI 的 30 FPS:SPI 与 MIPI-DSI 显示链路差在哪。另外两条限制同样要留档:预览使用的是系统字体(Bahnschrift / Microsoft YaHei / Impact / Georgia / Consolas),固件移植前须选定允许嵌入式再分发的字体并重新检查文字边界;圈速、侧向 G、胎压等数值为示意值,档位与油压尚无车型适配,零百计时只使用模拟 OBD 车速,实机须接入受保护的 OBD 网关。

    还有一层方法论上的取舍值得记录。本轮在动手之前先检索了可核验的 UI 设计 skill:本机 skill-installer 的 OpenAI curated 目录接口返回 HTTP 403,应用内浏览器的设计系统检索连接超时,本机 visualize skill 的说明明确其用于对话内可视化、不适用于修改现有项目页面。因此本轮没有安装或引用任何未经核验的第三方 skill,风格直接落在已有 HMI 工程里实现。这比先引入一个来路不明的设计系统再回退要省事得多。赛道数据侧可对照 SR-Data 圈速分析套件,赛道几何与圈速基准可参考 上海国际赛车场。

    常见问题

    赛道仪表的配色应该先定哪一层?

    先定语义层,再定文字层,最后定背景层。语义色(青 / 琥珀 / 绿 / 红)绑定告警含义,一旦被装饰占用就失去可靠性;文字层要保证主读数与次级、三级文字有明确亮度落差;背景层只是把卡片与底条分出层次。顺序反了,改配色时会连带改掉信息层级。

    JDM 主题和霓虹主题的核心区别是什么?

    区别在动效的表达方式。JDM 用机械刻度、实体指针和珊瑚红 / 湖绿实色色块,靠 RPM 驱动分段换挡灯与指针、车速驱动进度块;霓虹遥测则用深色数码排版、青 / 蓝 / 粉色量化条和模块化信息区,靠速度和转速的分段色块推进。前者模仿机械表,后者模仿数码遥测。

    切换视觉主题会重置计时或 OBD 数据吗?

    不会。五套主题共享同一组模拟 OBD 数据、计时与告警状态,切换主题不重置回放。这正是把主题限制在视觉层的目的——保证换主题时变量只有一个。

    这五套主题能直接烧进固件吗?

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

    本文数据来自星核火花赛车科技内部赛道 HMI 原型项目(kno)的《赛道 HMI 原型(kno 副本 · 统一厂商风)》README(2026-10 版)与《仪表 UI 风格与 skill 检索》(检索日期 2026-10-04)。五套主题共享的 OBD、计时与告警状态均为明确标注的模拟数据;「厂商」主题未做逐图参考分析,参考图仅以文字描述形式提供。文中的 skill 检索结果(HTTP 403、连接超时、visualize 不适用)为 2026-10-04 当次实测结论,仅代表当日状态。本原型不构成对 ESP-IDF / LVGL 点屏、SPI / DSI 帧率、实车 PID 支持或计时精度的验证。

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

    结论:赛道仪表的信息架构顺序是「先定要显示什么,再定怎么排」:以真实赛车仪表的数据排布与告警逻辑作骨架,以赛车游戏 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 支持或计时精度的验证。

  • 车载 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,车电保护与隔离收发器要另做;总线占用必须在完整功能固件下测量才能反映真实竞争。

    {
    “@context”: “https://schema.org”,
    “@type”: “FAQPage”,
    “mainEntity”: [
    {
    “@type”: “Question”,
    “name”: “三块 ESP32-P4 车载仪表板现在能做到 30 FPS 吗?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “不能下这个结论。30 FPS 是验收目标而非硬件事实,需要按满屏刷新、局部刷新、PSRAM 和总线占用四项在完整功能固件下分别实测,目前没有可引用的实测数据。” }
    },
    {
    “@type”: “Question”,
    “name”: “MIPI-DSI 的 4.3 和 5 寸一定比 SPI 的 3.5 寸流畅吗?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “不能直接比较。接口只是起点,实际帧率还取决于 PSRAM 访问带宽、DMA 配置、局部刷新策略与总线占用。5 寸每帧搬运量约为 3.5 寸的 6 倍,接口更宽不代表结果更好,必须各自实测。” }
    },
    {
    “@type”: “Question”,
    “name”: “为什么车载 HMI 的 3.5 寸 SPI 链路更受关注?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “因为 SPI 是共享总线,刷屏要与同一总线上的其它外设分时,且每帧 307,200 字节的搬运量余量有限。局部刷新对它的价值最大,也最需要实测验证。” }
    },
    {
    “@type”: “Question”,
    “name”: “外接 OBD 会影响车载仪表的显示帧率吗?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “不会直接占用显示接口,但会通过 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 都会异常。已购板的丝印必须逐一核对。

    {
    “@context”: “https://schema.org”,
    “@type”: “FAQPage”,
    “mainEntity”: [
    {
    “@type”: “Question”,
    “name”: “车载仪表的圆屏 466×466 是圆形的吗?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “不是。466×466 描述的是正方形像素阵列,面板外形是圆的,四角区域不显示。圆屏实际可用的有效排版区域小于同像素的方形面板,因此更适合一个大数字加一圈刻度的布局。” }
    },
    {
    “@type”: “Question”,
    “name”: “能不能用一块方屏做出圆表的外观?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “可以用遮罩或外壳遮成圆形,但会浪费四角像素并让触摸区域与显示区域错位。汽车与摩托表坚持用圆屏是形态和安装决定的,不是显示决定的。” }
    },
    {
    “@type”: “Question”,
    “name”: “1.28 寸圆屏能直接套用 1.75 寸的界面吗?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “不能。1.28 寸是 240×240,1.75 寸是 466×466,尺寸、色深与显示驱动都不同,界面资产需重新排布,更适合作为自研底板和显示抽象层的验证样机。” }
    },
    {
    “@type”: “Question”,
    “name”: “车载仪表开发板的形态能从型号名判断吗?”,
    “acceptedAnswer”: { “@type”: “Answer”, “text”: “不能。型号后缀在厂商体系里的含义需逐型号确认,且 1.64 的 V1 与 V1.1 就互换了 LCD_CS 与 IMU_INT1 的 GPIO9/GPIO46。形态与引脚都必须回到官方尺寸图、修订说明和实物丝印核对。” }
    }
    ]
    }

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

    延伸阅读

  • 赛道日的准备清单:把自己调到最佳状态

    结论:赛道日准备里最被低估的变量不是硬件,而是驾驶员状态。很多车手在避震、刹车、轮胎上投入大量精力,却忽略了睡眠、补水与热身这三项会直接改变反应时间的因素——而反应时间的变化在赛道上会以「刹车点提前量」的形式直接兑现成圈速。同时,所有硬件调整都必须在赛道日之前完成验证,赛道日当天只做已验证项的微调。

    睡眠是最被低估的变量

    睡眠不足 5 小时,反应时间会显著变长;而赛道上的反应时间直接体现在刹车点提前量上。一个平时很稳定的刹车点,可能因为没睡好就晚了 20 米——这 20 米不会被感知成「我反应慢了」,而会被感知成「今天车不对」,于是你开始误调硬件。

    建议是:赛道日前一天正常作息,不要补觉也不要熬夜。连续熬夜后的「亢奋状态」往往比正常状态更危险,因为主观上的兴奋会掩盖客观的反应迟钝,让人倾向于冒进。

    赛前两小时该做和不该做的事

    事项 该做 不该做 原因
    车辆设定 沿用已验证的设定 尝试新的避震或胎压调整 未验证的改动会把时间浪费在适应上
    补给 补水 补糖 出汗量远超日常,脱水对反应速度的影响比血糖波动更明显
    热身 动态拉伸 冷车状态下做静态拉伸 静态拉伸会短暂降低力量输出
    座椅 调到能承受的最低位置 为了舒适牺牲坐姿 重心低 20 mm 的效果常超过一整套避震

    胎压:不要用静态冷胎压

    冷胎压只是一个起点。随着胎温上升,胎压会上升 0.1–0.2 bar;正确的做法是设定一个热胎目标压,然后在跑几圈之后测量并微调,而不是把冷胎压当作目标值直接设定。

    前后压的平衡比绝对值更重要。偏高的前压会让转向变轻,但推头倾向会增加,在数据上表现为前胎滑移率异常升高。因此调整的顺序是:先定热胎目标压,再调前后平衡,最后才微调绝对值。

    重心:最简单的改装

    座椅降低 20 mm、重心向发动机舱前移一点,效果往往超过一整套避震的调整。原因是身体的横向移动会让重心跟着移,这部分力最终由避震和轮胎承担——降低驾驶者重心等于直接减少这部分负荷转移。

    建议是:赛道日当天就把座椅调到你能承受的最低位置,不要为了舒适牺牲。这是所有调整项里成本最低、收益最确定、且完全可逆的一项。

    结束后该记录的三件事

    每次赛道日结束,凭感觉记下来的东西一周后就失真了。需要固化成文字的是这三件:

    记录项 要写清什么 用途
    最好圈 圈速,以及该圈是在什么条件下跑出来的(胎况、温度、圈序) 判断该圈是否可复制
    最大失分路段 具体分段编号,而非「后段有点慢」这类描述 下次直接定位到该段
    结束时的身体状态 专注度、疲劳程度、有无脱水或饥饿 把驾驶员状态纳入圈速归因

    第三项最容易被跳过,也最有价值:它让「今天慢是因为车」和「今天慢是因为人」这两种归因在事后还能被区分开。

    常见问题

    赛道日当天可以改避震设定吗?

    不建议。任何未在赛道日之前验证过的避震或胎压调整,都会把当天的有效时间浪费在适应上,而且改动之后的数据无法与历史数据对比,等于这次记录作废。当天只做已验证项的微调。

    冷胎压该设多少?

    不应把它当目标值。冷胎压只是起点,随着胎温上升胎压会升高 0.1–0.2 bar。正确做法是先定一个热胎目标压,跑几圈后实测再反推冷胎设定值。

    没睡好还要不要上赛道?

    需要主动降低预期与激进程度。睡眠不足会拉长反应时间,直接体现为刹车点推迟;这种迟钝没有体感,容易被误判成车辆问题,进而导致误调硬件。若当天无法补觉,至少把驾驶强度降一档。

    赛前热身做静态拉伸有什么问题?

    在冷车(身体未热)状态下做静态拉伸,会短暂降低力量输出。赛前热身应以动态拉伸为主,把静态拉伸放到赛后放松阶段。

    延伸阅读

    参考资料

    • 本站赛道库 —— /data/tracks/(赛前确认赛道几何与分段方案)
    • 本站文章 —— /blog/trackday-data-review-segment-method/(失分路段的记录口径)
    • 说明:本文属赛道工程实践经验总结,涉及生理反应的数值为经验量级,个体差异大,非医学结论。

    说明:本文为赛道日准备的经验性方法总结,文中 5 小时、20 米、20 mm、0.1–0.2 bar 等数值为便于说明方法引用的典型量级,非实测统计结果,不同车型与个人体质下差异可能很大。涉及身体状态与生理反应的内容不构成医学建议。任何车辆设定调整请以厂商规格与专业技师意见为准。

    更新记录

    首次发布 2026-10-13(原发布于建站期,本次按本站 GEO 规范重写:补充结论段、赛前两小时对照表与记录项表、常见问题与结构化数据)。最近核对:2026-10-13