很多人拿到一块新开发板，第一反应都是先插USB、找资料、装IDE。我拿到AC6966B开发板的时候也差不多，但实际走了一遍才发现，这套AC696N开发环境并不是一个安装包能搞定的，它由固件工程、编译工具链、下载工具和调试串口四部分拼装而成，任何一环没对上，后面都会以各种奇怪的方式卡住。这篇内容就是写给第一次在Windows下接触杰理AC696N系列芯片的同学，我把自己从零搭环境的完整过程、选型思路和踩过的坑整理出来，希望能让你少走弯路。
1. 先把这套环境的四件套在脑子里串起来
1.1 四条线的分工与交付物
熟悉STM32或者Arduino的同学，一开始会不太适应AC696N这种国产音频芯片的开发方式。它没有一个“一站式IDE”，而是把开发链路拆成了相对独立的四段：
| 环节 | 承担的工作 | 你面对的对象 | 最容易卡住的地方 |
|---|---|---|---|
| 固件工程 | 芯片启动、外设驱动、业务逻辑 | SDK源码包里的sdk/app/project目录 | 不知道改哪个目录，改了没效果 |
| 编译工具链 | 把源码编译成可烧录的固件 | Keil工程或原厂命令行工具链 | 编译器版本不匹配、头文件路径缺失 |
| 下载工具 | 把固件写入板载Flash | JL专用下载工具 | USB驱动没装好，工具识别不到设备 |
| 串口日志 | 观察运行状态和打印信息 | 任意串口助手 | 设备管理器没有COM口、波特率不对 |
这四条线不是孤立的。编译不出来，后面烧录无从谈起；烧录工具连不上设备，编译出再好的固件也上不了板；串口日志不通，跑起来出了问题你也只能靠猜。所以搭建环境这个阶段，做的其实是把这条链路的每一段都提前打通，而不是“装个软件”这么简单。
1.2 为什么原厂不做一个傻瓜式IDE
先说清楚原因，后面遇到问题就不慌。AC696N的方案SDK主要面向方案商和有一定经验的嵌入式工程师，原厂的交付逻辑是“给源码+给工具链+给说明文档”，而不是“给你一个一键完成所有事情的开发环境”。这种做法有好有坏。
好处是灵活，你可以用Keil看代码、改逻辑，也可以用命令行工具链做批量编译，适合后面量产和CI流程。坏处就是第一次接触的人容易懵：为什么我装好了Keil还是编译不过？为什么烧录工具里看不到设备？原因往往不是某一个软件坏了，而是几个工具之间的版本、路径、驱动没有对齐。把四件套的关系在脑子里串成一条线，是这套环境能跑通的前提。
2. 安装前的版本选型：这些坑是我装完才想明白的
2.1 Keil版本为什么不能乱装
我最初的直觉是装最新的Keil版本总没错，但打开SDK包里的开发文档后发现，原厂对编译器的版本有明确要求。这不是原厂保守，而是因为SDK里大量底层代码、链接脚本、预编译库和编译器之间有绑定关系。
举个例子，旧版编译器对结构体对齐、位域处理、未初始化全局变量的默认行为，跟新版编译器存在差异。这些差异在几百行的小工程里看不出来，放到AC696N这种带着蓝牙协议栈、音频DSP代码的完整SDK里，就可能变成“编译能过但运行崩溃”或“链接时地址重叠”这种棘手问题。所以版本选型的唯一标准，就是看你手里SDK文档里写的是哪个版本，老老实实装那个版本。不同批次的SDK可能对应不同版本，以你自己那份文档为准。
2.2 串口驱动、下载工具和辅助环境怎么选
除了Keil，还有几样东西要在动手前确认好。
- USB转串口驱动：AC6966B开发板一般板载了USB转串口芯片，常见的是CH340或者CP2102系列。先看板子丝印或者原理图，确定是哪一颗，再去装对应驱动。驱动装好后，设备管理器里会出现一个新的COM口。如果插上板子完全没有新设备出现，先查USB线是不是只能充电不能传数据——这种线在开发中害人无数。
- JL专用下载工具：这个工具通常随SDK的tools目录一起提供，不要在网上随便找一个“通用版”下载工具来用，型号不匹配时要么完全认不到设备，要么烧进去起不来。
- Python环境：有些SDK会附带日志解析、固件打包、批量配置生成的脚本，脚本一般用Python写，需要时按文档要求装一个对应版本即可。不需要的时候可以不装，别一上来就装一堆东西。
这一阶段的选型原则其实就一句话：能少装就少装，SDK文档没让你装的东西，后面用到再补也来得及。
3. 一步步装好Keil、串口驱动与JL工具链
3.1 按这个顺序装，基本不会乱
安装顺序看着是小问题，但顺序不对会浪费不少时间。我建议按下面的顺序走，每一步都验证完再进行下一步。
- 安装USB转串口驱动。装完插上开发板，打开设备管理器，确认能枚举出COM口。这一步不通过，后面的烧录工具和串口日志全都没戏。
- 安装SDK文档指定的Keil版本。安装时目录保持默认即可，组件按默认勾选，不需要额外装一堆Pack，因为AC696N工程一般走原厂工具链路线，不依赖Keil内置的芯片Device数据库。
- 配置原厂工具链。如果SDK是搭配Keil使用的，打开工程后会在编译选项里看到编译器路径，指向原厂工具链目录。如果SDK提供的是命令行编译脚本，则需要把工具链根目录按文档要求配置到系统环境变量里。
- 解压SDK源码包。重点来了——一定要放到纯英文、没有空格、没有中文的路径下，比如D:\work\AC696N_SDK，不要放桌面，不要放带空格的文件夹。很多编译脚本底层是批处理或者Makefile，路径带空格会出现“找不到文件”这种莫名其妙的问题。
- 打开烧录工具，确认它能识别到设备。这个时候先不烧录，只要工具界面里能枚举出设备、能读到芯片型号，就说明驱动和硬件链路是通的。
这一步做完，环境的“骨架”已经立起来了。
3.2 环境变量与杀毒白名单这两个细节别忽略
命令行工具链不像Keil那样装完就能用，它需要知道去哪找你解压的SDK和工具链。有些SDK会在编译脚本里固定读取某个环境变量，比如SDK_ROOT或者JLC_TOOLCHAIN这样的名字，具体以你手里脚本为准。操作方法是在系统环境变量里新建一个变量，把对应路径填进去，然后重新打开命令行窗口或者重启Keil，让环境变量生效。
另一个容易被忽略的是杀毒软件。
原厂的工具链第一次运行时要读写USB设备、生成bin文件，行为比较像“戴手套操作硬件”，很容易被杀毒软件拦下来，表现就是烧录工具闪退、编译脚本跑到一半被kill。我当时的处理方法是把SDK目录、工具链目录加入杀毒软件的白名单，再重新跑一次编译。这个问题在Windows Defender策略比较严格的环境下出现频率很高，提前加白名单能省很多事。
4. SDK目录拆解：拿到包后先认清这五个目录
4.1 这份SDK的目录大致长这样
AC696N的SDK包解压后，目录结构一般来说会有下面这些部分。不同发布批次会有差异，但总体思路是接近的。
AC696N_SDK/ ├─ doc/ # 芯片手册、开发指南、版本说明 ├─ tools/ # 下载工具、日志工具、辅助脚本 ├─ sdk/ # 源码主体 │ ├─ include/ # 全局头文件 │ ├─ src/ # 核心源码 │ │ ├─ driver/ # 芯片外设驱动：GPIO、I2C、PWM、ADC等 │ │ ├─ system/ # 系统启动、时钟配置、电源管理 │ │ └─ ble/ # 蓝牙协议栈的封装接口（多为预编译库） ├─ app/ # 应用层代码，相当于整个工程的业务大厅 └─ project/ # Keil工程文件、编译入口、输出目录每个目录都有明确的职责，不要一上来全翻一遍。先看doc，再看tools，然后打开project，别的先放着。
4.2 哪些目录你会经常动，哪些目录尽量别碰
这部分的经验值很高。很多人拿到SDK以后，光找“入口”就花了不少时间，找到以后又喜欢往下钻底层代码，结果越看越晕。我给一个相对实用的分工清单：
| 目录 | 职责 | 你的操作频率 | 建议 |
|---|---|---|---|
| doc | 文档和版本说明 | 偶尔看 | 先读版本说明，确定SDK支持的功能范围 |
| tools | 下载工具、工具脚本 | 每次烧录都会用 | 只认准这个目录里的工具，不要外找 |
| sdk/src/driver | 外设驱动 | 需要改外设时看 | 了解接口即可，别轻易改底层实现 |
| sdk/src/ble | 蓝牙协议栈封装 | 基本不动 | 它是预编译的库，你改了源码也不生效 |
| app | 应用层业务逻辑 | 最常改 | 第一次做验证性改动，从这里入手 |
第一次接触，建议只改app层的东西，比如把某个LED闪烁的延时从500ms改成1000ms，然后编译、烧录、看现象。这个改动足够简单，又能覆盖“改代码-编译-烧录-验证”的全流程。只有把这条闭环跑通了，后面改复杂功能时才不会把“环境问题”和“逻辑问题”混在一起。
5. 打开Keil工程到第一次编译通过的完整过程
5.1 打开工程后的三个典型问题
用Keil打开project目录里的uvprojx文件后，不推荐直接点Rebuild，先检查三处配置，能避免很多让人摸不着头脑的报错。
第一是芯片和工具链的关联方式。AC696N工程通常不需要你在Keil的Device列表里选择具体型号，工程文件里已经写好了原厂工具链的调用方式。如果你打开工程后发现编译器选项是灰色的，或者编译时提示找不到设备，检查一下是否装了SDK要求的工具链版本。没装对版本的话，工程根本加载不到正确的编译器核心。
第二是头文件路径。原厂工程的Include Paths一般在工程配置里已经填好了，但如果你把SDK解压到了不同路径，或者自己新建了源码目录，就需要手动把路径加回来。点击魔术棒，在C/C++选项卡里的Include Paths中加入：
..\sdk\include ..\sdk\src\driver ..\sdk\src\system ..\app这里用的是相对路径，基准是uvprojx文件所在目录。如果还缺其他头文件，编译时它会明确告诉你找不到哪个.h，按提示往上一层层补齐即可。
第三是预定义宏。工程里通常会有几个全局宏，比如选择芯片型号、选择板级配置、选择demo功能用的。不要随便删，也不要自己加，保持原样就好。改动这些宏可能导致编译出来的固件跟你的板子不匹配，属于“高级操作”，后面调试时再学不迟。
5.2 第一次编译的产物与基线
配置没问题后，先点Clean，再点Rebuild，然后盯着编译输出窗口。第一次编译会明显偏慢，因为除了编译你自己的源码，还要链接盲区的预编译库，并生成整个工程的map文件。看到“0 Error(s), 0 Warning(s)”之类的结果时，恭喜，你的环境已经基本通了。
编译产物一般是hex或bin文件，输出位置通常在project目录下的output或build子目录里，具体看工程配置里的Output选项卡设置。我建议你把第一次编译通过时的工程配置、头文件路径、宏定义列表截个图存下来，把它当作基线。以后每次改动只动一处，编译出问题就对比基线来找差异，这个方法在调试阶段非常高效。
第一次编译时如果遇到报错，把报错信息里第一个文件的路径拿出来跟你的实际目录结构对一下，95%以上都是头文件路径没配对导致的。
6. 烧录验证与首次上电日志排查
6.1 烧录工具的使用与供电问题
编译出固件之后，别急着点烧录。先确认开发板的供电方式。AC6966B这类带音频功放的板子，如果用USB口直接供电，插入的瞬间电流可能不够，导致烧录工具连到一半设备掉线，或者烧录过程中校验失败。我的习惯是：如果板子上有独立的电源接口，就外接电源；没有独立电源接口再用USB供电，同时找一根尽量短、质量好的USB线。
打开SDK tools目录里的JL下载工具，选择对应的芯片型号，加载刚才编译出的固件文件，然后连接开发板。工具能读到设备后，点烧录。烧录完成后，板子自动复位运行新固件。
如果烧录工具一直报“未找到设备”，优先排查三件事：USB线是否只能供电、驱动是否真的装好、芯片是否处于异常状态。很多时候不是工具问题，而是最基础的硬件链路没打通。
我整理了一份常见烧录报错的对照表，适合贴在工位旁边：
| 现象 | 常见原因 | 处理方式 |
|---|---|---|
| 工具完全找不到设备 | USB线不通/驱动没装 | 换线、重装驱动 |
| 烧录中途断开 | 供电不足 | 外接电源，或换短粗的USB线 |
| 烧录成功但上电没反应 | 固件型号与板子不匹配 | 核对工程里的芯片型号宏 |
| 校验失败 | Flash保护位开启 | 查SDK文档关闭保护，或先擦除再烧录 |
6.2 首次上电应该看到什么
烧录成功后，把开发板重新上电。如果烧进的是默认的蓝牙音箱demo固件，正常现象一般是这样：板上某个LED亮起或闪烁，喇叭传出一段上电提示音，然后手机蓝牙列表里会出现一个以SDK默认名称开头的设备。
如果这些现象一个都没有，别慌，先用串口日志确认芯片是否真的在运行。
6.3 串口日志排查方法
打开设备管理器，找到板子对应的COM口号。然后用任意串口助手打开这个COM口，波特率以SDK文档为准，常见的有921600和115200两类，不同板子可能不同。打开后按一下板子复位键，正常情况下会看到从芯片启动到系统初始化的打印信息逐行刷出来。这个日志是从上电到进入主循环的完整过程，能看到它，就说明芯片在跑，烧录也成功了。
如果串口没有任何输出，通常就三个原因：TX和RX接反了、波特率不对、或者你打开的COM口并不是调试串口而是下载口。逐项排查即可。
到这里，整个环境闭环就完整了。我在实际项目中一直沿用“电源指示灯亮、枚举出COM口、日志有启动打印、烧录工具能识别设备”这四个检查点来判断一套板子环境是否可用，缺哪一个就单独排查哪一段，从来不用从头再猜一遍。这套方法在AC696N上适用，换到其他类似的国产芯片方案上，同样能帮你快速定位问题。
