芯片平台总览与差异

本文介绍 fw-AC63_BT_SDK 中芯片平台的总体划分、各平台（bd19 / br23 / br25 / br34，以及仓库中存在的 bd29 / br30）的芯片型号、在工程中的组织方式、编译烧录机制以及平台之间的关键差异，帮助开发者根据产品需求选择合适的芯片平台并理解跨平台移植要点。

Purpose and Scope

本页面向需要为 AC63 系列芯片选型、或需要在不同芯片平台之间移植/对比代码的开发者，覆盖以下内容：

• AC63 系列 SDK 支持的芯片平台划分与命名规则；
• 各平台对应的芯片型号、定位与适用应用（SPP+BLE / HID / Mesh）；
• 芯片平台在 SDK 工程中的组织方式（apps/*/board/、cpu/*/liba、cpu/*/tools）；
• 平台之间的差异维度（库文件、板级配置、编译目标、烧录工具）；
• 从选型到编译烧录的核心流程。

以下主题不在本页范围内，由同目录下的兄弟页面分别介绍：

• 应用工程细节（spp_and_le / hid / mesh 的具体实现）——参见对应的应用开发文档页；
• 单板级配置（具体引脚的 board_xxx_cfg.h、功能开关 board_xxx_global_build_cfg.h）——参见"板级配置"相关页面；
• 编译环境与工具链安装——参见"环境搭建/编译指南"相关页面。

Overview

fw-AC63_BT_SDK 是杰理科技为 AC63 系列芯片提供的通用蓝牙 SDK 固件开发包，基于 Zephyr RTOS 实时操作系统，提供完整的蓝牙协议栈与丰富的应用示例，覆盖 SPP + BLE 透传/数传、HID 人机交互 与 Bluetooth Mesh 三类典型应用场景（README.md）。

"芯片平台"是 SDK 中对同一系列芯片的工程抽象：同一平台内的芯片共享同一套预编译库（lib.a）、工具脚本与板级配置模板，差异主要体现在芯片型号、Flash/RAM 容量与封装引脚。SDK 按 cpu/ 目录下的平台名组织代码与库文件，并在 apps/*/board/ 下为每个平台提供独立的板级配置目录。

核心概念速览：

蓝牙协议方面，SDK 支持 Bluetooth Core v5.4，QDID 222830 已认证（README.md），这意味着所有平台共享同一套经过认证的蓝牙协议栈能力，平台间差异主要体现在外设资源与射频/功耗特性上。

Architecture

芯片平台在 SDK 工程中处于"承上启下"的位置：向上支撑应用层（apps/）的板级配置，向下对接芯片硬件与预编译库（cpu/）：

flowchart TD
    subgraph sg_Apps["应用层 apps/"]
        A1["spp_and_le (SPP+BLE 透传)"]
        A2["hid (键鼠/遥控/手柄)"]
        A3["mesh (Bluetooth Mesh)"]
    end

    subgraph sg_Board["板级配置层 apps/*/board/"]
        B1["bd19 / AC632N 系列"]
        B2["br23 / AC635N 系列"]
        B3["br25 / AC636N 系列"]
        B4["br34 / AC638N 系列"]
    end

    subgraph sg_Cpu["芯片平台支撑层 cpu/"]
        C1["liba 预编译库 (btctrler/btstack/media)"]
        C2["tools 工具 (download.bat/fw_add.exe)"]
    end

    subgraph sg_Include["接口层 include_lib/"]
        D1["蓝牙协议栈/驱动/媒体公共头文件"]
    end

    A1 --> B1
    A1 --> B2
    A1 --> B3
    A1 --> B4
    A2 --> B1
    A2 --> B2
    A2 --> B3
    A2 --> B4
    A3 --> B1
    A3 --> B2
    A3 --> B3
    A3 --> B4
    B1 --> C1
    B2 --> C1
    B3 --> C1
    B4 --> C1
    B1 --> C2
    C1 --> D1

架构解读：

• 应用层（apps/）只关心业务逻辑，不直接感知具体芯片；它通过 board/ 下的板级配置与平台对接。
• 板级配置层是"平台差异"的主要集中地：每个应用目录下按平台划分 board/ 子目录（如 apps/hid/board/bd19/），包含 Makefile、board_*.cbp、board_xxx.c（板级初始化）、board_xxx_cfg.h（引脚/外设配置）与 board_xxx_global_build_cfg.h（功能开关）（README.md）。
• 芯片平台支撑层（cpu/）存放各平台的预编译静态库（liba/）与烧录工具（tools/，如 download.bat、fw_add.exe、isd_download.exe）。库文件是平台差异的最底层体现——同一应用在不同平台编译时链接的是不同的 lib.a（README.md）。
• 接口层（include_lib/）提供跨平台一致的蓝牙协议栈、驱动、媒体等头文件，是"平台差异被屏蔽"的关键：应用代码只需包含公共头文件，具体实现由各平台库文件提供。

芯片平台详述

支持的芯片平台与型号

根据 README 的"支持的芯片与平台"章节，SDK 当前发布版支持四个主力平台，覆盖从入门到高性能的完整产品线（README.md）：

此外，仓库 cpu/ 目录下还保留了 bd29（AC630N）与 br30（AC897N）平台的配置工具目录（如 cpu/bd29/tools/AC630N_config_tool/、cpu/br30/tools/AC897N_config_tool/），说明这些平台在 SDK 历史上被支持或用于特定产品线；当前 README 主推的发布平台为 bd19 / br23 / br25 / br34 四个。

平台定位与选型逻辑

从型号编号可以读出平台的定位规律：

• bd19（AC632x / AC632N）：入门级平台，型号最丰富（9 个型号），覆盖从低容量到带完整功能的产品梯度，是 SDK 的默认演示平台（编译示例 make ac632n_spp_and_le 即以 AC632N 命名）。
• br23（AC635x / AC635N）：中端平台，型号较少，面向成本与性能均衡的 SPP/HID/Mesh 产品。
• br25（AC636x / AC636N）：中高端平台，型号覆盖 AC6363F/AC6366C/AC6368A/AC6368B/AC6369C/AC6369F/AC636N，适合对性能、资源有更高要求的应用。
• br34（AC638x / AC638N）：高端平台，代表 AC63 系列的最高规格（AC6381A/AC6385A/AC638N）。

三个应用（spp_and_le / hid / mesh）在所有四个平台上均有板级支持，因此选型时首先确定应用类型，再按成本/资源需求选择平台，最后在平台内挑选具体型号。

板级配置的组织差异

每个应用目录下都有 board/ 子目录，按芯片平台划分。以 apps/hid/board/ 为例（README.md）：

apps/hid/board/
├── bd19/   # AC632N 系列 (32个板级配置)
├── br23/   # AC635N 系列
├── br25/   # AC636N 系列
└── br34/   # AC638N 系列

每个板级目录内的文件结构完全一致，这是平台差异被"模板化"的体现——换平台时，目录结构、文件职责不变，变的只是具体内容：

库文件与工具的差异

cpu/ 目录是平台差异的物理载体（README.md）：

cpu/
├── bd19/ → br34/    # 各芯片平台的 lib.a 库文件 + 工具脚本

• cpu/<platform>/liba/：预编译静态库，包括 btctrler（蓝牙控制器）、btstack（蓝牙协议栈）、media（媒体）等模块。不同平台对应不同的 *.a 文件，应用代码通过 include_lib/ 的公共头文件调用，链接期由板级 Makefile 选择具体平台的库。
• cpu/<platform>/tools/：烧录工具，如 download.bat、fw_add.exe、isd_download.exe 等，与芯片的烧录协议/升级工具链绑定。

这意味着跨平台移植时，最需要关注的是板级配置与库文件匹配：应用逻辑（apps/*/）与公共头文件（include_lib/）基本可复用，但必须为每个平台重新生成/维护 board 目录，并链接该平台自己的 lib.a。

平台差异维度总结

核心流程：从选型到编译烧录

芯片平台的选择贯穿整个开发流程。下图展示了从产品需求到固件产物的完整路径：

flowchart TD
    Start([产品需求]) --> App{"应用类型?"}
    App -->|"数据透传/Dongle/FindMy"| SPP["apps/spp_and_le"]
    App -->|"键盘/鼠标/遥控/手柄"| HID["apps/hid"]
    App -->|"智能照明/传感网络"| MESH["apps/mesh"]
    SPP --> Plat{"平台选型"}
    HID --> Plat
    MESH --> Plat
    Plat -->|"入门"| P1["bd19 / AC632N 系列"]
    Plat -->|"中端"| P2["br23 / AC635N 系列"]
    Plat -->|"中高端"| P3["br25 / AC636N 系列"]
    Plat -->|"高端"| P4["br34 / AC638N 系列"]
    P1 --> Board["进入 apps/<app>/board/<platform>/"]
    P2 --> Board
    P3 --> Board
    P4 --> Board
    Board --> Build{"编译方式"}
    Build -->|"Windows IDE"| CBP["打开 board_*.cbp (Code::Blocks)"]
    Build -->|"命令行"| MK["make <chip>_<app> (如 ac632n_spp_and_le)"]
    Build -->|"VS Code"| VSC["Ctrl+Shift+B 选择任务"]
    CBP --> Lib["链接 cpu/<platform>/liba 对应库"]
    MK --> Lib
    VSC --> Lib
    Lib --> Hex["生成 .hex 固件"]
    Hex --> Burn["USB 升级工具 / 生产烧写工具 烧录"]
    Burn --> End([产品固件])

流程要点：

1. 确定应用：三个应用（spp_and_le / hid / mesh）均支持全部四个平台，先选应用再选平台；
2. 选择平台：按成本/资源/性能梯度在 bd19 → br23 → br25 → br34 中选择；
3. 定位板级目录：进入 apps/<app>/board/<platform>/，该目录已按平台模板化，包含编译脚本、工程文件与板级初始化代码（README.md）；
4. 编译：三种方式殊途同归——Code::Blocks 打开 .cbp、命令行 make <chip>_<app>、或 VS Code 预置任务。命令行示例 make ac632n_spp_and_le 揭示了 target 命名规则为 <芯片型号缩写>_<应用名>（README.md）；
5. 链接平台库：编译时板级 Makefile 选择 cpu/<platform>/liba/ 中对应平台的静态库；
6. 烧录：编译产物 .hex 通过 USB 升级工具或生产烧写工具烧录到目标板。

平台选择机制的代码依据

平台选择的核心机制是目录即配置：Makefile target 名（ac632n_*）与板级目录（apps/*/board/bd19/）、库文件目录（cpu/bd19/liba/）三者通过命名约定关联。README 明确说明"所有支持的 target 名称见顶层 Makefile 开头的注释"（README.md），即编译入口由顶层 Makefile 统一分发，各 target 映射到具体的板级目录。

工程目录中平台相关路径的对应关系如下（README.md）：

平台与应用映射关系

所有平台共享同一套蓝牙协议能力（Core v5.4 已认证），因此平台与应用的映射是一张"全连接"矩阵——每个平台都支持全部三个应用：

flowchart LR
    subgraph sg_Platforms["芯片平台"]
        P1["bd19"]
        P2["br23"]
        P3["br25"]
        P4["br34"]
    end
    subgraph sg_Apps2["应用"]
        A1["spp_and_le"]
        A2["hid"]
        A3["mesh"]
    end
    P1 --> A1
    P1 --> A2
    P1 --> A3
    P2 --> A1
    P2 --> A2
    P2 --> A3
    P3 --> A1
    P3 --> A2
    P3 --> A3
    P4 --> A1
    P4 --> A2
    P4 --> A3

这张"全连接"矩阵是 SDK 设计意图的直接体现：应用逻辑与芯片平台解耦——应用代码通过 include_lib/ 公共接口访问协议栈，通过 board/ 模板化配置访问硬件，因此任意平台组合都能编译出可用固件。开发者需要做的平台相关工作，是维护好对应 board/ 目录下的引脚与外设配置。

使用示例

以下示例均提取自仓库实际源码/文档，展示如何在工程中定位与使用芯片平台。

示例 1：查看应用的板级平台目录

选择应用后，进入 apps/<app>/board/ 即可看到按平台划分的目录结构（以 apps/hid/board/ 为例）：

apps/hid/board/
├── bd19/   # AC632N 系列 (32个板级配置)
├── br23/   # AC635N 系列
├── br25/   # AC636N 系列
└── br34/   # AC638N 系列

Source: README.md

该结构说明：bd19 是板级配置最丰富的平台（32 个配置），br23 / br25 / br34 的配置数量随平台定位减少——入门平台型号多、板级变体多，高端平台面向定制化产品、预置变体较少。

示例 2：命令行编译指定平台目标

命令行编译是跨平台差异最直观的体现——target 名直接编码了芯片型号与应用名：

# Windows 用户
双击 tools/make_prompt.bat 打开命令行环境

# Linux/macOS 用户
cd SDK 根目录

# 编译完整工程
make ac632n_spp_and_le

# 编译完成后，在对应 board 目录下找到生成的 .hex 文件

Source: README.md

ac632n_spp_and_le 可拆解为 <芯片型号:AC632N>_<应用:spp_and_le>：芯片型号决定链接 cpu/bd19/liba/ 中的库，应用名决定编译 apps/spp_and_le/ 的代码。换平台编译时，只需替换 target 名中的芯片型号前缀（如 ac636n_hid、ac638n_mesh），无需改动应用代码——这就是平台差异被命名约定屏蔽的体现。

示例 3：SDK 工程结构中平台相关目录

fw-AC63_BT_SDK/
├── apps/                          # 应用层代码
│   ├── spp_and_le/                # 📌 SPP + BLE 应用
│   ├── hid/                       # 📌 HID 应用（键盘/鼠标/遥控器/游戏手柄）
│   └── mesh/                      # 📌 Mesh 应用
├── cpu/                           # CPU 相关代码与库文件
│   ├── bd19/ → br34/              #   各芯片平台的 lib.a 库文件 + 工具脚本
├── include_lib/                   # 头文件（bt协议栈、驱动、媒体、系统等）
├── tools/                         # 编译工具与脚本
└── Makefile                       # 顶层 Makefile（统一编译入口）

Source: README.md

示例 4：应用选型对照（平台 + 场景）

以 HID 应用为例，选型时平台无关（四个平台均支持），差异体现在示例子应用与参考文档：

适用场景: 蓝牙键盘、鼠标、遥控器、自拍器、游戏手柄（吃鸡王座）、语音遥控器
示例应用: examples/mouse_single/ 鼠标 / examples/keyboard/ 键盘 /
          examples/gamebox/ 游戏手柄 / examples/voice_remote_control/ 语音遥控

Source: README.md

配置选项

平台层面的"配置"主要通过板级目录中的文件表达，跨平台差异集中于此：

说明：各平台 config_tool 目录的存在（如 cpu/bd19/tools/AC632N_config_tool/、cpu/br25/tools/AC696X_config_tool/）表明配置工具与芯片平台强绑定——同一款配置工具不一定能跨平台复用，进行参数配置时需选择目标平台对应的工具版本。

失败模式、边界情况与注意事项

基于源码证据，跨平台开发中常见的问题与对应预防措施如下：

库文件与平台不匹配

• 现象：链接错误、undefined symbol，或烧录后行为异常。
• 根因：cpu/<platform>/liba/ 中的静态库是按芯片平台预编译的（btctrler、btstack、media 等），不同平台的库不能混用。
• 预防：编译时确认 target 名的芯片前缀与 cpu/ 下平台目录一致（如 ac632n_* 对应 bd19）；不要手动替换/混用不同平台的 *.a 文件。

板级配置未同步

• 现象：外设不工作、引脚冲突、低功耗异常。
• 根因：board_xxx_cfg.h（引脚/外设）与 board_xxx_global_build_cfg.h（功能开关）是平台/型号强相关的，同平台不同型号（如 AC6328A 与 AC6329B）的引脚资源也可能不同。
• 预防：换平台/换型号时，以目标 board/ 目录下已存在的配置为基准修改，而不是从其他平台复制后猜测。

配置工具跨平台误用

• 现象：配置写入失败或参数无效。
• 根因：cpu/<platform>/tools/ 下各平台 config_tool 相互独立（AC632N / AC630N / AC695X / AC696X / AC897N / AC698N）。
• 预防：使用与目标芯片型号匹配的 config_tool 版本。

平台型号覆盖不完整

• 现象：某些平台缺少目标应用/型号的板级配置。
• 说明：bd19 有 32 个板级配置，而 br23 / br25 / br34 的预置配置较少；若找不到目标型号的 board，需基于同平台最接近型号的 board 新建配置，并注意 lib.a 是否支持该型号。
• 边界情况：README 发布的平台为 bd19 / br23 / br25 / br34；仓库中仍保留 bd29（AC630N）、br30（AC897N）的 config_tool 目录，但当前发布文档未将其列为推荐平台——使用前需确认对应 lib.a 与工具链可用。

工具链与环境差异

• Windows 推荐 Code::Blocks，Linux 支持 Makefile 命令行；两种方式生成的固件应一致，但环境变量（工具链路径、/opt/jieli 安装位置）不一致会导致编译失败，不属于平台差异，但与平台库的链接环节相关。

性能与运维考量

• 库按平台预编译：lib.a 已针对平台指令集/外设优化，应用层无需（也不应）重新实现协议栈；性能调优应聚焦板级配置（时钟、电源）而非应用代码。
• 蓝牙能力全平台一致：Core v5.4 已认证（QDID 222830），各平台蓝牙吞吐/连接能力的上限由射频硬件决定，差异主要在外设资源与功耗，选型时结合数据手册评估。
• 升级链路：烧录依赖 cpu/<platform>/tools/ 下的工具（USB 升级工具、生产烧写工具），量产前需按平台验证升级流程。

扩展点

• 新增芯片型号：若现有平台内新增型号，通常在对应 apps/*/board/<platform>/ 下新建板级目录（仿照最接近的型号），确认 cpu/<platform>/liba/ 支持该型号后即可编译。
• 新增平台：需要新增 cpu/<new_platform>/（liba + tools）并在各应用的 board/ 下新增目录、在顶层 Makefile 注册新 target——这是平台级扩展，建议联系杰理获取对应库文件。
• 功能裁剪：通过 board_xxx_global_build_cfg.h 与 apps/*/config/ 控制编译进固件的库功能，跨平台裁剪方式一致。

Related Links

• README.md（支持的芯片与平台、工程结构）
• README.md（板级配置目录说明）
• README.md（编译指南：Code::Blocks / Makefile / VS Code）
• README.md（关键目录说明：liba / tools / config）
• 应用工程：apps/spp_and_le、apps/hid、apps/mesh（对应应用开发文档页）
• 板级配置：apps/*/board/<platform>/（对应"板级配置"相关页面）
• 编译/烧录工具链：tools/、cpu/<platform>/tools/（对应"环境搭建与编译指南"相关页面）

说明：本文所有芯片型号、平台划分、目录结构与编译机制均以仓库 README 及目录清单为依据；涉及具体芯片寄存器、Flash/RAM 容量等细节，请查阅 doc/datasheet 下的数据手册。