前言
现在为止也开发了许多杰理和中科蓝讯蓝牙芯片的TWS蓝牙耳机、音响项目 SDK 的案子，在调试案子时不断的向前辈们学习到了很多关于蓝牙音响、蓝牙TWS耳机专业的知识。想在这里做一个学习汇总，方便各位同行和对中科蓝汛芯片SDK感兴趣的小伙伴们学习；
本章详细讲解中科蓝讯蓝牙芯片架构原理与开发教程
本章针对中科蓝讯蓝牙音频芯片，从硬件存储架构、核心运行机制到开发规范进行系统性讲解，帮助小伙伴快速掌握芯片的框架原理，规避开发中的经典问题。
芯片整体架构总览
内核与系统基础
中科蓝讯蓝牙芯片采用32 位 RISC-V 开源指令集内核，搭载国产 RT-Thread 实时操作系统。操作系统核心代码已被封装为静态库，普通应用开发无需修改或接触系统底层代码，大幅降低了开发门槛。
总线结构
芯片采用冯・诺依曼结构，即程序代码与数据采用统一地址空间编址，CPU 通过同一条总线完成取指与数据读写。
核心存储结构
芯片采用「外部 SPI Flash 存储 + 内部 RAM 运行」的两级存储架构，这是整个芯片框架的核心设计：
1、程序与数据无法直接在 Flash 上执行，必须先通过 SPI 接口搬运到芯片内部 RAM 中，CPU 再从 RAM 读取指令和数据运行。
2、该设计平衡了 “大容量存储” 与 “高速运行” 的需求，同时控制了芯片成本。
整体存储映射关系如下图所示：
1、左侧：外部 SpiFlash（掉电不丢失，容量大，速度慢），分为资源参数区、bank 程序存储区、com 程序存储区
2、右侧：芯片内部 RAM（掉电丢失，容量小，速度快），分为 MASK 程序区、专用 RAM、bank 运行区、com 运行区
3、数据通路：Flash 与 RAM 之间通过 SPI 总线通信，完成代码与数据的加载搬运
存储系统分层详解
SpiFlash 是芯片的 “外置硬盘”，用于持久化存储所有程序与数据，常见容量为512KB 或 1MB，从上到下分为三个区域：
1、资源与掉电参数区：存放非程序类数据，包括提示音音频文件、EQ 音效配置、用户掉电记忆参数等。
2、bank 程序存储区：存放绝大多数应用层代码，容量通常在几百 KB 级别，是程序的主体存储区。
3、com 程序存储区：存放核心公共程序代码，容量较小，对应 RAM 中的常驻运行区。
芯片内部 RAM 运行空间：
1、MASK 程序区：芯片出厂时固化的掩膜程序，是芯片上电后的启动入口，负责基础硬件初始化、Flash 引导加载等底层逻辑，用户不可修改。
2、其它专用 RAM：供蓝牙基带、音频编解码、外设寄存器等硬件模块使用的专用内存空间，不用于存放用户程序。
3、bank 程序运行区：相当于 Flash bank 区的 “运行缓存（Cache）”，容量仅几 KB 到几十 KB，用于动态加载 Flash 中 bank 区的代码，空间不足时会自动覆盖旧代码。
4、com 程序运行区（公共区）：常驻内存的程序运行区，com 区代码上电后一次性加载完成，程序运行全程不会被换出，CPU 可高速访问。
程序加载运行完整流程：
1、上电启动阶段：CPU 从内部 MASK 程序区开始执行，完成时钟、SPI 接口等基础硬件初始化。
2、com 区加载：MASK 引导程序通过 SPI 接口，将 Flash 中 com 存储区的全部代码一次性搬运到内部 RAM 的 com 运行区，该过程仅在上电时执行一次。
3、主程序运行阶段：程序进入 main 函数后，com 区代码常驻 RAM，CPU 可直接高速执行；当 CPU 需要执行 bank 区的函数时，芯片自动触发 SPI 传输，将对应地址的代码块加载到 RAM 的 bank 运行区，若 bank 运行区空间已满，则自动覆盖不活跃的代码块，实现动态换入换出。
核心概念：com 区与 bank 区深度解析
com 区与 bank 区是中科蓝讯开发最核心的概念，二者的运行机制、性能、使用场景有本质区别。
4.1 com 区（公共常驻区）
1、核心定位：高实时性、高频率调用的核心代码的常驻内存区
2、加载机制：上电启动时一次性完整加载，程序全生命周期内常驻 RAM，不会被替换
3、容量限制：通常在几十 KB 以内，受限于芯片内部 RAM 总大小，空间宝贵
4、运行性能：CPU 直接从 RAM 取指，无额外 SPI 通信开销，执行速度快，响应延迟极低且确定
5、典型使用场景：中断服务函数、定时器回调、高频核心控制逻辑、实时性要求高的音频处理
4.2 bank 区（动态加载区）
1、核心定位：主体应用程序的存储区，承担大容量代码存储的角色
2、加载机制：按需动态加载，CPU 执行到未缓存的 bank 代码时，自动触发 SPI 搬运；空间不足时自动覆盖旧代码，整个过程对开发者透明
3、容量特性：Flash 中存储容量可达几百 KB，远大于 RAM 中对应的运行缓存区
4、运行性能：存在潜在的 SPI 加载延迟，执行速度低于 com 区；频繁换入换出会进一步降低性能，同时 SPI 的 IO 电平翻转会引入电磁干扰
5、典型使用场景：非实时主逻辑、UI 界面、配置处理、低频调用的功能函数、字符串等常量数据
开发核心规范与注意事项
中断函数必须全部放在 com 区：
1、硬性规则：中断服务函数（ISR）及其调用链上的所有子函数、用到的常量数据，必须全部指定到 com 区，否则会直接导致芯片死机。
2、底层原理：中断响应要求极低的延迟确定性，若中断函数位于 bank 区，中断触发时代码可能仍在 Flash 中，需要先完成 SPI 加载才能执行，无法满足实时性要求。芯片固件做了强制限制：中断上下文内若触发 bank 代码加载，直接进入异常死机状态。
中断内 switch 语句的特殊限制
问题根源：C 语言的 switch 语句，编译器默认会生成独立的跳转表（jump table），默认情况下跳转表会被存放在 bank 区；若中断函数内使用 switch，执行时访问 bank 区的跳转表，会触发加载异常导致死机。
解决方案：
1、优先使用if-else分支替代 switch 语句，从根源上避免生成跳转表。
2、若必须使用 switch，需确认工程编译选项中添加了-mjump-tables-in-text参数，该参数会让编译器将跳转表生成在函数代码段内部，随函数一起存放在 com 区。
3、版本差异：早期 SDK 默认不带该编译选项，禁止在中断中使用 switch；新版 SDK 通常已默认添加，可正常使用，建议开发前确认编译配置。
高实时性代码优先放入 com 区
对于延时敏感、调用频率高的逻辑（如按键消抖、实时控制、定时器回调等），优先分配到 com 区，保证执行速度和响应确定性。
注意：com 区容量非常有限，需合理规划，仅将必要的逻辑放入，避免空间溢出。
默认分区规则
没有通过AT()手动指定段名的函数、常量，编译器默认全部放入 bank 区。bank 区的加载、替换完全由芯片固件自动完成，开发者无需手动管理内存调度。
5.5 电磁敏感场景的 bank 优化
1、问题背景：SPI 通信时 IO 口电平高速翻转，会产生电磁干扰，对 FM 收音、模拟音频采集等敏感电路会引入噪声。
2、优化方法：将同一功能模块（如 FM 全部相关函数）的代码，指定到同一个自定义命名的 bank 段中；芯片加载时会尽可能将整个 bank 段一次性加载到 RAM，减少运行过程中频繁的 SPI 加载动作，从而降低干扰噪声。
制作不易！喜欢的小伙伴给个小赞赞！喜欢我的小伙伴点个关注！有不懂的地方和需要的资源随时问我哟！
