简介这是一份面向嵌入式语音应用开发者的杰理AC695N芯片SDK开发包能够在智能家居、玩具、安防等场景中帮助工程师高效完成从硬件设计到软件编程的全流程开发。压缩包为RAR格式体积约111.86MB内容涵盖芯片数据手册、硬件电路设计指导、SDK源码含驱动、API库、示例代码及编译工具链、版本升级补丁和开发文档其中SDK目录下的驱动程序、API库和示例代码覆盖了语音采集、播放、编解码等典型功能可直接迁移到实际项目中目录结构清晰方便按需查阅。目前已有1844人学习浏览适合需要快速上手AC695N语音芯片的中高级嵌入式开发者。通过这套资源开发者可系统掌握芯片配置、录音/播放及音效处理等关键技能并借助硬件资料规避电路设计风险参考示例代码缩短产品研发周期获取从底层驱动到上层应用的完整支持。1. 杰理 AC695N SDK 开发包先判断它适不适合你的产品很多人第一次拿到「杰理 JL AC695N 语音芯片 SDK 开发包」是在选型阶段或者方案公司转交资料时。说实话这包东西跟“装上 IDE 就能点运行”的开发套件是两回事它是一套需要自己在 Linux 里编译、配置、烧录的完整 BSP里面预装了蓝牙协议栈、音频框架、电源管理和一批可参考的 demo。但代价是你得能看懂 make 脚本、改 config 配置、搞定 USB 烧录不识别这类问题。我把它按“认芯片 → 搭环境 → 改固件 → 踩坑 → 收尾”的顺序拆一遍适合刚转嵌入式的人也适合想评估这颗芯片能不能扛住量产需求的工程师。2. AC695N 的资源边界双模蓝牙、音频 DSP 与 SDK 目录结构拿到开发包以后别急着跑编译。先花半天把 AC695N 这颗芯片的资源边界搞清楚后续能省掉大量改来改去的动作。很多问题是选型阶段埋下的比如你以为芯片有内嵌 Flash结果拿到的型号需要外挂 SPI Flash比如你要做语音助手但评估板默认配置根本没开 DSP 的 AEC。下面的内容都围绕“资源决定功能”展开。2.1 芯片层面的关键参数什么能做什么不能做AC695N 属于 AC69 系列的后续量产型号定位是中等价位的蓝牙音频语音 SoC常见于蓝牙音箱、智能遥控器、语音助手、TWS 充电仓这类产品。它的核心资源可以按下表理解这几项直接决定你的产品能不能落地。资源区域能力边界开发时要注意的事蓝牙协议双模BR/EDR BLE支持 A2DP/AVRCP/HFP 等常用 profile要确认是否支持同时连接多个设备以及 BLE 广播模式是否常开音频编解码SBC/AAC 为主支持本地 Flash/SD 卡播放如果是 AAC要检查授权是否在 SDK 内已包含MCU 与 DSP32 位 MCU 加可编程 DSP常见为 RISC-V 内核DSP 可做 EQ、降噪、AEC、部分唤醒词识别存储扩展内嵌小容量 Flash或 SPI Flash 挂载音频资源多的时候优先规划资源分区大小音频接口模拟 Line-in/Mic、I2S、PDM 数字麦克风PDM 麦克风选型要注意灵敏度差异模拟方案注意底噪电源管理内置 PMU支持锂电池直充和充电检测软件上要区分“充电中”和“满电”否则电量显示会飘这一层的结论是AC695N 适合做“带蓝牙音频 轻量语音交互 电池供电”的产品。如果产品有复杂的本地语义理解、Wi-Fi 音频流、或者需要多路 I2S 同时跑这颗芯片会非常吃力。选型时把能力边界卡死能省掉后面很多翻车。2.2 SDK 目录分层从哪里看起从哪里改起我拆过的多个版本的 SDK 结构类似不同版本目录名可能略有差异但分层逻辑是稳定的芯片相关底层独立、平台驱动独立、应用层独立。下面这份树形结构是从常见 ACL695N 开发包中提炼出来的典型布局。AC695N_SDK/ ├── apps/ │ ├── demo/ │ │ ├── bt_music/ # 蓝牙音乐播放参考工程 │ │ ├── bt_call_box/ # 免提通话/语音通话示例 │ │ └── speech_assistant/ # 带唤醒词识别的语音助手示例 │ └── config/ # 各产品的编译配置与宏开关 ├── arch/ # 内核寄存器操作、启动代码 ├── src/ # SDK 主体蓝牙协议栈、媒体播放、电源管理 ├── platform/ # 板级驱动DAC、ADC、充电、按键、LED ├── include/ # 对外提供的头文件与接口声明 └── tool/ # 烧录工具、日志工具、音频资源转换脚本拿到包之后我一般建议按“apps/demo → apps/config → include → platform → arch”的顺序看。先在 demo 里找一个最接近产品的工程再在 config 里确认支持哪些宏开关然后在 include 里找接口。千万不要一上来就翻 arch那是寄存器层面的东西除非你要做内核级别的定制否则不要动。这种分层的价值在于绝大多数量产定制只需要改应用层和板级驱动。比如修改按键逻辑、换提示音、改蓝牙名称都在 apps 和 platform 里完成。只有新增外设比如接一块新的传感器才会动到 arch 或者 SDK 底层的适配。把这条边界立住整个项目 80% 的改动都被限定在可控范围里。3. 编译 AC695N SDK装环境、选工程、生成固件的完整流程编译环境这一步是新人卡住最多的地方。杰理 SDK 多年沿用 Linux 编译体系官方文档提到的环境多为 32 位 Ubuntu。如果你手头只有 64 位系统也不是不能用但要把 32 位运行库补齐。另外WSL 环境可以编译但 USB 烧录这一步在 WSL 里会遇到端口映射问题实际量产阶段非常不方便这点放到后面避坑章节细说。3.1 编译环境搭建32 位库与依赖准备先明确一个原则编译工具链通常是 SDK 包内自带的预编译交叉工具链而不是系统自带的 gcc。所以环境搭建的重点不是“装编译器”而是让工具链能在你的 Linux 上正常执行。64 位 Ubuntu 下最容易缺的就是 32 位运行库缺了之后工具链会直接报“No such file or directory”但文件明明存在这个表现非常迷惑。# 以 64 位 Ubuntu 为例先支持 32 位架构 sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install -y libc6:i386 libstdc6:i386 libncurses5:i386 # 确认 32 位库是否生效 ldconfig -p | grep -E libncurses.so.5 | head -5逻辑说明第一组命令的作用是添加 i386 架构源并把 SDK 依赖的动态库补上。libc6:i386 和 libstdc6:i386 负责工具链的基础运行libncurses5:i386 负责编译时勾选配置菜单的界面显示。参数说明如果你的发行版较新、软件源里已经没有 libncurses5可换成 libncurses6 再试试但部分旧版 build 脚本会明确找 ncurses5这属于版本差异需要根据需要灵活处理。做嵌入式开发我一般会在 Linux 上保留一个长期不升级的编译环境避免系统滚动更新之后库版本漂移。3.2 编译流程选择工程、生成固件、检查产物SDK 目录下通常有 build.sh 脚本整套编译流程的第一道关卡就在这里。以比较常见的操作顺序为例cd AC695N_SDK # 第一步通过配置界面选择芯片型号和 demo 工程 ./build.sh config # 选择 AC695N 系列 # 选择 bt_music蓝牙音乐播放工程 # 第二步开始编译-j 后面的数字是并行任务数 ./build.sh -j8 # 第三步查看固件产物 ls -l out/逻辑说明build.sh config 会进入一个选择菜单把所选芯片型号、demo 工程写入 .config 文件。后面再执行 build.sh 时编译系统以这个 .config 为准把对应 demo 的源码、SDK 库、资源文件打包进固件。参数说明-j8 表示 8 个编译任务并行。如果编译过程中出现内存不足导致的报错就把数字降下来改成 -j4 或 -j2等一下总比崩溃强。编译产物一般在 out/ 目录下里面至少会有 .bin 烧录文件和 .elf 调试文件。.elf 必须保留好后面第 6 章的崩溃定位要用到它。编译通过后第一次启动开发板前还要做两件事确认固件里包含的配置信息和你的硬件一致特别是晶振频率、Flash 大小、GPIO 复用确认烧录工具能识别到芯片。这两个点也是整个 SDK 使用过程中出现频率最高的拦路虎后面会展开讲。4. 改量产固件提示音替换与蓝牙名称修改实操开发包里的 demo 工程能跑起来之后下一步就是把固件改出自己的味道。这个阶段的高频需求基本就三类换提示音、改蓝牙名称、调整设备信息。本文以提示音和蓝牙名称为例完整走一遍“改资源 → 改配置 → 重新编译”的流程。这也是新手最容易把代码改坏的地方因为改了不干净固件表现异常。4.1 替换提示音先转换格式再打资源包很多人第一次改提示音直接把 mp3 文件丢进工程目录然后发现编译能过但播放没有声音。原因是 AC695N 的提示音不是直接引用文件而是要先把音频转换成固定格式的资源文件再链接进固件。SDK 的 tool 目录下一般有资源转换脚本不同版本名字略有差异但逻辑一致。# 第一步把音频统一处理成 16kHz、16bit、单声道 WAV ffmpeg -i old_power_on.mp3 -ar 16000 -ac 1 -sample_fmt s16 power_on.wav ffmpeg -i old_power_off.mp3 -ar 16000 -ac 1 -sample_fmt s16 power_off.wav # 第二步把需要打包的音频文件名写入清单 cat audio_list.txt EOF power_on.wav power_off.wav EOF # 第三步调用 SDK 资源打包脚本生成 res_audio.bin python3 tool/audio/make_audio_res.py audio_list.txt res_audio.bin逻辑说明第一步把音频强制转成统一的采样率、位深、声道数原因有两个。一是 SDK 的资源打包工具对格式有硬性要求二是 AC695N 的解码和播放框架在统一参数下运行最稳定避免了不同音源切换时的采样率跳变。第二步和第三步是把音频文件打包成一个 bin 资源文件这个 bin 会在编译时被链接进固件。参数说明-ar 16000 表示 16kHz 采样率-ac 1 表示单声道-sample_fmt s16 表示 16bit 位深。如果你做的是语音类产品建议所有提示音都按这个标准做人声在 16kHz 下足够清晰资源占用也最小。资源打包完成后还要在以板配置里声明启用这个资源文件。在 apps/demo 对应工程的资源列表里加上 res_audio.bin然后重新编译提示音才会生效。4.2 修改蓝牙名称与设备信息找到宏定义一次改到位修改蓝牙名称这个需求非常高频。很多人直接在代码里搜产品名、搜 “AC695N” 字符串但实际名称往往藏在一个设备信息结构体或者宏定义里搜不到的时候不要硬搜先确认 SDK 有没有统一的设备信息配置头文件。常见做法是在 board_config.h 或 sys_config.h 里定义不同 demo 放的位置不一样但 grep 一定能定位到。# 第一步在工程里搜索蓝牙名称相关的宏定义 grep -rn DEVICE_NAME\|BT_NAME apps/demo/bt_music/ | head -20 # 第二步假设命中了 board_config.h用 sed 直接替换名称 sed -i s/AC695N_BT_NAME/MySmartSpeaker/g apps/demo/bt_music/board_config.h # 第三步清理后重新编译避免头部缓存干扰 make clean ./build.sh -j8逻辑说明grep 的作用是找到名称定义的准确位置这是最稳妥的做法。不同 demo 的命名可能不同有些叫 DEV_NAME有些直接一行字符串。sed 命令把原始的蓝牙名称替换成你的产品名注意要确认 Shell 的引号不会吞掉特殊字符。最后是 make clean 再编译这一步不能省因为头文件有缓存同名配置改了之后不完全重编很容易出现固件里还是旧名称的情况。参数说明sed 命令里 s 表示替换g 表示全局替换。不要贪方便直接在源码里手改一个引号字符串如果你把名称定义在设备信息结构体里手改容易漏掉另一处引用。grep 定位后改宏只动一处全局生效。这一套流程走完固件里的提示音和新蓝牙名称基本就稳定了。改完后重新烧录手机搜索、开机播报都要做一轮回归。5. AC695N 开发避坑五条实测踩坑记录与处理流程这一章是开发包使用过程中最容易让人耗时间的地方。下面五条都是我自己在类似 SDK 上遇到过的、而且经常在社区里反复被问起的问题。每条按“现象 → 原因 → 解决”展开读者可以直接当排查手册用。5.1 编译报错工具链提示 No such file or directory现象Ubuntu 64 位系统下执行 build.sh工具链明明存在于 toolchain 目录里却提示 “No such file or directory”而且没有任何缺包提示编译直接中止。 原因这个报错非常具有迷惑性。交叉编译工具链的二进制文件可能是 32 位格式而系统缺少 32 位运行库Linux 执行它时就会给出这个让人摸不着头脑的错误。问题不一定在于文件本身存在与否而在于运行环境不满足。 解决按第 3 章的方法安装 i386 运行库然后重新执行编译。如果还不行用 file 命令检查工具链二进制格式确认是不是 32 位 ELF。也可以直接在 Ubuntu 上保留一个旧版本 LTS 系统作为编译专用环境这是最省事的方式。5.2 USB 烧录工具识别不到芯片现象开发板连接 USB 后杰理烧录工具一直显示“找不到设备”换线、换 USB 口都无效。 原因多数情况下这不是线材问题而是芯片没有进入烧录模式。AC695N 这类芯片通常需要在上电时序上做特殊处理比如按住某个按键再插 USB、或者先按住烧录键再供电。直接插上 USB 或板子已经在正常运行是不会进入烧录状态的。 解决查阅所购模块的原理图或 SDK 文档里的烧录说明确认进入烧录模式的条件。常见方式是按住 BOOT 或某个 GPIO 控制的按键然后插 USB等待烧录工具出现设备后再放开。进烧录模式后设备管理器里一般会出现一个新的串口或 HID 设备看到这个变化就说明芯片已经在等固件了。5.3 固件能跑但手机搜不到设备现象固件编译烧录都顺利板子似乎也正常运行但手机蓝牙扫描始终看不到设备名称。 原因这类问题有两个高发点。一是芯片外接晶振频率和 SDK 内部默认配置不一致比如板上用的是 26MHz 晶振而固件按 24MHz 配置导致射频工作异常蓝牙无法正常广播。二是产品的 BR/EDR 广播功能没有开启只开了 BLE或者反过来手机扫描到的类型不对。 解决先核对板子的晶振规格在 SDK 的 board_config 或 clock 配置里改成一致数值。然后确认固件里蓝牙双模的开关状态。不要在这时候改代码逻辑先把射频和协议开关排干净再检查地址是否随机或可发现。5.4 GPIO 控制不受控器件不动作或乱跳现象代码里明明配置了某个 GPIO 去控制功放使能脚但功放不工作或者 GPIO 输出电平不稳定导致电流异常。 原因这类问题的本质是复用冲突。AC695N 的引脚大多是复用引脚同一个引脚可能同时连接充电检测、按键扫描、音频通路或者调试串口。SDK 默认的板级配置可能已经把这个引脚的复用功能切换成了别的用途而你只是按引脚编号操作没有修改复用表。 解决在 platform 或 board_config 中找到引脚复用配置把目标引脚切到普通 GPIO 模式同时检查是否有给这个引脚接了内部上下拉。GPIO 控制功放这类应用建议把默认状态设为关闭等系统启动完成后再拉高避免上电瞬间误触发。5.5 改了配置却不生效固件行为还是旧版本现象修改提示音或按键逻辑后重新编译烧录开发板的行为没有变化好像改动完全没有编译进去。 原因百分之七十的可能是工程没有彻底 clean构建系统里的目标文件还是旧的。还有一部分原因是源代码里有多处配置你改的那一处根本不是实际生效的那一处比如同一项配置在 sys_config.h 和板级头文件里各有一份。 解决先养成强制 make clean 再编译的操作习惯。再使用 grep 搜索同一个配置名在工程里的出现位置确认没有重复定义或者确认覆盖关系。不要只看 demo 目录必要时全局搜一次。6. 收尾日志定位与一键编译烧录脚本开发包用熟了之后手动的重复操作会成为最大的时间黑洞。这个阶段我一般会把编译、打包和烧录串成一条指令同时把 SDK 的日志导出和地址回溯工具用起来。下面两个手段对日常开发和量产维护都很有用。6.1 把编译与烧录串成一条命令#!/usr/bin/env bash set -e PROJbt_music make clean ./build.sh -j$(nproc) mkdir -p artifacts cp out/${PROJ}.bin artifacts/${PROJ}_$(date %Y%m%d).bin bash tool/flash_tool_x64.sh -p /dev/ttyUSB0 -f artifacts/${PROJ}_$(date %Y%m%d).bin逻辑说明脚本开头 set -e 让任何一步失败时立即停止避免烧录了旧固件还不自知。make clean 和 build.sh 保证每次都是新固件。文件名加日期固件版本可追溯。 参数说明$(nproc) 是当前 CPU 核数可自动决定并行数。烧录时 -p 指定串口设备如果你的板子通过 USB 枚举成别的节点要按实际环境修改这个路径。这套流程建议在上板前先确认好烧录口的对应关系否则脚本执行到烧录步骤时会卡住。6.2 用 addr2line 把崩溃地址还原成函数SDK 的日志输出里出现异常调用栈时比如打印一个地址 0x00215A3C这串数字在十六进制编辑器里毫无意义但可以通过 addr2line 还原成具体函数这是在类似 SDK 上定位崩溃问题最常用的一招。# 以 RISC-V 工具链为例实际前缀以 SDK toolchain 目录为准 toolchain/riscv32-unknown-elf/bin/riscv32-unknown-elf-addr2line \ -e out/bt_music.elf -f -C 0x00215A3C逻辑说明-e 指定带调试信息的 .elf 文件-f 输出函数名-C 自动去掉 C 编译器的名字修饰。最终会把一个地址映射到具体的源码函数与行号。 参数说明如果 SDK 工具链是 ARM 内核把命令替换为对应的 arm-none-eabi-addr2line 或 arm-linux-gnueabi-addr2line。日志里出现多个地址时按从后往前的顺序逐个还原一般能拼出完整的调用路径。有次交付前客户反馈板子不出声查了半天才发现是固件缓存版本和源码不一致。从那以后我每次在改完配置后都强制走一遍 make clean、编译、确认固件时间戳再进烧录流程。这个习惯救过我很多次希望帮到你。本文还有配套的精品资源点击获取
