企业官网建设流程全解析

简介：这是一份面向嵌入式语音应用开发者的杰理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 充电仓这类产品。它的核心资源可以按下表理解，这几项直接决定你的产品能不能落地。

这一层的结论是：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 libstdc++6:i386 libncurses5:i386 # 确认 32 位库是否生效 ldconfig -p | grep -E "libncurses.so.5" | head -5

逻辑说明：第一组命令的作用是添加 i386 架构源，并把 SDK 依赖的动态库补上。libc6:i386 和 libstdc++6: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 PROJ=bt_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、编译、确认固件时间戳，再进烧录流程。这个习惯救过我很多次，希望帮到你。

本文还有配套的精品资源，点击获取