企业官网建设流程全解析

一颗芯片的三个名字：BES2810、best1702 与 best1702_ibrt 关系深度解析

一句话剧透：这三个名字不是三颗芯片，也不是三个可以互换的编译宏，而是同一颗 SoC 在**“对外型号 → 芯片平台 → 产品形态”**三个层面的投影。看懂了它们，你就看懂了 BES SDK 整个构建体系的第一块多米诺骨牌。

目录

• 1. 技术背景：一个让新手怀疑人生的瞬间
• 2. 三个名字，三个世界：具体含义与功能定位
  • 2.1 BES2810 / BES2810ZP——对外产品型号（身份证名字）
  • 2.2 best1702——SDK 内部芯片平台标识（内部工号）
  • 2.3 best1702_ibrt——产品 target（具体岗位）
• 3. 技术关联性分析：三个名字如何咬合成一台机器
  • 3.1 构建系统的变量传递链
  • 3.2 三层闸门模型：能力、默认、传参
  • 3.3 一颗 DSP 的三层旅程（实例推演）
• 4. 应用场景对比：什么时候该用哪个名字
• 5. 可能的演进关系：从 best 命名谱系看未来
• 6. 开发注意事项：十个实战忠告
• 7. 总结

1. 技术背景：一个让新手怀疑人生的瞬间

每个接手 BES 平台的工程师，几乎都会经历同一个灵魂拷问时刻：

• 硬件同事甩来一份《BES2810ZP Datasheet》，说"我们用的是 BES2810"；
• 打开 SDK，发现 HAL 目录叫platform/hal/best1702/，地址映射头文件叫plat_addr_map_best1702.h；
• 跑构建脚本，命令行里赫然是T=best1702_ibrt；
• 想搜个 GPIO 驱动怎么写，网上的文章一会儿说 BES2800，一会儿说 best2300，一会儿又是 1702……

三个名字，到底听谁的？

这不是 BES 故意刁难人，而是任何一家芯片厂商都逃不掉的命名现实——对外营销名（型号）和内部工程名（平台代号）从来就是两条线。就像汽车圈：你在 4S 店买的是"秦PLUS"（商品名），工程师嘴里的却是"e平台3.0"（平台代号），而生产线排产单上写的可能是"SC7180A-DMi-120-FL"（具体配置代号）。

放到 BES2810 这里，对应关系就是：

BES2810ZP（芯片型号，对外发布） ←—— 数据手册、Release Note、BOM 表 │ best1702（芯片平台，SDK 内部标识） ←—— 芯片配置、HAL、寄存器、编译宏 │ best1702_ibrt（产品 target，形态） ←—— 耳机固件构建入口、板级配置

2. 三个名字，三个世界：具体含义与功能定位

2.1 BES2810 / BES2810ZP——对外产品型号（身份证名字）

定位：恒玄科技（Bestechnic，简称 BES）对外发布的芯片型号，出现在一切"给人看"的场合。

这颗芯片的硬件画像（数据手册 摘要）：

• 220-pin BGA 封装，4.1mm × 7.3mm × 0.79mm；
• 多核异构：4 × Cortex-M55（M55C0~C3）+HiFi 系列 DSP+ 独立 BT controller 核 +Ethos-U55 NPU；
• 8.3 MB 片上 SRAM + SiP 封装 Flash（8/16 MB 可选）；
• BR/EDR + BLE 双模音频平台，主打 TWS 耳机。

关键点：BES2810 是型号家族名，ZP 是具体的封装/配置后缀（类比骁龙 8 Gen3 vs 8 Gen3 for Galaxy）。你在数据手册、宣传材料、和 BES FAE 的邮件里看到的都是它。但它几乎不出现在编译系统里——全工程搜索2810，源代码层面的命中寥寥无几，且都是文档和第三方驱动的移植痕迹。

2.2 best1702——SDK 内部芯片平台标识（内部工号）

定位：BES 内部的芯片平台代号，是整个 SDK编译体系里"这颗芯片是谁"的唯一权威答案。

证据链：

① 构建入口处，target 把自己绑到这个芯片平台上（config/best1702_ibrt/target.mk:1）：

CHIP ?= best1702

② 芯片配置文件把它翻译成 C 宏（config/chips/best1702.mk:1）：

KBUILD_CPPFLAGS += -DCHIP_BEST1702

于是全工程所有 C 代码里的条件编译都以CHIP_BEST1702为判断依据——你在源码里搜BES2810是搜不到任何#ifdef的。

③ 它声明这颗芯片"具备什么能力"（config/chips/best1702.mk:42-81节选）：

export CHIP_HAS_USB := 1 export CHIP_HAS_CP := 1 # 有 CP 协处理器（多核） export CHIP_HAS_FPU := 1 # 有浮点单元 export CHIP_HAS_EXT_PMU := 1 # 支持外置 PMU export CHIP_HAS_HIFI4 := 1 # 有 HiFi4 DSP export CHIP_HAS_DMA2D := 1 export CHIP_HAS_SECURE_BOOT := 1

注意这些宏的命名规律：CHIP_HAS_*= 芯片能力层，它们回答的是"硅片里有没有这个电路"，而不是"这次编译用不用"。

④ 它决定了 HAL 的物理目录结构：

platform/hal/best1702/ ← best1702 专属 HAL（地址映射、CMU、睡眠） ├── plat_addr_map_best1702.h ├── hal_cmu_best1702.c └── ... platform/drivers/ana/best1702/ ← best1702 PMU/模拟寄存器 platform/drivers/bt/best1702/ ← BT controller 补丁

换一颗芯片（比如 best2300），这些目录整套换掉。这就是"芯片平台"的含义：同一套应用层代码，适配不同芯片时切换的底层分界线。

⑤ best 命名是一个大家族。看一眼config/chips/目录就明白了：

best1000.mk best1305.mk best1306.mk best1400.mk best1501.mk best1600.mk best1603.mk best1700.mk best1702.mk best2000.mk best2001.mk best2003.mk best2300.mk best2300p.mk best3001.mk ...

从 best1000 到 best3003，横跨 BES 十几年的产品线：1xxx 系早期蓝牙音频、2xxx 系智能手表、130x/150x/160x 中端耳机、1700/1702 这一代旗舰音频平台。best1702 是这个谱系里的最新一代音频平台成员。

2.3 best1702_ibrt——产品 target（具体岗位）

定位：基于 best1702 芯片平台的一个产品形态构建目标，回答"这次编出来的固件是给什么产品用的"。

证据链：

① Makefile 通过T变量选择 target（顶层Makefile:165）：

TARGET_CFG_FILE = config/$(T)/target.mk

构建时T=best1702_ibrt，就会加载config/best1702_ibrt/target.mk。

② 构建脚本里的真实用法（tools/build_1702_cmd.sh）：

bth_build_cmd="T=$TARGET_LISTCHIP=$CHIPID..."# TARGET_LIST=best1702_ibrt

注意这里T和CHIP是分开传的两个变量——target 和芯片平台是两个独立维度，虽然 best1702_ibrt 默认绑定 best1702（CHIP ?= best1702），但这个?=意味着命令行可以改。

③ 什么是 IBRT？

IBRT 是 BES 的 TWS（真无线立体声）主从协同技术，全称可理解为Intelligent Bluetooth Relay Technology（智能蓝牙中继）。它的核心思想是：两只耳机一主一从，只有主耳和手机保持蓝牙连接，从耳的数据靠主耳实时转发——耳间同步不依赖手机，延迟和功耗都更可控。这是 BES TWS 方案的看家本领，围绕它有一整套角色管理（master/slave 切换）、耳间命令（TWS 命令码 0x8000 基址）、双耳状态同步机制。target 名字里的_ibrt后缀，就是声明"这个固件形态走 IBRT TWS 路线"。

④ 同一块芯片，不止一个 target。看config/目录：

config/ ├── best1702_ibrt/ ← TWS 耳机主固件（本文主角） ├── cp_subsys/ ← M55C1 子系统镜像（A2DP 解码核） ├── cp_subsys1/ ← M55C2 子系统镜像 ├── cp_subsys2/ ← M55C3 子系统镜像（构建被注释，未启用） ├── dsp_m55/ ← DSP 固件形态 ├── dsp_m55c1/ ├── sensor_hub/ ← 传感器中枢形态 ├── prod_test/ ← 工厂产测固件 └── programmer_inflash/ ← 烧录器固件

这是理解 target 概念的关键：同一颗 best1702 芯片，可以编出耳机固件、产测固件、烧录器固件、各 CPU 子系统固件等不同 target。best1702_ibrt只是其中"TWS 耳机应用固件"这一个岗位。实际产线烧录时，一次完整构建会产出多个 target 的镜像（主固件 + bootloader + CP 子系统镜像），由build_1702_cmd.sh编排。

3. 技术关联性分析：三个名字如何咬合成一台机器

3.1 构建系统的变量传递链

三个名字不是并列关系，而是一条自上而下的装配流水线。用一张图看清整个咬合过程：

┌─────────────────────────────────────────────────────────────────┐ │ 你敲下的构建命令 │ │ make T=best1702_ibrt CHIP=best1702 DSP_HIFI4=1 ANC_APP=1 ... │ └────────────────────────────┬────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ 顶层 Makefile:165 │ │ TARGET_CFG_FILE = config/$(T)/target.mk │ │ T=best1702_ibrt → 加载 config/best1702_ibrt/target.mk │ └────────────────────────────┬────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ config/best1702_ibrt/target.mk:1 │ │ CHIP ?= best1702 ← target 声明"我基于哪颗芯片" │ │ （?= 可被命令行覆盖，但一般没人覆盖） │ │ ↓ include config/$(CHIP)/... │ └────────────────────────────┬────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ config/chips/best1702.mk │ │ KBUILD_CPPFLAGS += -DCHIP_BEST1702 ← 芯片身份进 C 宏域 │ │ CHIP_HAS_HIFI4 := 1 ← 芯片能力清单 │ └────────────────────────────┬────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────┐ │ compile_commands.json（最终真相） │ │ 每条编译命令携带 -DCHIP_BEST1702 及上百个功能宏 │ │ #if defined(CHIP_BEST1702) 的代码分支在这里尘埃落定 │ └─────────────────────────────────────────────────────────────────┘

而BES2810 在哪？它压根不在这条流水线上。它只活在数据手册、Release Note 和你与 FAE 的聊天记录里。芯片一旦流片，型号就定死了；SDK 里的 best1702 是工程世界给它的工号。

3.2 三层闸门模型：能力、默认、传参

理解三者关系的进阶版，是理解每一层各自"管什么"。这里有一个贯穿 BES SDK 的核心模型——三层闸门：

第 1 层闸门【芯片具备能力】 config/chips/best1702.mk CHIP_HAS_HIFI4 := 1 "硅片里有没有这块电路？" —— 物理事实，无人能推翻 ↓ 有能力 ≠ 会启用 第 2 层闸门【target 默认值】 config/best1702_ibrt/target.mk:461 DSP_HIFI4 ?= 0 "这个产品形态默认开不开？" —— ?= 是最弱赋值，专等被覆盖 ↓ 默认关 ≠ 实际关 第 3 层闸门【构建传参】 tools/build_1702_cmd.sh:133 HIFI_MCU="DSP_HIFI4=1 DSP_COMBINE_BIN=1 ..." "这次编译到底开不开？" —— 命令行变量优先级最高，一票拍板

为什么 target.mk 全用?=？这不是随手写的，而是 GNU make 的刻意设计：?=表示"仅当变量尚未定义时才赋值"，而命令行变量（make DSP_HIFI4=1）的优先级高于一切普通赋值。所以 target.mk 里的默认值本质上是给命令行让路的兜底值。三层结论经常互相矛盾，而这恰恰是 BES 用同一套 SDK 灵活裁剪出不同产品的方法论。

3.3 一颗 DSP 的三层旅程（实例推演）

拿本工程最典型的 HiFi4 DSP 串一遍三层（全部实测数据）：

结论：能力有、默认关、传参开 → 实际在跑。本工程的通话算法（AEC/NS 等）就跑在这颗"默认关闭但被传参打开"的 DSP 上。

再补一个反例，让模型更立体——触摸检测：config/best1702/capsensor_cfg.mk里CAPSENSOR_TOUCH ?= 1默认开启，但build_1702_cmd.sh:130传了CAPSENSOR_TOUCH=0强制关闭，实测 compile_commands 中 0 条命中。默认开 ≠ 实际开。两个例子一正一反，三层闸门的权威排序一目了然：命令行 > 默认值 > 芯片能力（能力层甚至都不直接产生-D宏）。

4. 应用场景对比：什么时候该用哪个名字

一张速记图：

看到 BES2810 → 想到"这颗芯片是什么"（硬件视角，查手册） 看到 best1702 → 想到"代码怎么适配这颗芯片"（平台视角，查 HAL） 看到 best1702_ibrt→ 想到"这次编的是什么产品"（产品视角，查 target 配置）

5. 可能的演进关系：从 best 命名谱系看未来

5.1 内部代号与型号的"代际错位"

best1702与BES2810的数字并不同步（1702 vs 2810），这不是 bug，而是两条命名轨道：

• best 谱系（内部工程线）：config/chips/下从 best1000 一路排到 best3003，是 BES 十余年平台演进的化石层。1700/1702 属于最新的旗舰音频平台代际；
• 2810 谱系（对外产品线）：BES2xxx 系列面向市场定位命名（如 BES2800 是上一代旗舰）。BES2810 大概率是搭载 best1702 平台（或其衍生版本）的首发对外型号。

这种"内部代号 ≠ 对外型号"在业界是常态（高通骁龙的 SM8xxx 内部号 vs 8 Gen X 商品名，联发科 MT68xx vs 天玑 xxxx，皆同此理）。可以预期：best1702 平台未来可能衍生出多个对外型号（不同封装/存储/裁剪配置，类似 BES2810ZP 中的 ZP 后缀细分），届时数据手册会多几个兄弟，但 SDK 里它们大概率仍共用best1702这套芯片配置——型号管市场，平台管代码。

5.2 一个值得玩味的细节：DSP 命名冲突

数据手册 标称 DSP 为 “Tensilica HiFi 5s@ 240MHz”，而 SDK 全线使用CHIP_HAS_HIFI4、platform/drivers/hifi4/命名。这不是笔误，更可能是：软件框架沿用上一代 HiFi4 的驱动框架名，硬件 DSP 已升级到 HiFi 5s 内核。对开发者的实际影响：

• 读 SDK 代码、查 IPC 接口时，按hifi4关键字搜索；
• 评估算力、看性能指标时，以数据手册的 HiFi 5s 规格为准；
• 两者混着叫时，心里要清楚指的是同一个东西。

这类"框架名滞后于硬件代际"的现象，恰恰是"平台标识（best1702）相对稳定、型号（BES2810）快速迭代"的又一佐证——内部代号承载兼容性，对外型号承载营销节奏。

5.3 多核 target 的演进方向

config/下 cp_subsys / cp_subsys1 / cp_subsys2 三个 CP 子系统 target 的存在（其中 cp_subsys2 的构建调用在build_1702_cmd.sh中被注释），暗示这颗 4 核 M55 平台的算力尚未被完全释放。随着 LE Audio、端侧 AI（Ethos-U55 NPU 已在硅片中，SDK 已有U55_TEST传参入口）逐步落地，可以预期 target 家族会继续扩张——芯片能力是存量，target 是增量，这也是三层闸门模型的生命力所在。

6. 开发注意事项：十个实战忠告

1. 搜代码别用 BES2810。源码里芯片身份是CHIP_BEST1702，用型号名搜索只会收获一堆文档命中。同理，寄存器、地址映射都在best1702目录下。

2. 改配置前先想清楚改哪一层。芯片能力（config/chips/best1702.mk的CHIP_HAS_*）、产品默认（config/best1702_ibrt/target.mk）、板级资源（tgt_hardware.h/.c）是三个不同的管辖范围——改错层轻则无效，重则工厂构建翻车。

3. 永远以 compile_commands.json 为唯一真相。target.mk里写着?= 0的宏，可能被build_1702_cmd.sh传参打开；写着?= 1的，可能被显式传 0 关闭。判断"某功能这次编译生效没"，数 compile_commands 里的-D命中数，别信配置文件的表面值。

4. 宏计数要防前缀误伤。搜索GFPS会命中GFPS_ENABLED等长名前缀；判定宏生效必须用精确边界正则（如-DNAME(=|\s|")），否则统计结果能虚高几倍。

5. 同一个 target 名会出现在四个地方，缺一不可：config/best1702_ibrt/（配置目录）、make T=best1702_ibrt（构建命令）、out/best1702_ibrt/（产物目录）、tools/build_1702_cmd.sh（编排脚本）。排查构建问题时顺着这条线走。

6. 改 HAL 要检查双副本。部分 HAL 文件存在主核与 hifi4 子系统两份副本（如hal_key.c、hal_sleep.c），改主核必须同步另一份；但audioflinger.c的 hifi4 副本未参与编译、无需同步。哪些要同步、哪些不用，必须用 compile_commands 逐个验证，不能靠猜。

7. 型号带 Draft 标记时，硬件参数以最新手册为准并与 FAE 确认。BES2810ZP 手册 Rev 0.41 处于 Pre-preliminary 阶段，引脚复用、电气参数存在调整可能；SDK 代码与手册冲突时（如 DSP 命名），代码为准做开发、双方证据留档、找 FAE 书面澄清。

8. 和 BES 对接时切换到"型号频道"。FAE、商务、Release Note 都按 BES2810ZP 建档；直接甩 best1702_ibrt 过去，对方可能需要先做一次脑内翻译。附上 SDK 版本号（Release Note v1.7）能大幅提升沟通效率。

9. 新开产品线优先评估"改 target"而非"改芯片层"。BES 的裁剪粒度设计：同芯片出不同产品靠不同 target（或同一 target + 不同传参），芯片层配置基本不动。想在 best1702 上做一个非 TWS 产品？第一反应应该是"要不要新建一个 target"，而不是动config/chips/。

10. 别忘了构建产物是多 target 拼装的。build_1702_cmd.sh一次完整构建包含主固件（best1702_ibrt）、bootloader（prod_test/ota_copy）、CP 子系统（cp_subsys、cp_subsys1）多个 target。只重编主固件不重编子系统镜像，是跨核接口不同步事故的高发源头——尤其改了跨核 IPC 相关代码时。

7. 总结

回到开头的问题：BES2810、best1702、best1702_ibrt 是什么关系？

它们是一颗芯片的三个名字，分别回答三个问题：

一条装配链串起三者：型号定芯片（BES2810ZP = best1702 平台的某个流片版本）→ 平台承载代码（best1702 提供 HAL 与能力宏）→ target 定义产品（best1702_ibrt = best1702 上的 TWS 耳机形态）。

而对日常开发更有用的是那条三层闸门铁律：芯片能力（CHIP_HAS_*）说明"能不能"，target 默认值（?=）说明"默认开不开"，构建传参（命令行）说明"这次开没开"——三层结论可以互不相同，最终生效与否只看 compile_commands.json。

记住一句话就够了：查手册认型号，读代码认平台，改配置认 target，判生效认编译数据库。