杰理AW33N四型号选型：BLE 6.0、低功耗与资源评估

杰理 AW33N 这条线上挂着的四个型号——AW338A、AW332A、AW333A、AW336A——加上"支持 BLE 6.0"这个宣传点，是我最近半年被问得最多的选型问题。问的人背景差别很大，有刚拿到开发板的学生，也有已经在出第二版板子的硬件负责人，但卡住他们的点惊人地一致：这四个后缀到底差在哪，以及"BLE 6.0"这件事对项目有没有实际影响。

我第一次做这类选型的时候，走的是最笨的路——把四份数据手册打印出来，逐页用荧光笔标差异，标了两个小时发现真正有用的信息散落在三四个章节里，而且有些关键项（比如协议栈缓冲区的默认配置）手册里根本没写。后来才明白，这类同平台多料号的选型，重点不在背参数，而在搞清楚三件事：平台级的共性是什么，料号级的差异维度有哪几个，以及你的项目在哪几个维度上是有硬约束的。把这三件事想通，选型表的答案基本就自己浮出来了。

下面我按自己实际做项目的顺序，把 AW33N 平台、四个料号的差异拆解、需求到指标的换算方法、场景映射，以及踩过的坑全部写出来。内容以方法论为主，具体参数请以官方最新数据手册和代理给的选型表为准，因为这一行的手册版本更新频率比很多人想象的要高。

1. AW33N 先当成一个平台名，四个料号是它的变体

1.1 杰理的 AC 系列和 AW 系列解决的不是同一类问题

杰理的产品线上，AC 系列和 AW 系列经常被放在一张对比表里，但它们的定位其实差得挺远。AC 系列（比如常见的 AC69xx、AC70xx 这一路）是蓝牙音频 SoC，设计重心在音频通路、DSP 算力和编解码，典型产品是 TWS 耳机、便携音箱、车载音频模块。AW 系列（AW31N、AW32N、AW33N 这一路）则是通用低功耗 BLE SoC，重心在低功耗、外设集成度和可编程性，主打的是遥控器、穿戴、传感器节点、智能家居外设这类场景。

把这两个系列混着看，最容易出两个方向的错。一个是拿 AC 系列的单价去套 AW 系列成本，算出来的 BOM 跟实际差一截，因为两者的晶圆面积和封装策略不一样；另一个方向更麻烦，是想让 AW 系列直接跑音频编解码，结果发现 DSP 资源和音频外设都对不上，只能加一颗独立 Codec，成本和板子复杂度都上去了。

所以选型第一步不是看 AW338A 和 AW332A 谁强，而是先确认你的产品落在哪条线上。如果需求里有明确的音频播放、麦克风阵列、主动降噪这类东西，那问题就不该在 AW33N 内部解决；反过来，如果核心需求是低功耗长待机加一堆传感器接口，那 AC 系列就是杀鸡用牛刀。

1.2 后缀字母数字编码了哪些信息

平台名之后的后缀，一般会编码这么几类信息：封装形式和引脚数、Flash 容量档位、RAM 档位、外设集的裁剪情况，偶尔还有温度等级或者特定用途的标记。AW33N 是平台代号，说明这几颗芯片共享同一套内核、同一套协议栈基础、同一套 SDK 框架；AW338A、AW332A、AW333A、AW336A 是具体的料号，差异体现在上面那几类信息上。

这里有个坑要提前说：后缀的编码规则并不是所有厂商都统一，杰理也没有对外公开一份"后缀字典"。所以不要试图从数字大小去推断谁更强。我见过有人默认"AW338A 数字最大所以最强"，结果拿到手册发现它在某个维度上反而是最小的，当场推翻选型结论。正确的做法是拿到对应料号的官方数据手册，把四个数拉齐：Flash 可用用户区、RAM 大小、封装引脚数和可复用 GPIO 数、外设清单（ADC 通道、PWM、I2C/SPI/UART 数量）。这四个数拉齐之后，差异基本就清晰了。

还有一点，SDK 是按平台分的，不是按料号分的。也就是说你下载的 SDK 大概率是"AW33N 系列 SDK"，里面通过宏定义或者配置文件来适配具体料号。这就意味着在项目早期用哪颗芯片点灯，对软件开发的影响没有想象中那么大，反而是硬件选型（封装、引脚、外设）更难改。这个认知能帮你在选型节奏上省不少时间——软件可以先跑起来，硬件定死之前多留几天验证窗口。

1.3 "支持 BLE 6.0"这句话拆成三层才看得清

蓝牙核心规范的版本号，和芯片实际能提供的能力，中间隔着好几层。看到"支持 BLE 6.0"，我一般会拆成三层去问：

第一层，控制器（Controller）声明的核心规范版本。这是最表层的，改一行版本号配置就能变，参考价值有限。

第二层，控制器实际实现并上报的特性集（Link Layer Feature Set）。版本号是版本号，特性集是特性集，两者不是一回事。一颗芯片可以声明自己符合 6.0，但只实现了其中一部分特性，剩下的标为不支持。

第三层，协议栈（Host）和 SDK 有没有把这些特性对应的接口暴露出来给你用。这是对你项目真正有意义的那一层。

拿蓝牙 6.0 里最受关注的几项来说，信道探测（Channel Sounding）用于安全测距，是数字钥匙、防丢器这类产品的关键；基于决策的广播过滤和广播者监控，对密集广播环境下的功耗和抗干扰有帮助；ISOAL 增强和链路层扩展特性集，则关系到等时通道和长包传输的效率。这些特性对普通 BLE 外设项目来说可能一辈子都用不上，但对特定品类就是决定性的。

所以选型初期就要明确：你的产品有没有把某个 6.0 特性写进必须实现的功能清单。如果没有，那"支持 6.0"这件事就当成加分项，别为它付溢价；如果有，就必须让原厂或代理书面确认这一层的接口可用性，最好是能提供 demo 或者测试固件。

2. 四个料号的差异，收敛在六个维度上

不管手册怎么写，实际会卡住项目的差异维度就那么几个。我整理成一张表，后面逐条展开。

2.1 Flash 容量：最先卡人的那一项

协议栈本身要占一块，OTA 双区备份要占一块，应用代码要占一块，如果产品带屏还要留字库和图标资源。很多人算 Flash 的时候只算了应用代码，等到做 OTA 的时候发现要双区，容量直接不够。

我的习惯是先给一个保守估算：协议栈加基础外设驱动按手册建议的预留量算，OTA 双区按应用固件体积的两倍留，字库按实际字数的 1.5 倍留（因为点阵数据压缩率不稳定）。三项加起来再乘 1.2 的安全系数，得到的数如果超过可用用户区，就直接往上一档选，别犹豫。压缩字体、裁剪功能这类优化留到后面做，选型阶段不要把未来寄托在"我一定能优化下来"上。

2.2 RAM 是被低估得最厉害的一项

BLE 协议栈的缓冲区分配跟连接数、MTU 大小、广播数据量直接相关。单个连接在默认 MTU 下占的缓冲不算多，但如果你要做多连接，或者把 MTU 拉到比较大的值，RAM 消耗是成倍上去的。而且这部分消耗是在协议栈内部，你从应用层不一定看得见，表现就是"代码没写多少，编译链接的时候 RAM 就满了"。

选型时值得问清楚的一个细节：手册标的 SRAM 有多少是可自由分配的，有多少被协议栈固定占用。有些料号标的总数不小，但固定占用扣掉之后剩不了多少。这个问题代理不一定答得上来，最好直接找原厂 FAE 或者看 SDK 里的链接脚本和内存映射文件，那是最真实的。

2.3 封装和 GPIO 是改板成本的隐形来源

封装决定了引脚数，引脚数决定了你能同时挂多少外设。一个常见的翻车场景是：软件功能都验证完了，硬件画板的时候发现 GPIO 不够，要么加 IO 扩展芯片（增加成本和一个 I2C 从设备），要么换料号（PCB 重画，认证可能要重做）。

我的做法是在选型阶段就把引脚分配表画出来，列清楚每个功能需要几个引脚、哪些必须支持复用功能（比如特定的 ADC 通道、硬件 I2C 引脚）。画完之后如果剩余引脚少于总数的一到两成，就往上一档选。留余量这件事在硬件上比在软件上难补救得多。

2.4 外设集决定外围 BOM 的复杂度

ADC 通道数、PWM 路数、串口数量、定时器数量，这些直接影响外围器件的选择。比如你要做三路 PWM 调光加两路 ADC 采样，选到只有两路 PWM 的料号，就只能上 IO 扩展或者软件模拟，软件模拟 PWM 会挤占低功耗模式的时间窗口，最终影响续航。这类取舍在原理图评审的时候很显眼，但在选型阶段很容易被跳过。

2.5 射频能力：连接角色和数量上限

BLE 的连接数上限、能同时扮演的角色（广播者、扫描者、中心设备、外围设备）、发射功率档位，这些在协议栈层面有硬限制。多连接产品（比如一个网关连多个节点）对这项特别敏感。选型时别只看"支持 BLE"，要确认具体的连接数上限，而且要问清楚这个上限是在什么 MTU、什么连接参数下的值。

2.6 低功耗模式：纸面参数和实测之间的差距

深睡电流、唤醒时间、可用的唤醒源，这三项决定了产品的实际续航和响应速度。手册给的是典型值，实际做出来往往会高一些，原因在后面的踩坑部分细说。选型时我会要求一个"最坏情况"的估算，把所有 GPIO 按悬空处理、所有外设默认开启，看看还能不能达标。

3. 把需求翻译成数字，选型表自己会说话

3.1 功能清单到资源预算的三步换算

第一步，把功能拆成"功能点"而不是"产品描述"。比如说"做一个智能温湿度计"，这句话不能用来选型。拆开是：BLE 广播加连接、一路 I2C 接温湿度传感器、一路 ADC 接电池电压检测、一个按键、一个 LED 指示、可能还有一段 OTA。这样拆完，你能直接数出外设需求和 Flash/RAM 的大致量级。

第二步，给每个功能点标上"必须"和"可选"。必须项决定下限，可选项决定要不要往上加档。我在这一步的经验是，把"以后可能要加"的东西全部归到可选项，绝不因为"万一要加"就让必须项升级。做过项目的人都知道，"以后可能要加"的功能实现率有多低，而为一个假设的扩展多花的钱是实打实的。

第三步，按必须项画一张最小可行配置表，然后逐个料号去套。套不上的直接淘汰，套得上的比较价格、封装、供货情况。这个方法听起来笨，但比"凭感觉选一个然后边做边改"要省太多时间。

3.2 功耗预算的算法和一个具体例子

BLE 产品的续航估算有个简单公式：电池容量（mAh）除以平均电流（mA），得到小时数。难点在平均电流。平均电流 = 广播或连接状态的电流 × 占空比 + 休眠电流 × (1 - 占空比) + 其他常开电路（LDO 静态电流、传感器待机电流）之和。

举个例子。一颗纽扣电池容量按 220mAh 算，要求续航两年，折算下来平均电流要压到大约 12.5 微安（220mAh / (2 × 8760h) ≈ 0.0126mA）。这个数字意味着什么？意味着主控的休眠电流必须在个位数微安级别，广播间隔不能太密，而且外部电路的静态电流必须精打细算。很多项目算到这一步才发现，光是一个上拉电阻在待机时持续耗的那几微安，就把预算吃掉一大块。

还要注意，电池的自放电在大电流场景下可以忽略，但在微安级场景下必须算进去。某些纽扣电池的年自放电率在百分之一到百分之几之间，两年下来损失的量不能忽略。选型阶段把这个算进去，后面就不会出现"实测续航只有理论值一半"的尴尬。

3.3 认证和协议栈版本要求别放到最后才想

如果产品要出海，蓝牙认证、无线电型号核准、电磁兼容这几项是绕不过去的。这些认证通常在模组或者芯片层面有已完成的测试报告可以复用，但前提是你用的料号和参考设计一致。如果中间为了省成本换了料号或者改了射频匹配电路，认证可能要从头做。

协议栈版本的要求也一样。有些客户或者平台方会指定蓝牙核心规范的版本，或者指定必须支持某个 BLE Profile 的特定版本。这些要求要在选型表里变成一行硬指标，而不是等到送测的时候才发现不支持。

3.4 做一次"最坏情况"反向验证

前面都是正向推算，最后建议做一次反向验证：假设所有对你不利的情况同时发生——Flash 用满、连接数跑上限、休眠电流取手册最大值、电池按最低容量算——你的产品还能不能达到最低可接受的功能和续航。如果还能过，说明余量足够；如果过不了，就要回到选型表重新看是哪一项卡住。

这一步做起来花不了多少时间，但能避免很多后期的返工。我见过一个项目，正向算一切正常，反向一算发现如果两路传感器同时工作，休眠电流就超标了，最后是调整采样周期解决的，比换芯片便宜得多。

4. 落到具体品类：四个料号各自适合的落点

4.1 单键遥控和无线外设类

这类产品的特点很明确：功能单一、极致低功耗、成本敏感、基本不需要显示屏。一颗按键加一个 BLE 广播，按键唤醒后发一次广播然后立刻回到深睡。这种场景对 Flash 和 RAM 的要求都很低，对外设的要求就是一个 GPIO 中断加一个定时器。

按常见的产品分档习惯，AW332A 这类命名落在偏小资源位置上的料号，在这种场景里往往性价比更高，因为用不到的东西不需要为它付钱（具体配置仍需以官方手册核实）。但有个前提要确认：它支持的广播间隔范围能不能满足你的响应速度要求。如果客户要求按下去一百毫秒内手机有反应，那广播间隔就不能设得太长，这就会拉高平均电流，往回推可能又要更大的电池或者不同的电池规格。这几个参数是互相咬合的，改一个动全身。

4.2 带屏穿戴和健康监测类

带屏的产品对 Flash 的要求会突然上一个台阶。屏幕驱动、字库、图标、可能的动画帧，这些资源是实打实的字节数。同时这类产品往往要同时跑多个 BLE 连接（手机加可能的体脂秤、心率带），RAM 需求也跟着上去。

另外还有一项容易被忽略：带屏产品的平均电流里，屏幕背光往往是大头，主控的低功耗优势会被背光吃掉。所以在这类产品上，主控选型的功耗差异对整体续航的影响，没有遥控器类产品那么显著，反而 Flash 容量和连接数上限更重要。这也是为什么我不建议在所有品类上用同一套选型权重。

健康监测类还要考虑 ADC 的精度和通道数。连续采样的传感器（比如光电容积脉搏波这类）对 ADC 采样率和 DMA 的支持有要求，选型时要确认这几项，不能只看"有几路 ADC"这个总数。

4.3 需要多连接或者组网的场景

一个网关连多个节点，或者一个 App 同时管理多台设备，这类场景对连接数上限和协议栈的调度能力很敏感。BLE 的连接多路复用是分时处理的，连接数越多，每个连接的可用时隙越少，实际吞吐和响应都会下降。选型时不能只看"支持多少个连接"这个数字，要看在那个连接数下每个连接的连接间隔能做到多少。

如果是 Mesh 或者类似的组网方案，Flash 需求会明显增加，因为要存网络密钥、节点信息、转发缓存。这类场景建议直接往资源充裕的料号上选，别在小配置上省，后期改起来很痛苦。

4.4 测距类应用：数字钥匙和防丢器

这类应用是蓝牙 6.0 新特性最直接的受益场景。安全测距依赖信道探测，而信道探测对射频的要求和普通 BLE 不一样：它需要在多个信道上做往返测量并计算相位差，对时钟精度和射频一致性有额外要求。所以如果你的产品规划里有测距功能，选型时第一件事就是确认这颗料号的控制器和协议栈是否支持信道探测，第二件事是确认有没有可用的参考设计或者评估套件。

没有参考设计的测距功能不要轻易自己从零调，射频这块的调试周期比软件长得多，而且测量误差的来源很分散，没有基准设备很难定位问题在哪。

5. 我踩过的坑：从选型到点灯的完整排查链路

5.1 手册标称和外设清单对不上

我最开始做 AW 系列相关项目的时候，遇到过手册里写的可用 GPIO 数量和开发板引出的数量对不上，差了三个。当时第一反应是自己数错了，把手册翻了两遍，又去数开发板丝印，还是差。最后搞明白是三个引脚被固定功能占用了（一个接晶振、一个调试口、一个电源检测），手册在总表格里算了进去，但在引脚功能表里单独标注了。这件事的教训是：拉引脚清单的时候一定要看引脚功能表那一页，不要拿总览页的总数做分配。

排查这类问题的方法很简单但很有效——画一张引脚分配表，每一行写引脚名、当前功能、是否能复用、复用成什么、备注。画完对着手册的引脚功能表逐行核。有疑问的地方先标红，不要自己想当然地补。

5.2 烧录完整片 Flash 之后 MAC 地址变了

这个问题我遇到过两次，表现是手机端看到的设备地址变了，之前配对过的设备连不上；更严重的一次是同一批板子里有两块 MAC 撞了，测试工装直接报错。

原因不复杂：芯片的 MAC 地址存在 Flash 的固定配置区或者 OTP 区里，如果烧录流程用的是整片擦除再写，配置区就被清掉了，芯片会用默认地址或者重新生成一个。解决思路有两条，一是烧录时保留配置区，很多烧录工具支持只擦用户区或者"下载时保留配置数据"这类选项；二是把 MAC 写入作为单独的工步，在产线测试里加一步 MAC 唯一性校验，从源头堵住撞地址。

这件事值得在选型阶段就确认：这颗料号的 MAC 存储位置在哪、出厂时是否已经写入、烧录工具是否支持保留。因为如果出厂没写入需要自己烧，那产线就要多一道工序，成本要算进去。

5.3 实测功耗比手册高一个数量级

这个坑几乎是每个做低功耗 BLE 的人都会踩的。我自己的排查顺序是这样：

先确认测量方法。用万用表串在电源上看平均电流，读数受采样率和量程影响，波动大的负载下读数会偏小或者偏大。更可靠的做法是用一个采样电阻配合示波器看压降波形，或者用专门的功耗分析工具。测量方法不对的话，后面的排查全是白费。

然后检查 GPIO。所有未使用的引脚要配置成确定状态（输出低或者输入带上下拉），悬空的输入引脚会因为输入级翻转持续耗电。这一项在中低功耗场景下能差出几十微安。

再检查外部电路。上拉电阻、分压电阻、LED 指示灯的限流电阻，这些在待机时都在持续耗电。一个 10k 的上拉接在 3V 上，就是 300 微安，直接把预算打穿。

接着检查外设。调试串口没关、调试口没断电、没用的外设时钟没关，这些都是常见的漏电点。

最后检查软件。广播间隔或者连接间隔是否被 SDK 的默认值覆盖了、有没有定时器在后台频繁唤醒、有没有任务在空转。我在一个项目里查了半天硬件，最后发现是 SDK 里一个默认开启的软件定时器每一百毫秒唤醒一次，关掉之后平均电流降了一半。

5.4 改了 Flash 分区之后设备再也连不上

有一次为了做 OTA，我调了 Flash 的分区表，把应用区和备份区的位置挪了一下，结果烧进去之后设备上电没反应，连广播都搜不到。当时以为是固件坏了，重新烧原版还是不行，最后发现是擦除不彻底，旧分区的残留数据干扰了引导流程。解决办法是整片擦除之后重新烧引导程序，再烧应用。

这件事的启示是：动分区表之前，先把当前的完整镜像备份出来，并且记录清楚烧录工具的擦除选项。另外，OTA 的双区设计一定要在选型阶段就算进 Flash 容量，不要等到开发后期才想起来，那时候改芯片就来不及了。

6. 拿到样片之后，建议按这个顺序验证

6.1 先把开发环境和烧录链路跑通

杰理的开发工具链迭代比较快，SDK 版本、编译器版本、烧录工具版本之间是有对应关系的。我见过用新编译器编旧 SDK 出现各种链接错误的情况，也见过烧录工具版本和芯片不匹配导致识别不到。所以拿到样片的第一件事不是写业务代码，而是把官方的示例工程原样编译一次、烧一次、跑起来。

工具链这块，社区里有不少折腾的经验分享，包括有人用单片微型控制器自己复刻离线烧录器这类做法。这些内容对理解烧录流程有帮助，但生产环境还是建议用官方工具，稳定性和售后都有保障。

6.2 然后验证射频和天线

射频这块，我建议的验证顺序是：先用接近参考设计的天线方案跑一次传导测试或者简单的通信距离测试，确认基础功能正常；再做拉距测试和不同姿态下的通信测试；最后如果要做认证，再上暗室。

天线匹配网络（通常是 π 型）的元件值不要照搬参考设计就完事，PCB 板材厚度、走线长度、周围是否有金属都会影响实际谐振点，最好留出可调元件的焊盘，实测之后微调。

6.3 第三步压功耗

功耗验证要在功能跑通之后做，因为功能没跑通的时候，你不知道哪些外设在正常工作、哪些是异常的。验证方法是让设备进入目标工作状态（比如广播状态、连接状态），用示波器看电流波形，把每个电流台阶和软件里的事件对应起来。对得上，说明你理解了自己的固件；对不上，就说明有隐藏的唤醒源或者外设没关。

6.4 最后压容量和边界条件

Flash 和 RAM 的容量要在功能全开的情况下看。具体做法是打开编译器的最优化配置，把 OTA 双区、字库、所有外设驱动都加上，看最后的占用。这一步如果超标，还有时间调整；等到快量产的时候才发现，代价就大了。

边界条件还包括：多连接同时工作的稳定性、低电压下的行为、温度范围边缘的表现、长时间运行的内存泄漏。这几项在样片阶段用不上太多设备，但能给后面的量产省很多事。

最后说点个人体会。选型这件事，看的资料越多反而越容易乱，因为不同来源的参数口径不一致，版本也不一致。我现在固定用一张自己维护的表格，只记录六项：Flash 可用区、RAM 可用量、封装配脚、关键外设数量、连接数上限、休眠电流实测值。每做一次选型就更新一次，几年下来这张表比任何一份手册都靠得住。另外，跟代理或者 FAE 沟通的时候，尽量要"实测数"而不是"手册值"，能要到评估板就先自己测一遍。手册上的休眠电流是硅片在理想条件下的表现，你的板子上还有稳压器、有上拉、有传感器，那些才是真正决定续航的东西。