归档 on 栈外随记

我为什么越来越看好 AI 眼镜

Sun, 01 Nov 2026 00:00:00 +0800

最近研究了一圈 AI 眼镜，我越来越觉得，这个东西值得认真关注。

一、为什么这么多厂商都在做

按照 Omdia 的估算，2025 年全球 AI 眼镜出货量约 870 万副，接近 900 万副。市场还不大，但已经吸引了不少厂商进场。大家争的除了眼前的销量，还有未来 AI 入口的位置。

眼镜的位置，确实太好了。眼睛、耳朵、嘴巴都在附近，适合采集画面、接收声音，再通过语音或者显示给你反馈。遇到不认识的东西，看着它问一句，AI 就能结合画面回答，不用再拿着手机对准、拍照、上传。

手机当然也能做，但眼镜有机会把这些操作变得更自然。尤其当你正在走路、搬东西，或者双手忙着的时候，这个区别就出来了。

我看好的，其实是 AI 从“等你提问”，慢慢变成一个能理解你当下处境的助手。它知道你刚才让它看了什么，正在处理什么事情，再结合这些信息提供帮助。如果做得好，交流起来就不用每次都从头解释。

二、眼镜能帮我们做什么

翻译，导航，拍摄，录屏，听歌，提词、消息提醒，扫码付款，全天候记录等等，这些都是比较容易想到的场景。并且，交互也不只有语音。或者触摸按键，眨眼这种控制，Meta 已经推出配合眼镜使用的肌电腕带，通过手腕处的肌肉电信号识别细微动作，让人动动手指就能操作。在不方便开口的时候，也能通过手势完成选择、确认等操作。

三、一个能帮人记住事情的助手

不过，最让我感兴趣的，还是“帮人记住事情”。临时冒出一个想法，说一句就保存下来；过了几天想不起细节，再问它：“上次那件事，我们最后怎么说的？”

如果这些能力足够可靠，眼镜就不只是拍摄工具了。它可能逐渐积累起一个和你生活有关的资料库，帮你找回那些经历过、却已经忘掉的信息。

四、长期记录会带来多少数据

顺着这个方向想，背后的存储需求也很值得关注。

我们现在拍照录像，通常是主动选一个时刻。如果未来变成每天长时间记录，数据量就完全不同了。做个简单假设：视频平均码率为 5 Mbps，每天记录 8 小时，**一天大约就是 18 GB，一年约 6.6 TB。**这还只是一个人的一份视频，没有算备份。

这不是在预测未来每个人都会这样录，而是说，一旦长时间记录普及，个人存储需求确实有可能上一个台阶。再乘上大量用户，云端存储、数据上传，以及 AI 检索和处理的需求，都可能跟着增加。

当然，也不一定所有原始视频都往云端传。上传要电量和带宽，长期保存要花钱，用户也未必愿意把生活完整交出去。更现实的做法，可能是设备先筛选，保留重要片段，把普通内容整理成文字摘要，再由用户决定哪些上传、哪些删除。

这么看，未来值得竞争的能力还有：**怎样用更少的空间，留下真正有用的信息。**毕竟存了一年的录像，问一句却找不到答案，那也只是多了一堆文件。

这也让我想到另一件事：买眼镜可能只是第一笔费用。如果后面还有云空间、AI 服务和数据处理，用户每个月愿意花多少钱？厂商能不能靠这些收入覆盖成本？这些问题，可能会影响产品最终怎么设计。

五、隐私是绕不开的问题

但越往“随身记忆助手”发展，隐私问题就越突出。

手机举起来拍，别人通常看得出来。眼镜一直戴在脸上，即便有拍摄指示灯，对方也未必留意。如果连聊天内容、生活轨迹都长期保存，一旦泄露，影响也会更大。记录是否经过同意，拍摄状态是否明显，数据能否导出和彻底删除，都会影响人们愿不愿意接受它。

六、续航、重量和颜值都很重要

硬件也有实实在在的难题。芯片、电池、摄像头和光学模组要塞进小小的镜架，功能越多，重量、发热和续航就越难兼顾。能戴一天，不代表能连续录一天；拿在手里觉得不重，也不代表架在鼻梁上几个小时还舒服。

针对续航，已经有厂商采用可换电设计。例如，夸克 AI 眼镜 S1 使用可更换的双电池方案，用户可以通过更换电池延长使用时间。此外，部分产品配有充电盒，方便外出补电。

还有颜值，哈哈，这个真的不能忽略。我之前在线下体验过，有些款式对我来说确实有点影响颜值。眼镜每天都在脸上，功能再强，如果不好看、夹头、压鼻梁，最后可能还是放进抽屉里。

对本来就需要戴眼镜的人来说，它又有天然的吸引力。如果度数配得合适，外观和舒适度也过关，相当于把原来就要戴的东西升级了。但不同人的脸型、鼻梁和度数不同，厂商还得把配镜和售后这些事情做好。

七、它会取代手机吗

眼镜取代手机，会成为一个趋势，现在更可能先发生的，是一些简单、频繁的操作逐渐转移到眼镜上，手机继续承担大屏操作和其他任务。

眼镜最后能走多远，既要看 AI 有多聪明，硬件发展有多快，也要看它能不能让人舒服地戴着，持续解决问题，还负担得起长期使用的费用。

如果以后出门，一副眼镜就能帮我翻译、导航、记录重点，需要时还能找回忘记的事情，那我确实会很想买。再往后想，它带来的变化可能还会延伸到存储、计算、服务和我们管理个人数据的方式。

越研究，越觉得这件事有意思。但真正让我期待的，还是它什么时候能从“演示起来很酷”，变成我每天都愿意戴的东西。

参考资料与视频

注：存储容量为指定码率和记录时长下的简单测算；关于存储、云服务和商业模式的内容属于个人推演，并非确定的行业预测。

周末重拾 STM32，从点灯开始

Sat, 31 Oct 2026 00:00:00 +0800

背景介绍

毕业后很久没用过 STM32 了，今天刚好周末，看到家里还有一块 STM32F103C8T6 最小系统开发板，就拿出来玩一下。这次从点灯开始，回顾从 CubeMX 配置到 VS Code 编译、烧录并运行的流程，顺手记录下来，方便以后回顾。

这次使用 MacBook 开发，硬件是 STM32F103C8T6 最小系统开发板和 USB 转 TTL 模块，通过串口烧录。

软件用到以下四款工具：

STM32CubeMX：配置时钟、GPIO 等，生成工程。
STM32CubeIDE：提供当前工程使用的 ARM GCC 和 Make 编译工具。
STM32CubeProgrammer：负责烧录、校验，通过命令行工具发送启动命令。
VS Code：编辑代码，通过“项目助手”扩展调用上述编译、烧录工具，实现一键编译烧录并运行。

最终实现的效果是：日常修改和下载都在 VS Code 中完成，每次下载前手动按一下开发板 RESET，再点击“编译烧录并运行”即可。

下面按实际操作顺序，记录具体的配置和烧录流程。

一、CubeMX 配置工程

1. 配置外部时钟

在 System Core → RCC 中，将 HSE 设置为 Crystal/Ceramic Resonator，使用开发板上的外部晶振。

2. 配置时钟树

在 Clock Configuration 中，使用 8 MHz 外部晶振，经 PLL 倍频至 72 MHz，选择 PLLCLK 作为系统时钟；APB1 二分频至 36 MHz。

【BES】编译配置（03）：Make 变量怎样变成 C 宏

Fri, 23 Oct 2026 00:00:00 +0800

前一篇讨论了 Make 变量从哪里来、怎样覆盖。接下来还要弄清楚：配置文件中的开关，怎样影响 C 源码里的 #ifdef？

一、从变量到宏的传递过程

程序	主要读取什么	在构建中负责什么
Make	Makefile、`.mk` 文件	根据配置安排构建，并组织传给编译器的参数
C 编译器	`.c`、`.h` 等源码文件	根据宏和源码内容，生成目标文件

写在 .mk 文件中的变量，是给 Make 使用的。C 编译器不会自动读取这些变量。

先用一个简单的 MY_FEATURE 开关说明。

1.1 定义 Make 变量

假设 .mk 文件里写了：

MY_FEATURE = 1

MY_FEATURE 是 Make 变量，Make 用 $(MY_FEATURE) 取值。例如，判断这个开关是否等于 1：

ifeq ($(MY_FEATURE),1)
# 在这里安排开启功能时的构建操作
endif

1.2 `export`：传递给子 Make

如果顶层 Make 另外启动子 Make 来构建模块，后面的子 Make 也可能需要这个开关。这时可以前面加 export 将变量传过去：

export MY_FEATURE = 1

export 会把变量带给后续子进程，子 Make 因而也能读取 MY_FEATURE。

这里说的子 Make，是另外启动的 Make 进程。如果是同一个 Make，通过 include 读入多个配置文件时，变量可以在该进程内使用，无需为了 include 单独加 export。

【BES】编译配置（04）：源码怎样编译成固件

Fri, 23 Oct 2026 00:00:00 +0800

前一篇说明了配置怎样变成编译参数。除了参数，构建系统还需要知道哪些目录、哪些源文件参与构建。这里继续借助本地 BES SDK，从源码清单查到编译命令，再看目标文件怎样链接成固件。

一、源码选择与编译

1.1 `core-y`：选择顶层目录

要选择参与构建的源码，先要确定它们所在的目录。这份 SDK 在 target.mk 中通过 core-y 列出顶层构建目录：

图 1：target.mk 用 core-y 指定顶层构建目录

当前面没有指定 EXT_SRC_DIR 时，会把 apps/ 和 services/ 加入这部分构建列表。后续再进入这些目录，读取各自的 Makefile。

1.2 `obj-y`：列出子目录和目标文件

core-y 加入 services/ 后，构建系统会读取 services/Makefile。里面的 obj-y 再决定这个目录下哪些内容参与构建。

在这套构建系统里，obj-y 是当前目录的构建清单，里面既可以写子目录，也可以写目标文件。清单的名称和处理方式由 SDK 的构建脚本约定，Make 本身不会因为变量叫 obj-y 就自动编译它。

（1）子目录条目

在 services/Makefile 的 obj-y 列表中，可以找到：

图 2：services/Makefile 用 obj-y 列出子目录

audio_process/ 末尾带 /，表示还要进入这个子目录，继续读取 services/audio_process/Makefile。

（2）目标文件条目

进入 services/audio_process/ 后，里面有这些源文件：

audio_process.c
audio_process_vol.c
audio_spectrum.cpp

这些源码需要经过编译，生成对应的 .o 文件。例如，audio_process.c 编译后生成 audio_process.o。

【BES】外设适配（01）：触摸输入从采样到事件

Fri, 23 Oct 2026 00:00:00 +0800

一、TWS 按键交互背景

耳机可以通过电容触摸、压力感应、实体按键或敲击检测等方式接收用户操作。

我接触的这份 BES 项目使用 CAPSENSOR 电容感应方案。以“双击暂停音乐”为例，先要完成触摸检测，得到“某个事件”，应用才能继续执行对应功能。

二、触摸检测的基本流程

手指接近或接触感应区域，会引起电容变化。硬件按一定节奏测量，将结果转换成程序能读取的数值，这个过程叫作采样。软件再结合数据随时间的变化，识别单击、双击或长按。

采样数据是测量结果，触摸事件是识别结果。 在实际开发中，重点先确认检测能启动、事件能产生，再将事件接入业务。

三、开机后，从应用初始化到触摸初始化

先看开机时这条主线

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}, "themeCSS": ".nodeLabel { white-space: nowrap; } .nodeLabel p { margin: 0; }"}}%%
flowchart TB
    subgraph INIT["① 应用初始化"]
        direction LR
        A["应用入口<br/>app_init()"]
        B["初始化触摸模块<br/>app_mcu_core_capsensor_init()"]
        C["准备时钟和模拟电路<br/>capsensor_driver_init()"]
        D["创建检测线程<br/>cap_sensor_core_thread_init()"]
        A --> B --> C --> D
    end

    subgraph TASK["② 检测线程"]
        direction LR
        E["线程开始执行<br/>capsensor_thread()"]
        F["配置并启动采样<br/>capsensor_drv_start()"]
        G["设置采样中断<br/>cap_sensor_irqinit()"]
        E --> F --> G
    end

    INIT -..->|"创建线程后，由 RTOS 调度运行"| TASK

    classDef initPhase fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef taskPhase fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    class A,B,C,D initPhase;
    class E,F,G taskPhase;
    style INIT fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    style TASK fill:#f0f8f3,stroke:#b9d7c4,color:#24563a

3.1 从应用入口进入检测初始化

app_init() 在 CAPSENSOR_ENABLE 开启时，调用 app_mcu_core_capsensor_init()。图中前一个函数用于恢复佩戴检测的校准参数，这里继续沿第二个函数看触摸初始化。

【BES】外设适配（02）：触摸事件怎样交给应用

Fri, 23 Oct 2026 00:00:00 +0800

上一篇讲到检测线程得到单击、双击等事件。这篇接着看：事件怎样进入应用，最后找到对应业务。

本项目的 MCU 处理路径如下：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 检测线程：调用接收函数"]
        direction LR
        R0N0["得到检测事件<br/>status.event"]
        R0N1["转换为应用按键事件<br/>app_capsensor_click_event()"]
        R0N2["放入应用邮箱<br/>capsensor_key_event_process()"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 应用线程：取消息并分发"]
        direction LR
        R1N0["还原按键消息<br/>app_key_handle_process()"]
        R1N1["进入产品处理<br/>app_ibrt_user_key()"]
        R1N2["按产品状态、左右耳和事件类型<br/>分发到对应业务函数"]
        R1N0 --> R1N1 --> R1N2
    end
    class R1N0,R1N1,R1N2 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 -..->|"通过邮箱交给应用线程"| R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

一、初始化时，登记事件接收函数

app_mcu_core_capsensor_init() 中有一行：

【BES】编译配置（01）：编译命令与构建脚本

Thu, 22 Oct 2026 00:00:00 +0800

在《系统总览（01）：编译配置如何决定固件功能》中，用 ANC 介绍了配置对源码的影响。实际构建项目时，还要先弄清楚该执行什么命令、得到什么文件，以及是否需要后续处理。

这里通过我在实际项目开发中所使用的BES 2700这款芯片的SDK 所用的构建命令进行介绍。包含构建目标、输出路径和 CRC 处理方式。

一、执行编译命令

编译bes工程，可以在工程根目录打开终端，输入：

make T=best1306p -j

Make 会读取工程里的 Makefile，并按其中的规则完成构建。这条命令中，T=best1306p 是用于选择这份工程的构建配置，-j 用于并行构建。

平时修改的 .c、.cpp 源码。经过编译、链接，源码会变成芯片能够执行的程序，并与相关数据一起组成固件。本例生成的固件文件路径是 out/best1306p/best1306p.bin。

二、为固件补充校验信息

2.1 CRC 后处理

编译生成固件后，有些项目还需要为后续升级补充校验信息。例如，接收方要检查收到的数据是否与准备好的固件一致，就需要一个用于比较的校验值。这里以 CRC32 为例。

CRC 的中文名称是“循环冗余校验”。电脑先算好一个值，接收方拿到数据后，再按相同范围、相同算法算一次，与保存的值比较：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 电脑上准备固件时"]
        direction LR
        R0N0["生成固件"]
        R0N1["计算 CRC"]
        R0N2["将校验值填入固件"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 后续设备接收后"]
        direction LR
        R1N0["读取收到的固件数据"]
        R1N1["耳机重新计算 CRC"]
        R1N2["与固件中保存的 CRC 比较"]
        R1N0 --> R1N1 --> R1N2
    end
    class R1N0,R1N1,R1N2 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 -..->|"后续设备收到文件"| R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

对比结果不同，说明数据在传输中发生了变化；结果相同，表示通过校验，数据传输正常。

【BES】编译配置（02）：构建目标与配置覆盖

Thu, 22 Oct 2026 00:00:00 +0800

前一篇介绍了如何执行构建命令。这篇看配置怎样被选中和加载。

一、构建目标与配置加载

1.1 `T`：选择构建目标

要知道本次构建用了哪套配置，可以先查构建命令传入了哪些变量、Makefile 怎样使用它们。

这份 SDK 用 T 选择构建目标，顶层 Makefile 根据T的值，拼出配置文件路径。传入 T=best1306p，选中的就是 config/best1306p/target.mk：

图 1：顶层 Makefile 根据 T 拼出配置路径

默认的构建输出目录如下：

图 2：顶层 Makefile 中的输出目录设置与目标检查

Makefile 还会检查这个文件是否存在。不存在时，会报 Invalid target。

修改配置前先看构建命令里的 T，再去找对应目录，避免改了另一套配置。

1.2 `CHIP`：指定芯片平台

选出产品配置后，还需要指定它使用的芯片平台。

CHIP ?= best1306p

这里用的也是 best1306p 作为默认值。

两个变量的用途分别是：

T：选择哪套产品或构建配置。
CHIP：指定这套配置使用的芯片平台。

这次两者恰好都叫 best1306p。换成产品目标时，它们可能不同。

1.3 配置文件的加载顺序

配置拆在多个文件中时，Make 可以用 include 读入其他文件。因此，查配置除了找赋值，还要沿着 include 看它们的加载顺序。

这份工程的顶层 Makefile 先读入下面两个文件：

图 3：先读取目标配置，再读取公共配置

srctree 表示源码根目录。这里先读取 target.mk，再读取 common.mk。

target.mk 里面还有其他 include。Make 读到这里，会先处理被包含的文件，再回来接着读后面的配置。

【BES】系统总览（02）：开机初始化到应用模块

Wed, 21 Oct 2026 00:00:00 +0800

耳机开机后，应用层需要先准备好运行环境：读取配置数据、创建消息处理机制、初始化各业务模块，之后才能处理按键、连接、音乐播放等事件。

一、应用层从哪里开始

正常启动时，main() 完成平台侧准备，然后调用 app_init()：

app_init() 是应用层初始化的主要入口。看这个函数，可以了解 SDK 开机时启用了哪些模块，以及模块之间的初始化顺序和条件。

二、`app_init()` 初始化系统和模块

app_init() 下，关键的初始化函数有：

nv_record_init()：准备 NV 数据、工厂参数
app_os_init()：创建 app 邮箱和线程
app_battery_open()：检查电池、充电状态，确定启动分支
app_key_open()：按键检测及开机按键处理
bt_app_init()：蓝牙模块
app_audio_open()：音频模块

这里的初始化，是为了让模块具备处理业务的条件。例如，音频模块初始化完成，并不代表已经开始播放音乐，后面还需要播放事件触发。

三、建立应用线程和邮箱

在 app_init() 中，会调用 app_os_init()：

这个函数主要完成两件事：先创建 app 邮箱，再创建 app 线程。

邮箱用于保存待处理的应用消息，app_thread 负责取出消息，并根据模块编号交给对应的处理函数。所以，这里的消息链路大致为：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 消息投递"]
        direction LR
        R0N0["模块产生消息"]
        R0N1["放入 app 邮箱"]
        R0N0 --> R0N1
    end
    class R0N0,R0N1 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 应用线程处理"]
        direction LR
        R1N0["app_thread 取出消息"]
        R1N1["调用对应模块的处理函数"]
        R1N0 --> R1N1
    end
    class R1N0,R1N1 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 -..->|"通过邮箱交接"| R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

这是 app 线程的处理方式。蓝牙和音频等子系统也有各自的线程或回调，整个 SDK 由这些任务协作运行。

【BES】系统总览（03）：事件如何触发业务处理

Wed, 21 Oct 2026 00:00:00 +0800

【BES】系统总览（03）：事件如何触发业务处理

上一篇介绍了开机初始化：创建线程、邮箱，初始化按键、蓝牙、音频等模块。

初始化完成后，耳机就可以响应各种变化。例如，用户双击耳机、手机连接成功、App 切换降噪模式，都会触发相应的处理。

这一篇主要介绍：一个事件发生后，是怎样进入业务代码的。

一、事件与业务的区别

事件描述“发生了什么”，业务决定“接下来做什么”。

例如，用户双击左耳：

事件：左耳发生双击。
业务：根据当前状态，执行播放、暂停或者接听电话等操作。

同一个操作，在不同状态下可能执行不同功能。

整体流程可以这样理解：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 事件传递"]
        direction LR
        R0N0["检测到变化"]
        R0N1["传递事件"]
        R0N2["找到处理函数"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 业务处理"]
        direction LR
        R1N0["判断当前状态"]
        R1N1["执行具体操作"]
        R1N0 --> R1N1
    end
    class R1N0,R1N1 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 --> R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

下面结合 BES 的触摸链路来看。

【BES】系统总览（01）：编译配置如何决定固件功能

Tue, 20 Oct 2026 00:00:00 +0800

一、编译配置是什么

配置主要由 .mk 文件决定。看这些文件，可以了解当前选择了什么平台、加入了哪些模块，以及使用了哪些配置。

编译配置发生在电脑生成固件时。耳机上电后，运行的是已经编译好的固件。

整体流程如下：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 电脑上构建"]
        direction LR
        R0N0["读取配置"]
        R0N1["编译、链接"]
        R0N2["生成固件"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 耳机上运行"]
        direction LR
        R1N0["烧录固件"]
        R1N1["上电启动"]
        R1N2["运行固件中的代码"]
        R1N0 --> R1N1 --> R1N2
    end
    class R1N0,R1N1,R1N2 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 --> R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

二、ANC 配置如何影响源码

1. 判断是否加载 ANC 配置

下面是 target.mk 中的判断：

【中科蓝讯】耳机电量是怎样更新到手机的

Mon, 17 Aug 2026 15:18:41 +0800

从功能表面看，耳机电量更新并不复杂：ADC 采到电池电压，再查表换算成百分比，手机就能显示。

但在实际项目中，电量更新并不是采样后直接查表：采样值要先经过滤波，查表得到的也只是参考电量，手机最终显示的还要由软件继续维护。先把实际电压、参考电量和显示电量这三个值分清楚，整条链路就容易理解了。

先看完整链路：前 3 步把采样值处理成参考电量，后 3 步由软件维护显示值、完成双耳同步，最后上报手机。

电池电压是怎么采出来的？

顺着中科蓝讯 SDK 的调用关系看，系统会在 5ms 任务中检查 ADC 转换状态。转换完成后，读取电池通道和内部参考通道的 ADC 值。内部参考电压的已知值用于校准换算比例，再结合电池采样值和分压系数，得到实际电池电压。

为什么采到电压后还不能直接使用？

播放音乐或者蓝牙发射时，电池电压会短暂下降，负载变小后又会回升，所以一次采样不能直接拿来估算电量。

结合耳机电压变化缓慢、但采样又容易受负载影响的特点，我更推荐用递推平均的方式更新电压：每来一个新采样值，只让平均电压向它靠近一小步。平均电压变化达到条件后，才更新稳定电压。下降条件更容易触发，上升条件更严格，可以减少电压回弹的影响。

参考电量为什么不直接给手机？

稳定电压通过“电压—电量对照表”换算成参考电量。它只用来判断当前显示偏高还是偏低，不是手机最终看到的电量。

如果每次都用参考电量覆盖显示电量，负载变化仍然会造成百分比跳变。

显示电量是怎么变化的？

电量管理任务大约每 10 秒运行一次，并根据当前状态选择更新方式。

放电时，参考电量低于显示电量，软件就让显示电量逐级下降，不会一次跳到参考值；电压短暂回升时，也不会把电量加回来。

充电时，电压回升很快，不能直接用它增加百分比。软件根据充电电流和时间估算充入容量，再换算成显示电量；底层确认充满后，才显示 100%。

温度决定当前能不能充电、使用多大的充电电流。低电提醒主要看显示电量，低压关机最终看实际电压。

为什么内部电量和手机显示还可能不同？

显示电量发生变化后会被保存，耳机下次开机可以从上次的结果继续计算。耳机内部按 1% 维护电量，当前 App 路径按 5% 一档显示。

例如内部电量是 59%，手机仍然显示 60%；内部电量下降到 55% 后，手机才显示 55%。

左右耳电量最后由谁上报？

左右耳各自计算本耳电量，再通过 TWS 交换耳机和充电盒电量。主耳汇总左耳、右耳和充电盒数据后，统一上报给手机系统和配套 App。

现在再看这条链路，重点就是分清三份数据：实际电压反映电池状态，参考电量判断变化方向，显示电量负责最终呈现。

原文：CSDN · 【中科蓝讯】耳机电量是怎样更新到手机的？

【中科蓝讯】耳机电量与充电问题复盘

Mon, 17 Aug 2026 00:00:00 +0800

本文先整理电压采样的方案设计思路，再复盘下面五类电量与充电问题：

一、电压稳定方案的设计思路

电量计算不会直接使用一次 ADC 采样结果。播放音乐、蓝牙发射和负载切换都会造成短时波动，因此在进入电量估算前，需要先得到一份相对稳定的电压。

这里先分清三个值：

数据	含义
新采样电压	ADC 本次换算得到的电压，每次都可能变化
平均电压	经过滤波后缓慢上升或下降的中间值
稳定电压	达到更新条件后才改变，提供给后续电量算法使用

稳定电压不是手机显示的百分比，也不是永远固定不变。它只是在平均电压没有达到更新条件时保持原值。

方案一：去极值后取平均值

先连续采集一组电压，去掉其中几个最大值和最小值，再对剩余数据求平均。偶发的异常高值和异常低值不会直接影响结果，适合 ADC 容易出现尖峰干扰的场景。

这种方案的优点是抗单点异常能力强，思路也比较直观。缺点是需要保存一组采样数据，还要完成极值查找或排序，会占用更多内存和计算资源。采样窗口越长，结果越稳定，但输出延迟也越大，真实电压发生变化时不容易及时跟上。

方案二：递推平均加更新阈值

递推平均不需要保存整组数据。每得到一个有效采样值，就让原来的平均电压向新采样值移动一小步。新采样值低于旧平均值时向下移动，高于旧平均值时向上移动，每次移动的大小由两者差值和递推系数决定。

这种方案的优点是内存和计算开销小，适合持续采样，也可以通过调整递推系数改变响应速度。缺点是它不会自动剔除异常值，一个突发尖峰会影响后续一段时间；系数过小，电压变化跟得慢，系数过大，又容易把短时波动带进结果。

以递推系数 1/32 为例：

当前平均电压和稳定电压都是 4000mV。
本次新采样电压为 3800mV，与平均电压相差 200mV。
本次只向下移动差值的 1/32，也就是 6.25mV，新的平均电压约为 3993.75mV。
新的平均电压再与稳定电压比较。两者向下相差约 6.25mV，达到当前项目的下降更新条件，稳定电压才更新。

如果旧平均电压低于新采样电压，处理方向相反：旧平均电压加上两者差值的 1/32，得到新的平均电压。无论差值大小，每次采样都会参与递推；更新阈值只负责决定稳定电压是否改变。

当前项目在平均电压下降约 5mV 时允许更新稳定电压，向上则需要变化约 10mV。下降阈值更小，可以及时反映放电趋势；上升阈值更大，可以减少负载解除后电压回弹带来的影响。

对于 TWS 耳机这种电压变化缓慢、需要持续采样的设备，递推平均占用资源少，也方便调整响应速度，当前 SDK 采用的就是第二种方案。如果还会出现明显的异常采样，可以先剔除异常值，再进入递推平均。

二、电量曲线

问题现象

耳机从满电持续播放音乐时，有些 10% 很快掉完，有些区间长时间不变化；左右耳在同一电量区间的续航也可能相差较大。总续航接近要求，但百分比曲线不均匀。

问题原因

这次问题的直接原因是软件仍使用旧电池的电压—电量表，与当前电芯的充放电曲线不匹配，导致各百分比区间对应的实际续航不均匀。左右耳的主从角色还会带来功耗差异，因此双耳验证时也要把主从切换考虑进去。

处理结果

根据当前电芯的实测充放电数据更新电量表，同时调整电量相关的主从切换逻辑。修改后分别在 ANC 开启和关闭场景下完成整轮放电验证，各 10% 区间的续航恢复到要求范围内。

三、温度采样

问题现象

【中科蓝讯】机盒通信问题单复盘

Sun, 16 Aug 2026 00:00:00 +0800

本文围绕下面四类问题，整理对应的现象、问题原因和处理结果：

一、快速开关盖后异常断连

问题现象

快速开关盖时，耳机低概率断开。日志中没有完整的关盖命令，耳机却进入了充电状态。

问题原因

快速开关盖时，充电盒重新拉起供电。电平持续时间超过原来的防抖阈值，耳机提前判断为稳定入盒。状态切换由充电检测触发，不是串口丢包。

处理结果

将充电电平持续检测时间从约 600 ms 延长到 1 s，避免短暂电平触发充电模式。连续快速开关盖验证后，未再出现异常断连。

二、左右耳回复不一致，盒子灯效频闪

问题现象

耳机进入配对状态并放入盒内后，充电盒白灯闪烁不均匀，部分场景出现频闪或亮度异常。

问题原因

左右耳返回给充电盒的配对状态不一致。盒子先收到一只耳机的配对状态，又收到另一只耳机的非配对状态，灯效状态被反复切换。

左耳回复：配对中
右耳回复：非配对
        ↓
盒子灯效在两个状态之间反复切换

处理结果

由从耳同步主耳的配对状态，确保左右耳向充电盒返回一致的数据。双耳状态一致后，配对灯效恢复正常。

三、耳机进入配对，盒子却不显示配对灯效

问题现象

耳机已经连接一台手机，再进入配对模式并放入盒内。充电盒只显示耳机电量，没有显示配对灯效。

问题原因

耳机同时存在“已连接”和“可发现可连接”两个状态。原来的回复逻辑优先返回已连接状态，覆盖了正在配对的状态，盒子因此没有进入配对灯效。

/* 修改前 */
if (phone_connected()) {
    report_connected();
} else if (pairing()) {
    report_pairing();
}

/* 修改后 */
if (pairing()) {
    report_pairing();
} else if (phone_connected()) {
    report_connected();
}

处理结果

回复状态时优先判断配对状态，再判断手机连接状态。修改后，耳机在已连接状态下重新进入配对，盒子能够正常显示配对灯效。

四、配对超时后，盒子显示了错误灯效

问题现象

耳机在配对状态下入盒，配对超时后，充电盒显示了配对成功灯效，而不是结束灯效。

问题原因

耳机在配对超时后返回无效状态，充电盒却把这个状态按配对成功处理。数据传输正常，但两端对同一状态的含义没有统一。

处理结果

统一耳机与充电盒对回复状态的定义。收到无效状态时直接结束灯效，不再进入配对成功灯效。

这四类问题对应的检查入口是：充电电平、左右耳回复是否一致、状态判断优先级、两端状态定义。

【中科蓝讯】TWS 耳机机盒通信链路

Sat, 15 Aug 2026 00:00:00 +0800

机盒通信的主链路是：UART 收包、协议解析、校验与寻址、命令分发、业务执行、应答返回。这篇记录我负责该模块时使用的应用层调用链。

一、UART 收包与协议解析

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart LR
    N0["充电盒发送数据"]
    N1["UART 中断接收字节<br/>并写入环形缓冲区"]
    N2["协议状态机<br/>拼接完整数据包"]
    N3["应用任务<br/>从缓冲区取包并校验"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    class N0,N1,N2,N3 blue;
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

UART 中断侧负责收字节和快速识别数据包：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 中断与接收回调"]
        direction LR
        R0N0["uart1_isr()"]
        R0N1["uart1_rx_done_cb()"]
        R0N0 --> R0N1
    end
    class R0N0,R0N1 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 解析与接收处理"]
        direction LR
        R1N0["bsp_uart_packet_parse()"]
        R1N1["charge_box_packet_recv()"]
        R1N0 --> R1N1
    end
    class R1N0,R1N1 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 --> R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

中断将字节写入环形缓冲区，快速解析一次以记录收包时间及开盖、心跳等标志。charge_box_ssw_process(charge_sta) 再从缓冲区取出字节，重新组包、校验并处理命令。

【中科蓝讯】TWS音量是怎样同步的

Fri, 14 Aug 2026 10:38:44 +0800

这篇梳理音乐音量在应用层的处理：手机下发的音量怎样换算为本地等级，左右耳怎样同时生效，以及耳机按键调节后怎样同步手机音量条。通话音量只作区分，不展开 HFP 细节。

一、手机调节音量后的主流程

一次音量调节要对应下面四处状态：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart LR
    N0["手机音量条"]
    N1["耳机内部音量级"]
    N2["左右耳同步状态"]
    N3["DAC 实际输出音量"]
    N0 --> N1
    N1 --> N2
    N2 --> N3
    class N0,N1,N2,N3 blue;
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

手机和耳机的音量范围并不相同。AVRCP 绝对音量是 0～127，SDK 内部可配置为 16 级或 32 级，最后还要通过音量表转换为 DAC 使用的数字音量。

因此，手机显示 50% 不等于把数值 50 直接写入 DAC，而是先换算、再查表。

这里的“绝对音量”指手机音量条和耳机媒体音量相互对应：任一侧调节，另一侧都要更新。

手机调节音乐音量后，协议栈将新的媒体音量交给应用层，主线如下：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 接收与换算"]
        direction LR
        R0N0["收到手机设置的媒体音量"]
        R0N1["把 0～127<br/>换算为本地音量级"]
        R0N2["发起 TWS 定时音量请求"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 定时执行与保存"]
        direction LR
        R1N0["左右耳在约定时间设置 DAC"]
        R1N1["更新当前音量<br/>后续再延时保存"]
        R1N0 --> R1N1
    end
    class R1N0,R1N1 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 --> R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

TWS 路径不会在当前回调里直接设置 DAC，而是先发起定时请求；到达定时点后，左右耳再一起设置实际音量。

【中科蓝讯】TWS 耳机音量问题单复盘

Fri, 14 Aug 2026 00:00:00 +0800

写在开始

这篇文章整理项目中比较有代表性的音量问题单。只保留已经写明原因和处理方向的内容，并按音量控制链路归为三类。

排查音量问题时，可以先确认四个结果：

1. 收到的目标音量是否正确
       ↓
2. 左右耳保存的音量是否一致
       ↓
3. 两耳应用音量的时间是否一致
       ↓
4. 实际写入硬件的音量是否正确

本文围绕下面三类问题，整理对应的现象和排查思路：

一、回连后的初始音量不对

问题现象 1

耳机重新组队并连接手机后，预期使用耳机的默认音量，实际却变成手机之前保存的最大音量。

排查思路 1

按时间确认三个值：重新组队后恢复的默认音量、手机首次下发的历史音量，以及最终实际生效的音量。若默认值恢复正确，但最终值变成手机历史值，说明问题出在手机下发后的覆盖。

耳机重新组队后已恢复到默认音量，但手机连接时下发的历史音量又覆盖了本地值。如果要求重新组队后采用耳机默认音量，可以在首次连接的短暂保护窗口内忽略手机下发的音量，使用耳机的默认音量，同时将默认音量写回给 App。

问题现象 2

一拖二场景下，设备 A 已连接耳机且音量调到最大；设备 B 的音量较小，在播放音乐时抢连耳机。抢连成功后，音乐开始时仍按设备 A 的最大音量播放，随后才突然降到设备 B 的低音量。

排查思路 2

检查抢连后耳机采用的是哪台设备的音量，以及 A2DP 开始播放前硬件音量是否已经更新。

已有问题中，设备 B 抢连成功后，硬件音量设置晚于音乐开始，导致开始播放时仍保留设备 A 的最大音量。处理时要在 A2DP 出声前，按设备 B 的音量设置好硬件音量。

二、快速调节时双耳音量不同步

问题现象 1

长按手机音量键或快速滑动音量条时，声音会短暂偏向一边；从最大音量降到静音时，一只耳机比另一只更晚无声。反复在最大和最小音量之间切换时，还可能出现音量跳变。

排查思路 1

先看手机下发音量后，主从耳是不是在 alarm 到点前就各自更新了本地媒体音量；再对比 alarm 回调里两边实际采用的目标值。

已有问题中，主从耳在 alarm 到点前更新本地媒体音量的路径不同。快速滑动时，虽然两边在同一时刻进入 alarm 回调，但取到的音量基准已经不一致，所以会出现一边先变大、先变小或更晚静音。

【中科蓝讯】ANC 模式是怎样切换的

Wed, 12 Aug 2026 10:34:45 +0800

最开始看原厂 SDK 时，我觉得它的切换很简单：确定关闭、降噪或通透，再调用模式接口即可。

随着 App 控制、按键配置、单双耳记忆和出入盒切换逐渐加进来，我才发现应用层维护的并不只是一个 ANC 模式。提示音何时播放、左右耳怎样同步、状态什么时候保存和上报，也都在这条链路里。

一、先把 ANC 的几条链路放在一起

ANC 模式可能因为三类事件发生变化：

App 下发一个明确的目标模式；
用户通过耳机按键切换模式；
耳机出入盒或 TWS 连接状态变化，需要重新选择单双耳记忆。

把三个入口放在一起，我目前是这样理解的：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 确定目标模式"]
        direction LR
        R0N0["收到 ANC 相关事件<br/>App 指令、按键事件<br/>出入盒或 TWS 状态变化"]
        R0N1["确定当前使用场景<br/>单耳、双耳<br/>或者双耳都在盒内"]
        R0N2["得到本次目标模式<br/>关闭、通透、不同等级的降噪<br/>或自适应降噪"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 同步并应用"]
        direction LR
        R1N0["更新并同步状态<br/>选择或更新单耳、双耳记忆<br/>必要时通知对耳"]
        R1N1["处理提示音并应用模式<br/>按触发来源处理提示音<br/>再转换成 SDK 模式"]
        R1N2["保存并更新 App<br/>写入记忆；按键或状态变化时<br/>更新 App 显示"]
        R1N0 --> R1N1 --> R1N2
    end
    class R1N0,R1N1,R1N2 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 --> R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

这是一条方便理解的主线。实际代码里，App、按键和状态变化的处理顺序并不完全相同，后面再分别展开。

【中科蓝讯】TWS 耳机 ANC 问题单复盘

Wed, 12 Aug 2026 00:00:00 +0800

写在开始

这篇文章整理项目中比较有代表性的 ANC 问题单，并按问题现象归为五类。

有些问题标题虽然带有 ANC，但最后确认是电量、功耗或连接问题，这里不展开。本文只保留能够放回 ANC 控制链路解释的问题，没有明确结论的地方也不补充猜测。

先把 ANC 控制流程简化成四步：

1. 收到切换请求
       ↓
2. 确定并同步目标模式
       ↓
3. 加载参数，更新实际效果
       ↓
4. 保存状态并上报 App

本文围绕下面五类问题，整理对应的问题现象和排查思路：

一、实际模式正常，App 显示却不对

问题现象 1

从耳长按切换 ANC 后，耳机实际已经切换，App 仍显示原来的模式；

排查思路 1

先确认三个结果：从耳是否识别到长按、左右耳实际模式是否变化、主耳是否向 App 上报了新状态。

如果从耳和两耳实际模式都正常，重点查主耳是否收到新的目标模式、更新本地状态并上报 App。问题单中，从耳已经完成 ANC 切换，但主耳没有更新状态并发送新模式，因此问题出在主耳的状态同步和上报链路。

问题现象 2

耳机实际是高降噪，App 却显示低降噪；重新进入 App 后，等级还会发生跳变。

排查思路 2

对照耳机内部等级、协议值和 App 显示值是否一致。问题单中，耳机使用 1 表示低降噪、3 表示高降噪，App 却映射成1是高降噪，3是低降噪，导致高低等级颠倒。这是状态映射错误，不是 ANC 参数没有生效。

【中科蓝讯】TWS 耳机提示音问题单复盘

Tue, 11 Aug 2026 00:00:00 +0800

一、本文要解决哪些提示音问题

这篇文章记录的是我对 TWS 耳机提示音问题的整理和理解。我结合问题单、原厂 SDK 以及实际修改点，把零散的问题按现象和根因重新归类，并从业务请求、队列、播放到状态恢复，整理出一套排查思路。

具体问题的修改结论，以问题单和现有代码记录为准；没有明确依据的地方，我不额外延伸。理解提示音问题，可以先把流程分成四步：

1. 业务事件发生
       ↓
2. 提示音请求进入队列
       ↓
3. 提示音开始播放
       ↓
4. 播放结束，恢复音频状态

有些提示音只是给用户提供声音反馈，有些提示音还和业务回调绑定在一起。原厂 SDK 中，ANC 和音乐/游戏模式会在提示音播放完成后更新；接听、拒接和回拨也会在提示音相关回调中触发。

所以排查时不能只看“有没有声音”，还要看对应的业务回调是否按预期执行。遇到问题时，先分清是“声音没有正常播放”，还是“提示音对应的业务动作没有执行”：前者检查资源、音量和播放链路，后者检查业务请求和回调。

本文主要围绕以下 7 类问题展开，后文会分别说明问题现象、原因和排查思路：

二、业务已经发生，提示音却没响或播错

问题现象 1

电量已经低于 10%，却没有低电提示音。

排查思路 1

先确认低电条件是否真的触发。比如电量从 11% 直接变成 9% 时，可能跳过“等于 10%”的判断，后面就不会提交低电提示音。确认条件后，再检查代码是否走到提示音调用位置。

问题现象 2

来电双击已经接听，却播放成三击提示音。

排查思路 2

这个问题说明提示音请求已经提交，但事件和提示音没有正确对应。重点检查双击事件最终传入的提示音资源编号，确认是否误用了三击提示音。

这类问题可以按“业务条件、提示音调用、资源编号”的顺序检查。前三步没有问题后，再进入队列和播放流程。

三、提示音太大、太小，或换资源后异常

问题现象 1

通过 App 的“查找耳机”功能播放正常，但在手机设置中的 Google“查找设备”页面，点击“让耳机响铃”时声音偏小。

【中科蓝讯】TWS 耳机提示音是怎样播放出来的

Mon, 10 Aug 2026 15:06:42 +0800

在 TWS 耳机里，开机、蓝牙连接、低电量和降噪模式切换，通常都会伴随一段提示音。

从表面看，提示音像是准备一个音频文件，需要时调用播放函数即可。实际上，一段提示音从代码触发到左右耳真正出声，中间还要经过资源查找、播放排队、双耳同步和音频恢复。

本文以中科蓝讯 BT891x 原厂 SDK 的实现为例，重点分析提示音播放的核心流程。不同 SDK 的接口名称可能不一样，但整体思路通常可以互相参考。

一、提示音播放的完整链路

一段提示音的完整流程，可以先简化成下面五步：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 准备播放请求"]
        direction LR
        R0N0["业务触发"]
        R0N1["找到对应的提示音资源"]
        R0N2["把播放请求加入队列"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 同步与播放"]
        direction LR
        R1N0["确定哪只耳机播放<br/>并完成双耳同步"]
        R1N1["解码播放<br/>结束后恢复原来的音频状态"]
        R1N0 --> R1N1
    end
    class R1N0,R1N1 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 --> R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

比如手机连接耳机成功以后，蓝牙业务只需要提出“播放连接成功提示音”这个请求。至于提示音文件放在哪里、左右耳什么时候开始播放、当前音乐要不要降低音量，都会继续交给提示音模块处理。

【中科蓝讯】TWS 按键问题单复盘

Fri, 07 Aug 2026 20:17:54 +0800

一、写在开始

我参与的是一款基于中科蓝讯 BT8910 的 TWS 耳机品牌项目，目前这个项目已经完成。

项目结束后，我想把开发过程中接触到的 Jira 问题单重新梳理一遍。其中既有我参与处理的内容，也有同事负责的模块。

现在查一个函数、一个配置项并不难，真正值得记录的是：面对一个问题现象时，应该先判断哪一层，为什么往这个方向查，以及怎么通过日志一步步缩小范围。

所以这次复盘不是给出一套标准答案，而是站在我目前对应用层的理解上，把问题现象、判断过程和排查思路整理下来，供遇到类似问题的同学参考。

整理过程中我还发现，很多反馈看起来不一样，根因却有重复。按根因归类后，下次遇到类似现象时，就可以先判断问题属于哪个环节，再沿对应链路往下查。

后续我会继续按模块整理项目中的问题单，包括按键、提示音、机盒通信、ANC、音量控制、功耗管理、出入盒、双耳同步、蓝牙问题和连接问题等内容。这一篇先从按键开始，归纳其中比较常见的 4 类问题。

阅读提示

全文约 2 300 字，预计 10 分钟读完。

本文包含 4 类按键问题：完全无响应、场景功能错误、误触，以及复杂手势互相干扰。重点不是讲基础原理，而是遇到类似反馈时，应该先查哪里、再往哪里查。

本文只讨论按键链路本身。如果按键已经触发正确功能，只是提示音没有播放或播放不对，就归到后续的提示音问题中。

二、所有手势都没有反应

客户反馈

其中一只耳机的触控按键完全无效，双击、三击、长按都没有反应。

排查思路

第一步：确认触控输入

先看这只耳机的触控按键是否有按下、松开的日志。

没有日志：先查这个触控按键的输入本身，例如触控是否启用、耳机是否在盒内、是否正处于禁键时间、触控阈值或通道是否正常。

有日志：说明这个触控按键已经有输入，继续往下查。

第二步：确认手势识别

再看目标手势有没有识别出来。

没有识别出来：重点查双击间隔、长按时间、松手后状态是否复位，以及组合手势是否把普通手势挡住了。

识别出来：说明手势已经产生，继续看功能。

第三步：确认功能消息

最后看手势有没有转换成正确的功能消息。

没有、为空或错误：查按键定义、场景切换和配置更新。

有正确消息：再确认功能处理是否执行；如果功能已经执行，后面只是没有提示音，就属于提示音问题，不再按按键问题处理。

判断与处理

“完全无效”不一定是触控硬件问题，也可能是手势已经产生、但后面没有正确链接到功能。处理时不要一开始就调灵敏度或改功能定义，先通过日志确认问题停在哪一层。

三、同一手势，功能却错了

客户反馈

听歌时双击正常，来电时双击却不能接听或挂断。
长按在听歌时能切换功能，到响铃或通话时却失效。
App 改完触控后，耳机执行的功能不对。

排查思路

第一步：固定一个场景复现

只测听歌、只测来电响铃，或只测通话，避免混在一起判断。

第二步：确认手势已经识别

如果手势都没出来，回到第一类问题排查。

第三步：核对当前场景的功能

手势正常后，直接看耳机最后想执行的是什么功能。

同样是“双击”：听歌时可能是切歌，来电时应该是接听或拒接，通话中又可能是其他操作。
来电时双击却去切歌：说明双击识别没有问题，只是耳机还在按“听歌时的规则”处理。
只有通话异常：重点检查进入通话后，双击和长按是否已经改成通话时该做的功能。
App 改完才异常：重点检查新设置是否把听歌、来电或通话时的功能改错了。

判断与处理

听歌、来电响铃、通话时都可以识别同一个“双击”或“长按”，但后续要执行的功能并不相同。

这类问题通常是耳机没有按当前使用状态执行对应功能。处理重点是把每种状态下的功能对应关系确认清楚。

四、不该响应时仍然响应

客户反馈

耳机放在盒内还能切歌；刚出盒或拿取耳机时，容易误触切换功能。

排查思路

第一步：确认误触发生的时机

【中科蓝讯】TWS 耳机按键处理流程

Fri, 07 Aug 2026 18:39:14 +0800

上一篇已经把 SDK 的几个核心概念过了一遍，包括模式状态机、process/message/display 和消息分层。

这一篇就拿按键功能做一次具体分析，从一个按键事件出发，一直追到最终执行的位置。

以我接触到的 TWS 项目来看，按键是应用层里相对好理解、也比较容易上手的一部分：改单击功能、加长按、加多击，或者调整不同模式下的按键行为。这些需求在 SDK 里都对应到同一套机制，弄懂之后，定位修改位置会更快。

一、先跑一遍完整链路

一个按键从手指按下到功能执行，在 SDK 里走了这几步：

%%{init: {"flowchart": {"htmlLabels": true, "wrappingWidth": 1000, "rankSpacing": 30}, "themeVariables": {"lineColor": "#71829a"}}}%%
flowchart TB
    subgraph R0["① 输入与识别"]
        direction LR
        R0N0["手指按下<br/>用户触发按键"]
        R0N1["硬件扫描<br/>读取按键编号"]
        R0N2["消抖 / 识别<br/>判断短按、长按、多击"]
        R0N0 --> R0N1 --> R0N2
    end
    class R0N0,R0N1,R0N2 blue;
    style R0 fill:#f1f6fd,stroke:#b8cfe8,color:#23456b
    subgraph R1["② 消息与业务"]
        direction LR
        R1N0["查按键表<br/>找到对应消息"]
        R1N1["消息入队<br/>放入消息队列"]
        R1N2["模式分发<br/>按当前模式处理"]
        R1N3["功能执行<br/>播放、切歌、接听等"]
        R1N0 --> R1N1 --> R1N2 --> R1N3
    end
    class R1N0,R1N1,R1N2,R1N3 green;
    style R1 fill:#f0f8f3,stroke:#b9d7c4,color:#24563a
    R0 --> R1
    classDef blue fill:#e8f2ff,stroke:#7ba4d8,color:#23456b,stroke-width:1.5px;
    classDef green fill:#e7f4ec,stroke:#78aa8b,color:#24563a,stroke-width:1.5px;
    classDef amber fill:#fff3df,stroke:#d5a25b,color:#72501e,stroke-width:1.5px;

前两步主要回答“这个按键物理上发生了什么”。从第 3 步开始，软件才把按键行为转换成功能。

【中科蓝讯】聊聊我对这套SDK的理解

Thu, 06 Aug 2026 19:59:39 +0800

前两篇记录了环境搭建和 com/bank 内存的事。这篇主要想讲一下中科蓝汛的 SDK——不讲具体细节，也不列目录结构，每个项目的目录可能都不太一样，列了也没太大意义。主要是聊一下我对这套 SDK 几个核心概念的理解。以后不管拿到哪个版本、做什么功能，这几个概念应该都不会变。

一、SDK 就是一个"模式状态机"

这是做完项目之后最大的感受。一颗 TWS 耳机芯片，任何时候只处于一个"模式"——蓝牙模式、充电模式、IDLE 待机、关机。切模式就是改一个变量 func_cb.sta。

// func_run() —— 整个 SDK 的主循环就长这样
while (1) {
    func_enter();
    switch (func_cb.sta) {
    case FUNC_BT:      func_bt();      break;  // 蓝牙
    case FUNC_CHARGE:  func_charge();  break;  // 充电
    case FUNC_IDLE:    func_idle();    break;  // 待机
    case FUNC_PWROFF:  func_pwroff();  break;  // 关机
    default:           func_exit();    break;  // 退出，切下一个
    }
}

虽然每个模式做的事情不一样，但内部结构都有共同点。拿蓝牙模式看：

void func_bt(void)
{
    func_bt_enter();                    // 进来先初始化
    while (func_cb.sta == FUNC_BT) {    // 没切模式就一直在这转
        func_bt_process();              // 轮询事件
        func_bt_message(msg_dequeue()); // 处理消息
        func_bt_display();              // 刷新显示
    }
    func_bt_exit();                     // 走之前收尾
}

就是 enter → while → process/message/display → exit。再看 idle 模式，几乎一模一样——func_idle_enter() → while(func_cb.sta == FUNC_IDLE) → process/message/display → 退出。充电和关机模式虽然内部细节不同，但也是 enter → 做事 → exit 这个三段式。

【中科蓝讯】从两次偶发死机，理解 com 区和 bank 区

Thu, 06 Aug 2026 08:00:00 +0800

刚接触中科蓝讯 SDK 时，我经常看到函数前面有 AT(.com_text.xxx)。一开始我只知道照着原有代码写，却不明白它为什么在这里。后来看了资料和工程里的写法，我才认识到：SDK 把代码分区域存放，不同区域的运行方式不一样。

这篇只是我目前从应用侧整理的一点理解，重点放在看到 AT(...) 时怎么读。

一、com 区和 bank 区有什么区别

按照官方资料的说明，芯片上电后，一部分代码会从 Flash 搬到 RAM 里常驻下来，这部分就是 com 区；剩下的代码继续待在 Flash，用到时才被加载到 bank 运行区。

区域	简单理解	适合放什么
`com` 区	上电后会加载到 RAM，并在运行期间常驻	中断函数、实时性要求高的
`bank` 区	代码存在 Flash，运行时按需加载到 bank 运行区	大多数普通应用逻辑

com 区的空间有限，所以不要因为更快，就把普通功能都放进去。

二、真正要注意的是中断和它调用的函数

中断函数和它调到的关键函数，通常需要放在 com 区。因为中断来了要马上处理，不能等到需要时再去加载代码。

在工程里看定时和一些中断相关代码时，我能看到类似下面的写法：

AT(.com_text.user)
void user_timer_isr(void)
{
    // 中断中的处理
}

实际用的时候，我是先看同模块已有代码的写法，不凭空猜。但照抄还不够——踩过两次坑才知道，光盯着函数本身的 AT，容易漏掉更深层的依赖。

第一次是在中断里调了一个普通函数，我给那个函数加了 AT(.com_text.xxx)，以为这就完事了。结果还是偶发异常。排查后发现，这个函数内部又调了另一个普通函数，那个子函数没加 AT。中断触发时 CPU 跳到 com 区，执行到嵌套的子函数时，它的代码还在 bank 区没加载进来，一样挂。这件事的风险在于，被调函数可能还调了其他函数，嵌套几层之后很容易漏掉。所以给函数加 AT 时，得顺着调用链往下检查，确保整条执行路径上的函数都在 com 区。如果调用深度比较大，更稳妥的做法是通过消息转发把逻辑放到其他线程执行，避免在 com 区里越套越深。

【中科蓝讯】SDK 环境搭建与烧录

Wed, 05 Aug 2026 14:16:23 +0800

以我最近实际接触的中科蓝讯 BT891x 项目为例，刚开始最先要做的就是把开发环境搭起来：准备资料和工具、打开工程、编译生成 app.dcf，再用 Downloader 完成后续烧录。

不同 SDK 版本和开发板的目录、工具版本可能不一样，最终以当前资料包和工程说明为准。

一、准备资料和工具

如果手上的 SDK 对应特定的 TWS 开发板，原理图和相关硬件资料也要一并保存好，后面核对硬件配置、下载和外设问题时都会用到。

刚开始做 BT891x 时，主要先准备下面四项资料和工具：

内容	先拿它做什么
BT891x 固件 SDK	后续的功能开发主要就在这里进行
CodeBlocks 开发环境	打开 `.cbp` 工程并发起编译
RV32 Toolchain	供 CodeBlocks 调用的 RISC-V 编译工具链
Downloader	读取 `app.dcf`，进行配置和烧录处理

如果当前使用的是串口下载方式，还要保留蓝讯提供的串口驱动。资料包里的驱动通常以 CP210x 驱动包的形式提供，用于让电脑识别 CP2102 或 XLink 模块对应的 COM 口。

CodeBlocks 和 RV32 Toolchain 都是双击安装程序后，按提示一路选择 Next、默认路径安装即可。CodeBlocks 用来打开 .cbp 工程并编译，RV32 Toolchain 是真正执行编译的工具。

如果使用串口下载，按当前下载器对应的驱动安装即可。下载器和设备接入电脑后，系统能够识别出 COM 口，Downloader 才能继续扫描设备。

Downloader 不需要安装，解压后直接运行 Downloader.exe 即可。

二、编译与烧录

环境装完后，我不会马上改功能，而是先在 CodeBlocks 中打开 SDK 里的 .cbp 工程并编译一次。

一副 TWS 耳机，为什么既要用经典蓝牙，又要用 BLE

Tue, 04 Aug 2026 17:48:36 +0800

做 TWS 耳机时，经常会同时看到经典蓝牙和 BLE。

手机已经通过蓝牙连接耳机，可以播放音乐、接打电话，为什么配套 App 还要再连接一次 BLE？我刚开始接触时，也没有认真区分这两部分，只知道它们都叫蓝牙。

后来做 App 交互功能多了，我才慢慢理解：在目前常见的 TWS 产品里，它们处理的事情并不一样。经典蓝牙主要负责音乐、通话和媒体控制，BLE 更像一条给 App 使用的数据通道。

一、经典蓝牙主要负责耳机的基本功能

平时用耳机听歌、调节音量和接打电话，主要涉及经典蓝牙中的几个 Profile：

Profile	在耳机中的主要作用
A2DP	传输音乐音频
AVRCP	播放、暂停、切歌和音量控制
HFP	来电、接听、挂断等通话控制

通话时的语音通常还会通过 SCO/eSCO 链路传输。

这些功能决定了一副耳机能不能正常听歌和通话。以我目前接触到的应用开发来说，平时主要处理 SDK 上报的 A2DP、AVRCP 和 HFP 事件，再根据当前状态执行对应的产品逻辑。

二、BLE 主要负责耳机与 App 交互

配套 App 需要做的事情和播放音乐不太一样。它传输的通常不是连续音频，而是一些控制命令和状态数据。

我做过的项目里，BLE 主要用于这些功能：

修改 EQ；
切换 ANC 模式；
读取耳机电量；
OTA 升级；
查找耳机。

例如用户在 App 上切换 ANC，App 会通过 BLE 把命令发给耳机；耳机执行以后，还可能需要把最新状态返回给 App。读取电量也是类似的过程，只是数据方向和触发时机可能不同。

我接触过 GATT 的 Service、Characteristic、读写和通知，不过实际开发时，大部分数据收发还是通过 SDK 封装好的接口完成。刚开始看这些名词时，我觉得它们比较抽象。结合 TWS 耳机的功能，可以先这样理解：

做耳机开发，需要掌握哪些 C 语言知识

Mon, 03 Aug 2026 16:29:04 +0800

TWS 应用层的大部分工作，最后还是要落到 C 代码上。这篇整理开发中经常用到、也容易混淆的内容，方便需要时快速回顾。

一、数据类型与类型转换

嵌入式代码经常使用 uint8_t、uint16_t 和 uint32_t，因为它们的位宽是明确的。

int 占多少字节，由芯片架构和编译器决定。在常见的 32 位平台上，int 通常占 4 字节；在部分嵌入式平台上，也可能只占 2 字节。可以使用 sizeof 查看当前平台上的实际大小：

printf("int size: %u\n", (unsigned int)sizeof(int));

sizeof 返回的是 size_t 类型。这里先把结果转换成 unsigned int，再使用 %u 输出，适合常见的嵌入式 printf。

普通计算和循环计数可以使用 int。通信协议、Flash 数据、文件格式和寄存器字段需要明确长度时，优先使用固定位宽类型。

类型转换主要注意下面几种情况：

情况	需要注意什么
大类型转小类型	高位可能被截断
有符号转无符号	负数会变成很大的正数
无符号与有符号比较	有符号数可能先被转成无符号数
指针类型转换	只改变读取内存的方式，不会改变原来的数据

注意：有符号数和无符号数比较前，尽量把两边统一成合适的类型。进行指针类型转换时，要确认原内存长度不小于目标类型的大小。例如原数据只有 1 字节，转换成 uint32_t * 后却按照 4 字节读取，就会读到不属于它的内存。

二、指针、数组与生命周期

指针保存的是地址。使用前主要检查四件事：

指针是否为空。
指向的内存是否仍然有效。
访问长度是否越界。
指针指向的数据类型是否正确。

void update_state(uint8_t *state)
{
    if (state == NULL) {
        return;
    }

    *state = 1;
}

数组传入函数后通常会退化成指针，函数内部无法再通过 sizeof 得到原数组长度。因此传递缓冲区时，最好同时传入长度。

做 TWS 应用开发，到底需不需要懂协议栈

Mon, 03 Aug 2026 11:26:31 +0800

刚接触 TWS 应用开发时，我一直有一个疑问：蓝牙协议栈大部分已经由芯片原厂封装好了，平时做功能主要是调用 SDK 接口、处理事件和编写产品逻辑，还有没有必要专门学习协议栈？

刚入行的时候，我也尝试过从头学习蓝牙协议。当时下载了一份 Bluetooth Core Specification 6.0，打开后看到整整 3815 页，心里压力一下就上来了。里面有大量英文术语、状态、命令和数据包格式，我硬着头皮看了几天，还是很难把规范里的内容和手上的代码对应起来，最后没有坚持下去。

工作两年左右，我对协议栈内部仍然谈不上有多深入的理解，平时接触最多的还是应用层代码。所以我现在的看法是：**需要了解一些，但没必要一开始钻得特别深。**这篇文章只是记录我目前在项目中用到的一些认识。

一、我目前主要关注什么

以我目前的工作内容来说，HCI、L2CAP 以及各个 Profile 的内部状态机，我其实没有深入研究。日常开发更常见的是调用 SDK 接口、接收事件，再根据产品状态处理业务。

为了不把不同问题混在一起，我会先记住几个和工作直接相关的区别：

ACL 连接和 Profile 连接不是一回事。
A2DP 负责音乐，AVRCP 负责播放控制和音量同步。
HFP 负责通话控制，SCO/eSCO 承载通话语音。
SPP 和 BLE GATT 常用于 App 数据通信。
接口调用成功，不一定代表异步操作已经完成，还要等待后续事件。

为了更直观地区分这些连接和业务，可参考蓝牙连接关系简化图：

图中把 GATT 单独放在 BLE 连接下。严格来说，协议内部的承载关系还要更细，这里只保留我在应用开发中经常接触到的部分。

我目前也就是先把这些常见概念分清。这样遇到异常时，至少知道先看哪一类状态，不至于一上来就把所有现象都归结成“蓝牙有问题”。

二、实际项目里，我能接触到什么

以我使用的中科蓝讯 bt8910 SDK 为例，工程里可以看到 A2DP、HFP、SPP 和 TWS 相关的配置及适配代码，但真正的核心实现主要由预编译的 libbtstack.a 提供。

应用层这边，A2DP 和 HFP 主要是调整部分参数、接收事件和处理业务回调；SPP 的 SDP Record 和数据收发回调可以看到并修改；GATT 可以添加 Service、Characteristic 和读写回调；TWS 这边则能做一些业务状态同步和主从切换处理。

一副 TWS 耳机里，有哪些软件模块

Fri, 31 Jul 2026 18:32:50 +0800

一、先看整体

如果暂时不考虑具体芯片平台，TWS 耳机的软件大致可以分成下面几个部分：

这不是严格的分层架构。实际 SDK 中，各部分往往会互相调用，甚至放在同一个模块里。这样划分主要是为了看清楚：一个耳机功能背后，通常有哪些软件在配合。

软件模块	主要负责什么	常见内容
系统与 RTOS	让程序和多个任务运行起来	任务、消息、定时器、内存、看门狗
驱动与电源	与耳机硬件交互	GPIO、ADC、I2C、I2S、充电、休眠、唤醒
蓝牙连接	与手机建立和维护蓝牙业务	配对、回连、A2DP、AVRCP、HFP、BLE
双耳协同	让左右耳保持一致	双耳组对、角色、状态同步、音频协同
音频系统	管理声音输入和输出	编解码、播放、录音、提示音、ANC、ENC
产品应用	决定耳机具体怎样工作	按键、LED、佩戴检测、状态机、功能优先级
数据与升级	保存配置并更新固件	配对记录、用户设置、OTA、版本管理
调试与测试	帮助发现和定位问题	日志、异常信息、测试模式、量产支持

二、系统与 RTOS

TWS 耳机一般不是从上到下只执行一条固定流程。蓝牙事件、按键、音频、充电和定时任务可能在不同时间发生，因此软件需要同时管理多种事情。

这一部分通常包括：

系统启动和各模块初始化
任务或线程的创建与调度
事件、消息和队列
软件定时器
内存分配与任务栈
中断处理
看门狗和异常恢复

应用层开发中经常接触到的，并不是 RTOS 调度器本身，而是平台提供的任务、消息和回调接口。

例如，按键驱动检测到一次双击后，不一定会直接执行“切换降噪模式”。它可能先产生按键事件，再把事件投递给应用任务，最后由应用代码根据当前状态决定是否执行这个功能。

所以，当我们阅读一个新 SDK 时，找到事件入口和消息流转路径很重要。

三、硬件驱动与电源管理

耳机虽然体积不大，但里面仍然有不少硬件。软件需要通过不同接口读取状态或者控制这些器件。

常见内容包括：

GPIO：NTC供电、LED、使能信号
ADC：按键电压、其他模拟量
UART：日志输出、机盒
充电与盒仓检测：识别 DC、入盒、出盒、开盖、关盖、充电和满电等状态
佩戴检测：红外、触摸或其他传感器
I2C、SPI：传感器、外部芯片或存储器
I2S、PCM：数字音频数据传输

驱动层负责把硬件状态转换成软件可以识别的数据或事件，应用层再决定怎样处理。

“耳机入盒”背后涉及盒仓状态检测、TWS 对耳同步、按键禁用、ANC 和音乐处理、DAC 控制及主从切换；关盖后还要关闭蓝牙并进入 FUNC_IDLE或 charge等其他模式。处理不完整，可能导致左右耳状态不一致、盒内仍播放声音或关盖后仍连接手机。

蓝牙核心系统架构介绍

Mon, 10 Nov 2025 00:08:08 +0800

一、蓝牙的两种模式

（1）经典蓝牙（BR/EDR）

用于高数据速率应用，如无线耳机、音箱、键盘。

特点是连接稳定，适合持续传输音频或大量数据。

（2）低功耗蓝牙（BLE）

专为低功耗设备设计，如智能手环、温度计、传感器。

特点是耗电低，适合间歇性传输小数据。

总结：两种模式底层都用无线信号传输数据，都遵循蓝牙协议，只是侧重点不同。经典蓝牙重视速度和稳定，BLE重视省电和简单连接。

二、蓝牙核心系统组成

蓝牙核心系统由主机（Host）和控制器（Controller）两部分组成。

主机负责高层协议和控制逻辑，控制器处理底层射频和信号传输。两者分工合作，设备才能正常工作。

三、主机部分（Host）

主机包含多个协议模块，经典蓝牙和BLE有所不同。

经典蓝牙主要模块：

GAP（通用访问协议）：管理设备发现和连接建立。

SDP（服务发现协议）：帮助设备发现对方支持的服务。

L2CAP（逻辑链路控制协议）：管理数据流，负责数据分段和重组。

SMP（安全管理协议）：负责加密连接和密钥管理。

BLE主要模块：

GAP（通用访问协议）：管理设备发现和连接建立。

GATT（通用属性协议）：规定设备如何描述和交换数据属性。

ATT（属性协议）：按照GATT规则传输数据。

SMP（安全管理协议）：负责加密连接和密钥管理。

经典蓝牙工作流程：

GAP搜索附近设备并建立连接
SDP查找对方支持的服务
L2CAP处理数据传输，分段重组
SMP管理密钥和加密

BLE工作流程：

GAP搜索附近设备并建立连接
GATT列出设备支持的服务和数据属性
ATT按照GATT规定格式传送数据
SMP保障连接和数据安全

四、控制器部分（Controller）

控制器处理蓝牙底层功能，直接与硬件交互。

主要模块：

LL（链路层）：管理蓝牙设备的链路状态和数据包传输。

RF（射频层）：处理蓝牙信号的发送和接收。

IAL（等时音频层）：BLE特有，处理高实时性数据传输，例如音频。

控制器主要负责：

链路管理：连接的建立、维持、断开。

无线信号传输：信号调制解调、频率管理、纠错编码。

硬件交互：直接控制无线电模块发射和接收。

五、HCI（主机控制器接口）

HCI是连接主机和控制器的桥梁，负责两部分之间通信。

特点：

标准化接口，让不同厂商的设备互相兼容。

传输命令、事件和数据包。

举例：手机的应用层通过HCI命令告诉蓝牙芯片"开始扫描附近设备"，芯片执行后通过HCI事件返回扫描结果。

六、双模蓝牙

双模蓝牙同时支持经典蓝牙和BLE，一个设备两种能力

硬件层面同时支持BR/EDR和BLE。软件层面整合经典蓝牙和BLE的高层协议。

支持经典蓝牙的SDP和BLE的GATT，灵活切换。

举例：手机可以同时连接蓝牙耳机（经典蓝牙）和智能手环（BLE）

七、总结

经典蓝牙和BLE虽然侧重不同，但架构相似：都是主机管逻辑，控制器管硬件，通过HCI通信

经典蓝牙适合持续大数据传输，BLE适合低功耗间歇传输。

双模设备兼具两种能力，应用更广泛。

原文：CSDN · 蓝牙核心系统架构介绍

BLE设备地址介绍

Sun, 09 Nov 2025 21:19:34 +0800

什么是BLE设备地址

BLE设备地址48位长度，用来识别低功耗蓝牙设备。

地址分为公共地址和随机地址两大类，现代BLE设备为保护隐私，很少直接用公共地址广播。
注意：BLE地址和经典蓝牙地址虽然都是48位，但机制不同。

一、公共设备地址

由IEEE官方分配，全球唯一，永久不变。
常见设备：早期蓝牙键盘、鼠标。
优点：全球唯一，不会冲突。
缺点：申请要钱，容易被追踪定位。
地址结构：通常前3字节是厂商代码，后3字节厂商自己分配，也可以自定义。

举例：00:1A:7D:12:34:56

00:1A:7D = 苹果厂商代码
12:34:56 = 苹果内部设备序号

二、随机设备地址

BLE随机设备地址，设备自己生成，分三种：

1. 静态随机地址

开机时随机生成，本次开机内不变，重启后重新生成。
地址特征：最高两位为"11"，地址C0-FF开头。
常见设备：智能手环、体重秤、温度计。
优点：免费，开机内稳定连接。
缺点：设备多了可能冲突，重启后地址变化可能影响自动重连。

2. 可解析私有地址

BLE隐私保护核心。地址定期变化（通常15分钟），配对过的设备可通过IRK密钥识别真实身份。
地址特征：最高两位为"01"，地址40-7F开头。
常见设备：iPhone、Apple Watch、Android手机、AirPods。
工作原理：设备用IRK密钥生成临时地址，配对设备存有IRK可验证身份，陌生设备只看到随机地址。
举例：商场里手机地址每10分钟变一次，商家无法追踪你。但AirPods能认出你的手机，因为有共享密钥。
优点：防位置追踪，不影响已配对设备连接。
缺点：需要密钥管理和地址解析算法。

3. 不可解析私有地址（NRPA）

完全随机临时地址，任何设备都无法识别。
地址特征：最高两位为"00"，地址00-3F开头
常见场景：BLE Beacon广播、一次性数据推送。
举例：商场Beacon广播促销信息，路人收到即可，无需连接和识别。
优点：最强隐私保护。
缺点：无法建立连接，只能单向广播。

三、应用场景对比

蓝牙键盘鼠标：公共地址，稳定识别。
智能手环体重秤：静态随机地址，成本低。
iPhone和智能手表：可解析私有地址，防追踪。
BLE Beacon：不可解析私有地址，一次性推送。

四、BLE和经典蓝牙地址区别

经典蓝牙主要用公共地址，很少变化。
BLE主流用随机地址（特别是可解析私有地址），定期变化保护隐私。
同一设备可能同时有经典蓝牙地址和BLE地址，它们独立。
BLE地址最高2位标识类型，经典蓝牙没有。

五、实用知识

查看BLE地址（Android）：设置→关于手机→状态信息→蓝牙地址。
手机地址为什么总变？现代手机用可解析私有地址，每10-15分钟换一次，防止被追踪。

识别地址类型看第一字节：

C0-FF：静态随机
40-7F：可解析私有
00-3F：不可解析私有
其他：公共地址

总结：

BLE地址虽然分为四类，但一般都使用随机地址，在开发中

小型外设一般用静态随机，简单省钱
手机可穿戴一般用可解析私有，保护隐私
广播类一般用不可解析私有，单向推送

原文：CSDN · BLE设备地址介绍

BLE的7种工作状态

Sun, 09 Nov 2025 21:11:30 +0800

BLE芯片的链路层定义了7种工作状态，同一时间只能处于一种状态，不同状态之间可以切换，一颗芯片可以有多个状态机同时工作，下面对这些状态进行介绍。

七大状态介绍

一、待机状态（Idle）

芯片既不发送也不接收数据，处于休眠。

特点：

可以从任何状态进入待机状态

可以从待机进入除连接状态外的所有状态

不发射不接收，最省电

举例：你的手环没在用时，芯片就在待机状态睡觉。

二、广播状态（Advertising）

芯片主动发送广告包，告诉周围"我在这里"。

作用：让别人发现你，并能回复扫描请求。

举例：蓝牙音箱进入配对模式，不断广播"我是XX音箱，快来连我"。

可以从广告状态直接进入连接状态。

三、扫描状态（Scanning）

芯片监听周围的广告包，寻找可用设备。

作用：发现附近的BLE设备。

举例：手机打开蓝牙，扫描附近设备，此时手机处于扫描状态。

四、发起状态（Initiating）

芯片接收特定设备的广告包，并回复连接请求。

作用：主动发起连接。

举例：手机点击"连接手环"，进入发起状态，向手环发送连接请求。

可以从发起状态进入连接状态。

五、连接状态（Connection）

设备已建立连接，可以双向传输数据。

作用：进行数据交互。

举例：手环和手机已连接，正在同步步数和心率数据。

注意：只能从广播状态或发起状态进入连接状态，不能从待机直接连接

六、同步状态（Synchronization）

芯片接收周期性广告的数据包。

作用：同步接收定期更新的信息。

举例：接收BLE定位信标的周期性位置信息。

适用场景：需要定时接收广播数据但不建立连接。

七、等时广播状态（Isochronous Broadcasting）

芯片在等时信道上发送数据包。

作用：发送对时间敏感的数据流。

举例：BLE音频设备同步传输音乐到多个耳机（LE Audio）。

适用场景：需要精确时序的音频或数据传输。

八、状态切换规则

常见切换路径：

待机 → 广播 → 连接（外设被连接）

待机 → 扫描 → 发起 → 连接（中心设备主动连接）

连接 → 待机（断开连接）

任何状态 → 待机（随时可以休眠省电）

待机 → 广播/扫描/同步/等时广播（但不能直接到连接）

九、实际应用场景

智能手环：

没用时：待机状态（省电）
等待连接：广播状态（被发现）
已连接：连接状态（传数据）
断开后：回到待机

手机：

无线通信是如何实现的

Sat, 08 Nov 2025 18:45:37 +0800

无线通信技术早已经融入我们的生活，如手机通信，WiFi，蓝牙。背后都离不开它的支撑。那么，这项技术究竟是如何实现的呢？

一、基本实现原理

无线通信用的是电磁波信号，我们说话的语音，拍的图片，听的音乐，这些信息首先通过调制技术加载到无线载波上，然后由发射设备发送出去。接收方通过解调操作，把载波上的信息取下来，恢复成原始信号。

二、系统构建复杂性

构建一个无线通信系统很复杂，它主要涉及以下几个部分：

1.模数转换（确保传输和处理时兼容）

2.RF射频设计（负责信号发射和接收频率调控）

3.协议栈（无线通信标准）

专业开发要求

硬件设计需要高精度元器件匹配，系统调试需专门开发环境与经验，因此市场上很少从头搭建系统，而是普遍采用常用无线通信模块。把多个核心元器件集成在一起，直接实现特定通信功能，大大降低了应用门槛。

无线通信模块

无线通信模块就像是一个与装好的工具箱，主要由基带芯片，射频收发器等关键元器件组成，能直接作为通信终端使用，其中两大核心部分尤为重要。

1.系带芯片：调制解调。同时还会检测传输中可能出现的错误，并及时纠正，确保信息准确。

2.射频前端电路：信号强化器。射频信号在传输过程中可能会衰减，混入杂音，射频前端就负责对信号进行放大（提升强度，让传输更远）和滤波（过滤杂音）处理好的信号在通过天线发射出去，确保对方能清晰收到。

总结

无线通信系统的实现就是信息数字化“编码调制-射频发射-接收解调-信息还原”的闭环，在通过核心硬件的协同和统一标准的规定，最终实现稳定，高效的无线通信。

原文：CSDN · 无线通信是如何实现的

无线通信原理

Sat, 08 Nov 2025 17:09:46 +0800

1. 无线通信的本质：把信息“寄”到空气里

无线通信就是利用电磁波在空中传递信息——类似寄快递：

电磁波 = 快递盒：看不见摸不着，却能把内容送出去。
要传的内容 = 信息：音乐、指令、传感器数据等。

无线通信的流程只有两步：

调制（打包）：把信息装进“电磁波快递盒”。
解调（拆包）：收件方拆开快递，还原信息。

✏️ 蓝牙通信实例

调制：手机播放音乐时，蓝牙芯片把音频数据调制到 2.4 GHz 电磁波上，同时选择合适的频道，避免和 Wi-Fi “撞车”。
解调：蓝牙耳机接收到电磁波后，芯片解调数据并还原成声音。

2. 无线通信绕不开的麻烦：干扰

常见两种干扰类型：

同频干扰 Wi-Fi、蓝牙鼠标都在用 2.4 GHz，像多辆快递车挤同一条路。一旦有人开大功率 Wi-Fi，旁边的蓝牙键盘就会延迟。解决办法是让蓝牙跳频，类似换车道。
环境干扰 金属、墙体会衰减信号；厚衣物、人体遮挡都会减弱电磁波；旁边的蓝牙音箱可能会“滋滋”响。

3. 蓝牙的抗干扰技术

自适应跳频（AFH） 蓝牙在 2.4 GHz 频段的 79 个子信道里高速跳频，每秒最多跳 1600 次。检测到某个频道被占用，就换到空闲频道，降低碰撞概率。
纠错编码（FEC） 发送时附加冗余信息，即使部分数据受干扰被破坏，也能用冗余位恢复原数据，保证语音、音乐的连续性。

4. 常见无线技术对比

技术	典型用途	特点与蓝牙对比
蓝牙	耳机、音箱、手表、键鼠	功耗低、延迟小、距离短（约 10 米），适合随身设备
Wi-Fi	上网、智能家居联网	速率高、覆盖远，但功耗大，不适合小电池设备
LoRa / NB-IoT	远程传感器、智慧城市场景	覆盖远、功耗低，但速率慢，延迟大，不适合音视频

5. 常见蓝牙连接问题排查

现象	可能原因	建议处理
蓝牙耳机偶尔卡顿	Wi-Fi 同频干扰	远离路由器或尝试重连
穿墙后信号大幅衰减	墙体、金属屏蔽电磁波	尽量保持直线距离，避免多层阻挡
口袋里手机连接手表不稳定	人体吸收 2.4 GHz 信号	手机放包里或手表靠近手机
微波炉一开蓝牙噪音变大	微波炉辐射同频信号	避免同时使用或保持距离

6. 总结

无线通信的核心是“调制 + 电磁波传输 + 解调”。蓝牙之所以适合日常设备，是因为它在功耗、抗干扰和延迟之间做到了平衡。如果遇到连接问题，多半是干扰或遮挡导致。

LE audio介绍

Fri, 07 Nov 2025 00:15:34 +0800

LE audio介绍

LE Audio是它全称是Low Energy Audio（低功耗音频）

是蓝牙技术联盟在5.2核心规范里引入的全新，低功耗音频技术标准

在低功耗、多设备连接和音频共享上实现了超大突破！

LC3编解码器

全新的音频编解码器LC3,是LE audio的灵魂所在，

和传统SBC编解码器比起来，哪怕数据速率更低，也能提供相同甚至更好的音质。

不管是日常听歌还是打电话，都能在省功耗的同时稳稳保住音质。

多流音频技术

多流音频是LE audio的另一种优势！以前耳机主副耳要转发信号，现在智能手机等源设备能独立同步给两个耳机发多个音频流，直接消除了转发环节。带来的好处：连接更可靠、延迟更低、左右声道同步更完美！

比如听歌时来电话，不用断开音乐，能无缝切到通话，挂完电话又自动切回音乐，丝滑不卡顿。

广播音频功能

广播音频功能是LE Audio最具有革命性的功能，直接开启了音频共享的新时代！蓝牙联盟将其品牌化为 Auracast™。它允许一个音频源设备（比如手机）能以发射器身份，把一个音频流广播给附近无数个接收设备（比如不同品牌的耳机，只要支持LE Audio就能订阅，Auracast支持跨品牌设备接收）比如：大家可以用不同的耳机听同一个音频，可以是音乐，电影，广播。

总结：LE Audio为啥是未来趋势？

简单说就是三个字：长！高！稳！更长的续航，更高的音质、更稳定的连接，现在支持LE Audio的设备越来越多，妥妥的未来蓝牙音频主流方向。新手宝子如果想了解蓝牙音频新技术，LE Audio一定要重点关注！收藏这篇，随时回看。

原文：CSDN · LE audio介绍

蓝牙启蒙认知

Tue, 14 Oct 2025 19:29:36 +0800

蓝牙入门知识

一、蓝牙名字的由来

蓝牙名字,来自1000年前丹麦国王"哈拉尔德·蓝牙"的名字,因为这位国王统一了丹麦和挪威的部落。而蓝牙技术则统一了无线通信标准。

二、蓝牙解决了什么问题

代替有线连接：告别数据线的束缚
设备互联互通：不同设备也能通信（统一标准）
低成本低功耗：比wifi省钱，比红外线灵活

蓝牙让短距离无线连接变得简单，便宜，省电。

三、蓝牙是如何工作的

发现（Discovery）:搜索附近的蓝牙设备
配对（Paring）:首次建立信任，交换秘钥
连接（Connection）:正式通信，传输数据

技术层面：

跳频，采用2.4Ghz 频段，这个频段很多设备。为了不被干扰，蓝牙采用了跳频技术，所以不会被窃听或干扰。
握手，设备首次建立信任，交换密钥，验证双方的身份，验证通过后，就能传输数据。
蓝牙传输数据，蓝牙传输数据就像是寄快递，会把大文件切成多个小包（经典蓝牙单包最多339字节，BLE单包最多251字节），每个包都贴上“收件人地址”和“顺序编号”，通过无线电波“快递”过去，对方收到后按编号重新拼装。
连接稳定性，当距离太远（一般有效范围10~100米，取决于蓝牙功率，一般设置为10米左右），障碍物遮挡，电量不足，电磁干扰（wifi,微波炉），发射和接收功率设置，蓝牙版本不兼容，都会影响蓝牙连接的稳定性。

补充：蓝牙是如何空气中传输数据的

四、什么是2.4GHz频段

频率范围：2.400-2.4835GHZ

全球免许可：不需要申请就能用

穿透力适中：能穿墙但不会太远，10米左右

注意：2.4Ghz频段很拥挤，WIFI，微波炉，无线鼠标都在用，所以蓝牙必须有抗干扰技术

蓝牙为什么不用其他频段？

低频段（比如900Mhz）:穿透性强但传输速度慢，天线太大装不进小设备

高频段（比如5GHz）:传输速度快但穿透性差，耗电更多

2.4Ghz刚好平衡了所有需求，够快，够小，够省电，够穿透

五、跳频技术原理

经典蓝牙把2.4Ghz分成79个信道（每个1Mhz）,频率范围2402~2480，跳频速率固定1600次/秒（每625微秒跳一次，一个时隙625微秒），跳频序列是随机的，只有配对设备才知道。工作原理是提前约定好下一跳的信道，在79个信道中快速切换见面。经典蓝牙没有专门的广播专用信道，数据信道79个都可以用于传输。

BLE和经典蓝牙不同的点在于，BLE把2.4Ghz分成40个信道（每个2Mhz），跳频速率自适应，有3个广播专用通道，37个数据通道。

六、为什么蓝牙不会互相干扰

跳频序列不同，每个蓝牙设备都在不同的跳频，即使跳到同一信道，时间也是错开的，万一真的碰上，有重传机制。

七、主设备&从设备

主设备（Master）:发起连接，管理网络，控制时钟

从设备（Slave）：响应连接，被动接收指令

举例：

手机连蓝牙总是手机主动，耳机被动。这是蓝牙世界的基本规则，所以必须分出老大和小弟，这是蓝牙世界的等级制度。其中，一个当老大（Master），其他当小弟（Slave）,通常是主动发起连接的当老大，老大说了算，小弟负责听指挥。

责任划分：

主设备决定大家按什么顺序跳频，分配谁什么时候可以“说话”，当多个从设备同时要传输数据时，主设备决定谁先传谁后传。

从设备必须跟着主设备时钟走，主从设备会定期进行时钟同步，短时间偏差会通过重传机制纠正，只有长时间失去同步才会断连。蓝牙采用时分双工机制，主设备占用偶数时隙，从设备占用奇数时隙，每个时隙为625微秒。

分主从是避免混乱，如果设备都平等，谁来决定跳频顺序和分配传输时间。所以必须分主从来进行管理。主从结构让协议变的简单，主设备负责复杂的管理工作，从设备只需听指令就行。主设备下达命令，从设备立即执行，不用讨论。但主从之间有距离限制，距离太远，主设备管不到的地方，从设备就会断连。主从角色在某些情况可以切换，比如在TWS耳机中，耳机组队可以协商谁当主设备，谁当从设备。

典型例子：

手机=主设备，蓝牙耳机=从设备

电脑=主设备，蓝牙鼠标=从设备

注意：一个主设备最多连接7个从设备（蓝牙使用3位地址标识从设备，其中000保留，所以实际可用001~111=7个）

八、微微网概念

**核心理解：**微微网是蓝牙世界的基本单位，微微网=1个主设备+最多7个从设备组成的蓝牙小网络。
基本规则：必须有一个主设备，最多有8个成员，并且保持同一个频率节奏，所有成员必须同步跳频，跟着主设备的节拍走。
生命周期：主设备发起网络连接，从设备陆续加入，大家按规则通信，主设备可以选择关闭或断开从设备的通信。
通信规则：从设备只能和主设备说话，不能直接和其他从设备聊天，必须通过主设备中转。
轮流通信：主设备分配时隙，每个从设备按顺序说话，每0.625毫秒为一个时间片。

时间轴（每个时隙625微秒）：
0    1    2    3    4    5    6    7
|____|____|____|____|____|____|____|
 主   从1  主   从2  主   从3  主   从1

规则：
- 偶数时隙：主设备发送
- 奇数时隙：从设备发送

为什么叫微微网？

01-蓝牙协议栈介绍

Wed, 19 Mar 2025 01:41:41 +0800

01 蓝牙入门-蓝牙协议栈介绍

一、蓝牙类型

特性	经典蓝牙（BR,EDR)	低功耗蓝牙(BLE)	备注
全称	Basic Rate / Enhanced Data Rate	Bluetooth Low Energy	经典蓝牙在嵌入式领域基本被放弃使用，现在着重使用低功耗蓝牙
主要用途	音频传输	低功耗设备	经典蓝牙适合大数据传输，BLE适合小数据、低功耗场景
传输速度	1-3 Mbps	1 Mbps
功耗	高	极低	BLE的功耗是经典蓝牙的1/10到1/100，适合电池供电设备
连接时间	较长（通常需要几秒）	极短（毫秒级）	BLE连接快，适合频繁连接和断开的场景
兼容性	仅支持经典蓝牙	仅支持BLE的蓝牙	双模蓝牙设备可以同时支持经典蓝牙和BLE，兼容性更强

说明：

这两种协议都包括搜索管理，连接管理等机制，但他们底层是相互独立，不能互通的技术
厂家如果只实现了一种，那么只能与同样实现该技术的设备互通，如果厂家需要所有的蓝牙设备互通，那么就必须同时实现两种技术，而不去管是否真的需要

二、方案介绍

三种方案对比：

方案	单芯片方案	蓝牙+MCU方案	Host+Controller方案
适用场景	蓝牙音响、蓝牙耳机	智能手环、智能手表	手机、平板等复杂设备
功能复杂度	功能固定，较简单	功能中等，需要额外处理能力	功能复杂，需要高性能处理
开发难度	低	中等	高
成本	低	中等	高
功耗	低	中等	高
蓝牙协议栈位置	集成在单芯片中	蓝牙芯片负责通信，MCU负责逻辑处理	蓝牙协议栈在主芯片中，蓝牙芯片负责底层通信

三、蓝牙协议栈

HFP：接电话、挂电话。【蓝牙电话协议】
A2DP：听音乐。【蓝牙音频传输协议】
AVRCP：切歌、调音量。【蓝牙音视频远程控制协议】
PBAP：同步联系人。【蓝牙电话本访问协议】
MAP：查看短信。【蓝牙短信访问协议】

蓝牙协议的简化架构图

归档 on 栈外随记

我为什么越来越看好 AI 眼镜

一、为什么这么多厂商都在做

二、眼镜能帮我们做什么

三、一个能帮人记住事情的助手

四、长期记录会带来多少数据

五、隐私是绕不开的问题

六、续航、重量和颜值都很重要

七、它会取代手机吗

参考资料与视频

周末重拾 STM32，从点灯开始

背景介绍

一、CubeMX 配置工程

1. 配置外部时钟

2. 配置时钟树

【BES】编译配置（03）：Make 变量怎样变成 C 宏

一、从变量到宏的传递过程

1.1 定义 Make 变量

1.2 export：传递给子 Make

【BES】编译配置（04）：源码怎样编译成固件

一、源码选择与编译

1.1 core-y：选择顶层目录

1.2 obj-y：列出子目录和目标文件

（1）子目录条目

（2）目标文件条目

【BES】外设适配（01）：触摸输入从采样到事件

一、TWS 按键交互背景

二、触摸检测的基本流程

三、开机后，从应用初始化到触摸初始化

3.1 从应用入口进入检测初始化

【BES】外设适配（02）：触摸事件怎样交给应用

一、初始化时，登记事件接收函数

【BES】编译配置（01）：编译命令与构建脚本

一、执行编译命令

二、为固件补充校验信息

2.1 CRC 后处理

【BES】编译配置（02）：构建目标与配置覆盖

一、构建目标与配置加载

1.1 T：选择构建目标

1.2 CHIP：指定芯片平台

1.3 配置文件的加载顺序

【BES】系统总览（02）：开机初始化到应用模块

一、应用层从哪里开始

二、app_init() 初始化系统和模块

三、建立应用线程和邮箱

【BES】系统总览（03）：事件如何触发业务处理

【BES】系统总览（03）：事件如何触发业务处理

一、事件与业务的区别

【BES】系统总览（01）：编译配置如何决定固件功能

一、编译配置是什么

二、ANC 配置如何影响源码

1. 判断是否加载 ANC 配置

【中科蓝讯】耳机电量是怎样更新到手机的

电池电压是怎么采出来的？

为什么采到电压后还不能直接使用？

参考电量为什么不直接给手机？

显示电量是怎么变化的？

为什么内部电量和手机显示还可能不同？

左右耳电量最后由谁上报？

【中科蓝讯】耳机电量与充电问题复盘

一、电压稳定方案的设计思路

二、电量曲线

三、温度采样

【中科蓝讯】机盒通信问题单复盘

一、快速开关盖后异常断连

二、左右耳回复不一致，盒子灯效频闪

三、耳机进入配对，盒子却不显示配对灯效

四、配对超时后，盒子显示了错误灯效

【中科蓝讯】TWS 耳机机盒通信链路

一、UART 收包与协议解析

【中科蓝讯】TWS音量是怎样同步的

一、手机调节音量后的主流程

【中科蓝讯】TWS 耳机音量问题单复盘

写在开始

一、回连后的初始音量不对

二、快速调节时双耳音量不同步

【中科蓝讯】ANC 模式是怎样切换的

一、先把 ANC 的几条链路放在一起

【中科蓝讯】TWS 耳机 ANC 问题单复盘

写在开始

1.2 `export`：传递给子 Make

1.1 `core-y`：选择顶层目录

1.2 `obj-y`：列出子目录和目标文件

1.1 `T`：选择构建目标

1.2 `CHIP`：指定芯片平台

二、`app_init()` 初始化系统和模块