Wi-Fi 低功耗

概述

IEEE 802.11 规范中定义的 Wi-Fi STA 省电模式包括以下关键特性：

• 在未发送或接收数据时，进入休眠状态。

• 定期唤醒以接收 AP 的 Beacon 帧。

• 利用 Beacon 中的 TIM（Traffic Indication Map， 流量指示映射）进行数据管理。

站点休眠期间无法接收任何数据帧，因此 AP 需缓存待传数据帧，STA 需周期性唤醒检测信标帧。

Wi-Fi 省电模式的时序图如下：

基于上述标准 IEEE 802.11 省电机制，Ameba 系列 SoC 提供了三种 Wi-Fi 省电模式：

模式	全称	描述
IPS	非活动省电模式	在未连接时实现完全断电状态
LPS	传统省电模式	在 Wi-Fi 连接状态下，在活跃和休眠状态之间切换，并定期打开或关闭收发器以实现省电
WoWLAN	无线局域网唤醒	允许 SoC 系统在保持 Wi-Fi 连接的同时进入睡眠模式 系统可通过单播数据包、广播/组播数据包（可选）以及 AP 断连事件被唤醒

非活动省电模式（IPS）

非活动省电模式（Inactive Power Save，IPS）专为 Wi-Fi 未连接状态所设计，允许在没有网络连接时进入睡眠的状态，从而显著的延长电池续航的时间。

IPS 一般有两种睡眠层级：

• Wi-Fi 完全断电，此时处于最大程度的 Wi-Fi 省电状态。

• 电源门控（Power Gating）模式，以求可以更快速的退出 IPS。

编程接口

Ameba Wi-Fi 通过 wifi_set_ips_internal() 函数及一组相关参数，来实现对 IPS 行为的控制。IPS 控制流程如下图所示：

RTL8721DxRTL8720ERTL8710ERTL8726ERTL8713ERTL8730ERTL8721FRTL8735C

RTL8721Dx:

参数	类型	取值	描述	默认值
ips_enable	u8	0/1	关闭/使能 IPS	1
ips_level	u8	RTW_IPS_WIFI_OFF	IPS 状态下 Wi-Fi 断电	RTW_IPS_WIFI_OFF
		RTW_IPS_WIFI_PG	IPS 状态下 Wi-Fi 进入 PG 模式
ips_ctrl_by_usr	u8	0	结合 API 控制开关 IPS 机制	0
		1	结合 API 控制进退 IPS 模式

不同的组合方式功能参见如下表格：

ips_enable	ips_ctrl_by_usr	wifi_set_ips_internal	行为
0	0	Y	动态开关 IPS 机制 默认关闭 IPS
0	1	Y	关闭 IPS 机制
0	X	N	关闭 IPS 机制
1	0	Y	动态开关 IPS 机制 默认使能 IPS
1	1	Y	动态进退 IPS 模式 调用 wifi_set_ips_inetrnal() 可以快速退出 IPS 模式。
1	X	N	使能 IPS 机制 系统通过周期性监测 Wi-Fi 状态决定是否进入预设的省电等级。

传统省电模式（LPS）

传统省电模式（Legacy Power Save，LPS）的核心思想是允许客户端在 Wi-Fi 连接状态且不存在无线数据传输的情况下进入睡眠状态，此时接入点（Access Point）为其缓存下行数据从而达到节省功耗的目的。

LPS 模式下，客户端需要周期性唤醒来接收 AP 的信标帧，并通过解析信标帧中流量指示图 （Traffic Indication Map） 元素获知是否存在自己的数据等待接收，若存在则保持清醒继续和 AP 进行数据交互。

参数	类型	取值	描述	默认值
lps_enable	u8	0 / 1	关闭/使能 LPS	1
lps_listen_interval	u8	0	每个目标信标传输时间（Target Beacon Transmission Time）都唤醒来接收信标帧	0
		> 0	配置接收信标帧的间隔，单位：102.4ms（TBTT 间隔）

无线局域网唤醒模式（WoWLAN）

无线局域网唤醒模式（Wake on Wireless LAN，WoWLAN）下系统空闲时整个 SoC 进入 低功耗睡眠模式 ，同时由 Wi-Fi 维持已建立的连接。 WoWLAN 建立在 LPS 之上，复用与 传统省电模式（LPS） 完全相同的信标监听机制，二者的区别在于：

• LPS：仅 Wi-Fi 的 RF 在 beacon 间隙进入睡眠；

• WoWLAN：在此基础上让整个 SoC 关电/关时钟 ，Wi-Fi 子系统大部分模块（RF、BB 及部分 MAC ）被关电/关时钟，仅少量逻辑运行在 32K 时钟上。

WoWLAN 整体流程

在双核（AP + NP）架构上，WoWLAN 的睡眠与唤醒协同流程如下图所示：

• NP：运行 Wi-Fi 驱动，负责维持连接、解析收包、判断是否需要唤醒 AP。

• AP：运行应用程序与协议栈（如 lwIP），处理业务逻辑。

WoWLAN 进入流程

1. 应用侧通过以下两种方式释放 OS wakelock 进入 WoWLAN 模式：

   • 执行 AT+TICKPS=R 命令

     AT+TICKPS=TYPE,PG     # 可选，设置睡眠类型为 PG（默认）或 CG
     AT+TICKPS=R           # 释放 OS wakelock，允许系统进入睡眠
     

   • 调用 pmu_release_wakelock()

2. AP 由 Active 进入 Idle，在空闲任务中通过 wakelock 检查。

3. AP 向 NP 发送 tickless IPC 消息，随后进入 WFE 等待。

4. NP 收到 IPC 消息后关闭 AP 的时钟（AP CG）并释放自身的 wakelock。

5. NP 由 Active 进入 Idle 后进入睡眠；若睡眠类型为 PG，则 PMC 同时关闭 AP 的电源。

6. Wi-Fi 按配置周期性醒来接收 Beacon，从而维持 Wi-Fi 连接。

WoWLAN 唤醒流程

Wi-Fi 唤醒

SDK 默认配置 Wi-Fi 中断 WIFI_FISR_FESR_IRQ 为 NP 的唤醒源。系统睡眠期间，Wi-Fi 收包中断触发后 NP 恢复运行，解析收到的报文并判断是否需要唤醒 AP：

• 若 不需要 （例如仅是可由 Wi-Fi 自行处理的报文），NP 处理完后重新进入睡眠， AP 保持睡眠不受影响 。

• 若 需要，NP 恢复 AP 和 Wi-Fi 驱动。AP 恢复后通过 IPC 中断获知唤醒原因为 Wi-Fi，继续处理业务。

能够唤醒 AP 和 Wi-Fi 驱动的原因分为以下几类：

类别	说明
Wi-Fi 决定断线	连续丢失 Beacon 后发送 Null Data 探测 AP 连续无 ACK，判定断线唤醒重连
链路断开帧	收到 AP 下发的 Deauth / Disassoc 帧
收到单播数据包	收到单播数据 / 管理帧（TCP、UDP、ICMP、ARP、EAPOL-Key、 Action 等）
收到广播/组播数据包	可通过参数 wowlan_rx_bcmc_dis 开关此类唤醒

AP 唤醒

可为 AP 单独配置唤醒源，如 GPIO、AON Timer，配置方式参见 低功耗的开发者配置 。此类事件发生时，PMC 将首先唤醒 NP，再由 NP 恢复 AP 的时钟。

唤醒后 无需重新初始化协议栈，已建立的 TCP/UDP 连接与 socket 均保留，应用线程可直接收发数据。

WoWLAN 相关 API

• 静态配置

  通过修改 Wi-Fi 用户配置文件 中函数 wifi_set_user_config() 中的以下变量：

  参数	类型	取值	描述
  lps_listen_interval	u8	>= 0	监听间隔： 0（默认）：每个 TBTT 都醒来接收 Beacon； >0：每 lps_listen_interval * 102.4ms 醒来接收一次 Beacon
  wowlan_rx_bcmc_dis	u8	0 / 1	0（默认）：允许广播 / 组播帧唤醒系统； 1：禁止广播 / 组播帧唤醒系统
  lps_rx_unicast_pkt_timeout	u8	> 0	保持清醒等待 AP 发送首个缓存单播包的超时时间，单位 ms

• 动态配置

  可在运行时调用如下 API：

  API	说明
  wifi_set_lps_listen_interval()	设置 Beacon 监听间隔（单位 102.4ms）
  wifi_set_wowlan_rx_broadcast()	开启 / 关闭 WoWLAN 下广播 / 组播帧唤醒
  wifi_set_wowlan_ipv6_wake()	开启 / 关闭 WoWLAN 下 IPv6 报文唤醒
  wifi_set_broadcast_port_wakeup_white_list()	设置 TCP/UDP 广播包的端口白名单（最多 6 个）， 仅白名单内端口的广播包才唤醒，其余丢弃； 未调用时不过滤端口。

Video IC 专用无线局域网唤醒模式（WoWLAN for Video）

支持的芯片[RTL8735C]

概述

WoWLAN for Video 是给 Video IC 使用的保活机制。系统由三个处理器协同运作，在维持网络连接的同时将功耗降至最低：

• AP（CA32）：配置 WoWLAN 参数、启用 WoWLAN 模式后进入休眠。系统唤醒后，AP 从 NP 取得唤醒原因。在后续周期中，AP 可选择复用既有的保活连接，而非重新建立新连接。

• NP（CM4）：负责所有第三层网络活动。使用 lwIP（TCP、TLS、MQTT、WSS 等）维持与远端服务器的保活连接，监控传入封包是否符合唤醒模式，并在唤醒事件发生时唤醒 AP。NP 还实现了指数退避重连逻辑，处理服务器端（L3）和 WiFi（L2）错误。

• FP（WiFi 固件 / KM0）：在 WiFi MAC 层运作，负责追踪 Beacon 帧。FP 监控已关联 AP 的 Beacon 接收状况。当链路层事件发生时（如 Beacon 逾时或收到 Deauthentication / Disassociation 帧），FP 透过 IPC 通知 NP，NP 据此关闭服务器连接并进行 WiFi 重连处理。

AP 休眠期间，NP 与 FP 持续运作。NP 进入保活循环后释放 wakelock，让系统达到最低功耗状态。FP 独立进行 Beacon 追踪，并在链路层条件改变时透过 IPC 通知 NP。此协作机制使整体系统在保持网络连接的同时，显著降低功耗。

三个处理器之间透过 IPC 通道进行通信。所有 IPC 消息类型定义于 kaipc_msg_type 枚举（wowlan_ipccfg.h）。

WoWLAN for Video 通常与保活桥接模式搭配使用：由 NP 独立维持保活连接，让 AP 得以在保持网络连接的同时进入休眠。保活桥接模式的详细说明见下方小节。

保活桥接模式

在保活桥接模式下， 两颗核心各自拥有独立的 lwIP 协议栈：AP（CA32）负责应用程序 socket，NP（CM4）则拥有 Wi-Fi 驱动；若启用保活功能，保活 socket 便运行在 NP 上。由于 NP 会自行维持保活连接，AP 可在保持连接的同时进入低功耗状态。

• NP（CM4） 运行 Wi-Fi 驱动与自己的 lwIP/DHCP 客户端。它从 DHCP 取得 IP 地址，并使用设备的 MAC 地址；其 netif[0] 直接将封包送往 wlan0。

• AP（CA32） 在自己的 lwIP 上运行应用程序 socket。它与 NP 共用 相同的 IP 与 MAC 地址，其 netif[0] 透过 Ameba IPC 连接到 wlan0。

由于两颗核心在 wlan0 上共用同一组 IP/MAC，从 wlan0 收到的每个封包都必须分派到正确的协议栈。NP 的 wlan 驱动会对每个封包分类，并送往 NP lwIP、AP 或两者。

封包分派规则

针对从 wlan0 收到的每个封包：

转发目标	封包类型
NP（CM4）	ICMP echo request（由 NP 回复 echo reply） DHCP（由 NP 处理） 目的端口在 NP 范围内的 TCP（见下方 TCP 本地端口范围）
AP（CA32）	目的端口在 AP 范围内的 TCP（见下方 TCP 本地端口范围） DHCP 与 DNS 以外的 UDP
两者（NP + AP）	ICMP echo request 以外的 ICMP ARP（两颗核心都可查询 ARP） DNS（两颗核心都可查询 DNS） 非 ARP/ICMP/TCP/UDP 封包

TCP 本地端口范围

TCP 本地端口范围会在两颗核心之间切分，使 socket 的本地端口本身即可标识其所属的协议栈：

核心	配置	TCP 本地端口范围
NP（CM4）	WHC_DEV	0xc000–0xdfff （49152–57343）
AP（CA32）	WHC_HOST	0xe000–0xffff （57344–65535）

任何目的端口落在 NP 范围内的 TCP 流量都属于 NP 的 socket，会被转发到 NP；其余 TCP 流量则送往 AP。由于 NP 开启的每个 socket 都会自动分配到 NP 范围内的本地端口，保活 socket（纯 TCP、MQTT、WSS 等）无需任何逐 socket 配置即可自动路由到 NP。

启用保活桥接

保活桥接由 CONFIG_WHC_DEV_TCPIP_KEEPALIVE 启用（在 WHC_IPC 下默认开启）。启用后，NP 会在开机时自动初始化桥接： init/np/ 下的 constructor 会在应用程序启动前调用 bridge_dispatch_init() ，无需应用程序代码介入。它会注册封包分类器，依上表将每个 wlan0 封包分派到对应协议栈。此后 NP 开启的任何 TCP socket 都会依本地端口范围自动保留在 NP 上，因此保活 socket（纯 TCP、MQTT、WSS）无需逐 socket 设置。保活心跳的参考实现请参阅 bridge_dispatch 范例。

API 参考

bridge_dispatch_init

void bridge_dispatch_init(void);

注册封包分类器以启用保活桥接。调用后，目的端口落在 NP 范围内的 TCP 流量会自动路由到 NP lwIP，保活 socket 无需逐 socket 设置。此函数无参数；当 CONFIG_WHC_DEV_TCPIP_KEEPALIVE 启用时， init/np/ 下的 constructor 会在开机时自动调用它，应用程序通常无需自行调用。

WOWLANCFG 结构

所有 WoWLAN 参数透过定义于 wowlan_ipccfg.h 的 WOWLANCFG 结构在 AP 与 NP 之间传递：

#define MAX_WAKEUP_PATTERNS_NUM    8
#define MAX_WAKEUP_PATTERN_LENGTH  64

typedef struct {
    uint8_t  dtim;
    uint8_t  type;
    uint32_t interval;
    uint32_t retry_interval;
    uint32_t retry_cnt;
    char     wakeup_pattern[MAX_WAKEUP_PATTERNS_NUM][MAX_WAKEUP_PATTERN_LENGTH];
    uint8_t  pattern_num;
    uint8_t  pattern_len[MAX_WAKEUP_PATTERNS_NUM];
    uint32_t pattern_offset[MAX_WAKEUP_PATTERNS_NUM];
    uint8_t  fp_wakeup_reason;
    uint8_t  np_wakeup_reason;
    uint8_t  resume;
} WOWLANCFG;

字段	类型	说明
dtim	u8	LPS 监听间隔的 DTIM 周期（例如 10）
type	u8	保活协议类型（参见 keep_alive_type 枚举）
interval	u32	发送 TCP keepalive 探测前的闲置时间（秒）
retry_interval	u32	两次保活探测之间的间隔（秒）
retry_cnt	u32	宣告失败前的最大保活探测次数
wakeup_pattern	char[][]	唤醒模式字符串数组；数组大小为 [MAX_WAKEUP_PATTERNS_NUM][MAX_WAKEUP_PATTERN_LENGTH]，可在 wowlan_ipccfg.h 中调整
pattern_num	u8	启用的唤醒模式数量
pattern_len	u8[]	各唤醒模式的字节长度
pattern_offset	u32[]	接收封包中开始比对的字节偏移量
fp_wakeup_reason	u8	FP（WiFi 固件）回报的唤醒原因；唤醒时为非零值
np_wakeup_reason	u8	NP 回报的唤醒原因；唤醒时为非零值
resume	u8	AP 设为 1 表示恢复现有连接（复用连接）而非从头建立新的保活连接

用于在 wowlan_cfg.c 中定义唤醒模式的 WOWLANPATTERN 辅助类型：

typedef struct {
    const char *pattern;   /* 模式字节串 */
    uint8_t     len;       /* 模式长度（字节） */
    uint8_t     offset;    /* 接收封包中开始比对的字节偏移量 */
} WOWLANPATTERN;

keep_alive_type 枚举

enum keep_alive_type {
    TCP_PROTOCOL_KA = 0,
    TCP_TLS_KA,
    MQTT_KA,
    WSS_KA,
    TOTAL_KA_NUM
};

NP 唤醒原因代码

np_wakeup_reason 字段由 NP 保活处理函数写入，用于说明 NP 退出保活循环的原因。下表两个宏的值为固定值；其余值为 lwIP socket 层直接返回的 errno 错误码（例如 ETIMEDOUT、ECONNRESET）。

宏	值	说明
TX_TCP_APP_Retry_TO	0xFC	保活 ACK 逾时；已超过重试次数上限
RX_TCP_FIN	0xFD	收到服务器发送的 TCP FIN
RX_Wakeup_Pattern	0xFE	收到符合已设定唤醒模式的封包
其他	errno	lwIP socket errno（例如 ETIMEDOUT、ECONNRESET）—— socket 层的连接错误

FP 唤醒原因代码

fp_wakeup_reason 字段由 NP 在收到 FP（WiFi 固件）的 IPC 通知后写入，反映 FP 在 Beacon 追踪期间检测到的链路层事件。

宏	值	说明
Rx_DeAuth_DisAssoc	0x08	FP 收到已关联 AP 发送的 Deauthentication 或 Disassociation 帧
FWDecisionDisconnect	0x10	WiFi 固件决定断线（例如 Beacon 逾时——连续遗漏多个 Beacon）

AP 工作流程

下图为 AP 与 NP 之间的保活流程概览，可快速了解整体架构，各处理器的细节流程随后说明。

AP 侧入口为执行于 CA32 核心的 wowlan_tickless_task()，整体流程如下：

1. 开机后透过 IPC 通知 NP，并等待 NP 回复唤醒原因。

2. 判断唤醒原因：

   • 为零 ——首次开机。AP 以 resume = 0 发送配置，NP 据此创建新的保活线程并建立全新连接。

   • 非零 ——由 WoWLAN 唤醒。仅当唤醒原因为 RX_Wakeup_Pattern 时设置 resume = 1 以复用现有连接；其他原因（FP 断线、TCP 错误等）则由 NP 创建新的保活线程。

3. 填入默认参数（wowlan_set_default_parameter()）后调用 wowlan_enable()，透过 IPC 将配置发送至 NP，随后进入 FreeRTOS tickless 休眠。

此后由 NP 管理保活循环，并在唤醒事件发生时唤醒 AP。

NP 工作流程

NP（CM4）使用 lwIP 处理所有第三层网络活动（保活循环与唤醒路径见上方流程图）。

保活线程 keep_alive_thread() 依配置的 keep_alive_type 选择处理函数，等待 WiFi 取得连接后进入 tickless 保活循环。处理函数返回时，依结果作出响应：

• 收到唤醒封包 ——唤醒 AP（CA32）并等待其恢复。

• L3 错误 ——服务器连接失败（fp_wakeup_reason == 0）时以指数退避重连，最多尝试 10 次（SERVER_RECONN_MAX_RETRY）后唤醒 AP。

• L2 错误 ——WiFi 断线（fp_wakeup_reason != 0）时进入 WiFi 重连循环，最长 50 秒；成功则恢复保活，超时则唤醒 AP。

下图概括了 NP 的保活流程——初始化、保活处理，以及错误恢复处理：

如需自定义保活协议，可新增 keep_alive_type 枚举值，并透过 WOWLANCB 结构注册对应回调：

typedef struct {
    int (*handler)(WOWLANCFG *config);        /* 保活主处理函数；唤醒时返回 RTK_SUCCESS，错误时返回 RTK_FAIL */
    int (*error_recover)(WOWLANCFG *config);  /* handler 失败时调用；返回 RTK_SUCCESS 重试，RTK_FAIL 则唤醒 AP */
} WOWLANCB;

extern void (*wowlan_close_server_conn_cb)(void);  /* 类型特定的关闭服务器连接回调 */

AP API 参考

以下 API 适用于 AP（CA32）侧。头文件：wowlan_ipccfg.h。

wowlan_set_default_parameter

void wowlan_set_default_parameter(WOWLANCFG *param);

以要发送至 NP 的 WoWLAN 配置填充 WOWLANCFG 结构。实现于 wowlan_cfg.c——修改此函数可变更保活参数与唤醒模式。

参数	方向	说明
param	out	指向待填充 WOWLANCFG 的指针

此函数配置的默认值：

param->dtim           = 10;
param->type           = TCP_TLS_KA;      /* 默认为 TLS 保活 */
param->interval       = 240;   /* TCP keepalive 闲置时间，秒 */
param->retry_interval = 5;     /* 探测间隔，秒              */
param->retry_cnt      = 12;    /* 最大探测次数              */

/* 唤醒模式——最多 MAX_WAKEUP_PATTERNS_NUM 个，各项定义于 wowlan_patterns[]：
   { 模式字符串, 长度, 接收封包中的字节偏移量 }                        */
static const WOWLANPATTERN wowlan_patterns[] = {
    {"wakeup1", 7, 3},
    {"wakeup2", 7, 3},
    {"wakeup3", 7, 3},
    {"wakeup4", 7, 3},
    {"wakeup5", 7, 3},
    {"wakeup6", 7, 3},
    {"wakeup7", 7, 3},
    {"wakeup8", 7, 3},
};
param->pattern_num = sizeof(wowlan_patterns) / sizeof(wowlan_patterns[0]);
for (int i = 0; i < param->pattern_num; i++) {
    if (param->pattern_num > MAX_WAKEUP_PATTERNS_NUM) {
        break;
    }
    memcpy(param->wakeup_pattern[i], wowlan_patterns[i].pattern,
           wowlan_patterns[i].len);
    param->pattern_len[i]    = wowlan_patterns[i].len;
    param->pattern_offset[i] = wowlan_patterns[i].offset;
}

备注

默认保活类型为 TCP_TLS_KA``（TLS）。如需改用纯 TCP 保活，请将此项改为 ``TCP_PROTOCOL_KA。

wowlan_enable

void wowlan_enable(WOWLANCFG *param);

透过 IPC 将 WOWLANCFG 配置发送至 NP，触发 NP 启动保活线程。调用此函数后，AP 可进入 tickless 休眠。

参数	方向	说明
param	in	指向已填充 WOWLANCFG 结构的指针

wowlan_get_wakeup_reason

void wowlan_get_wakeup_reason(WOWLANCFG *param);

从 NP 发送的 IPC 消息缓冲区读取唤醒原因。

参数	方向	说明
param	out	指向 WOWLANCFG 的指针，填入唤醒原因字段（fp_wakeup_reason、np_wakeup_reason）

wowlan_ap_wakeup_notification

void wowlan_ap_wakeup_notification(void);

向 NP 发送 IPC 消息，通知 AP 刚完成唤醒。NP 收到后将已储存的唤醒原因回传给 AP。

NP API 参考

以下 API 适用于 NP（CM4）侧。头文件：wowlan_ipccfg.h 与 keep_alive.h。

wowlan_report_wakeup_reason

void wowlan_report_wakeup_reason(WOWLANCFG *param);

透过 IPC 将唤醒原因回传给 AP。NP 收到 AP 的唤醒通知后调用此函数。

参数	方向	说明
param	in	指向含有唤醒原因字段的 WOWLANCFG 指针

wowlan_get_wifi_cfg / wowlan_set_wifi_cfg

void wowlan_get_wifi_cfg(WOWLANCFG *cfg);
void wowlan_set_wifi_cfg(WOWLANCFG *cfg);

NP 端用于读写本地缓存 WOWLANCFG 的辅助函数。NP 使用这两个函数在 IPC 事件之间持久保存从 AP 收到的配置。

wowlan_parser_wakeup_pattern

int wowlan_parser_wakeup_pattern(uint8_t *payload, uint32_t pkt_len, WOWLANCFG *param);

检查接收到的封包 payload 是否符合任何已配置的唤醒模式。

参数	方向	说明
payload	in	指向接收封包数据的指针
pkt_len	in	接收封包的字节长度
param	in	指向含有唤醒模式的 WOWLANCFG 指针
返回值		模式匹配时返回 RTK_SUCCESS，否则返回 RTK_FAIL

编译 WoWLAN for Video 范例

软件配置

1. 在 menuconfig 中启用 CONFIG_STANDARD_TICKLESS：

   ./ameba.py menuconfig
   

   导航至：

   (Top) → Tickless Development → CONFIG TICKLESS DEVELOP → Enable Tickless for Wowlan
   

2. 在对应的保活源代码文件中，将 SERVER_IP 与 SERVER_PORT 修改为实际的服务器地址。

3. 在 wowlan_set_default_parameter()``（``wowlan_cfg.c）中自定义唤醒模式与保活参数。

   默认保活类型为 TCP_TLS_KA``（TLS）。如需改用纯 TCP，请改为 ``TCP_PROTOCOL_KA：

   param->dtim           = 10;
   param->type           = TCP_TLS_KA;   /* 或改用 TCP_PROTOCOL_KA 使用纯 TCP */
   param->interval       = 240;
   param->retry_interval = 5;
   param->retry_cnt      = 12;
   

   唤醒模式定义于 wowlan_cfg.c 的 wowlan_patterns[] 数组中，每个项目指定一个字节字符串、其长度，以及在接收封包中开始比对的字节偏移量。模式内容与数量均可自由调整，以符合应用需求。默认 WOWLANCFG 结构最多支持 MAX_WAKEUP_PATTERNS_NUM 个模式，每个模式最长 MAX_WAKEUP_PATTERN_LENGTH 字节；若需超过此限制，请调整 wowlan_ipccfg.h 中的宏值：

   #define MAX_WAKEUP_PATTERNS_NUM    8
   #define MAX_WAKEUP_PATTERN_LENGTH  64
   
   char     wakeup_pattern[MAX_WAKEUP_PATTERNS_NUM][MAX_WAKEUP_PATTERN_LENGTH];
   uint8_t  pattern_len[MAX_WAKEUP_PATTERNS_NUM];
   uint32_t pattern_offset[MAX_WAKEUP_PATTERNS_NUM];
   

   static const WOWLANPATTERN wowlan_patterns[] = {
       /* { 模式,      长度, 偏移量 } */
       {"wakeup1",  7,  3},
       {"wakeup2",  7,  3},
       {"wakeup3",  7,  3},
       {"wakeup4",  7,  3},
       {"wakeup5",  7,  3},
       {"wakeup6",  7,  3},
       {"wakeup7",  7,  3},
       {"wakeup8",  7,  3},
       /* 根据需要新增或修改项目 */
   };
   

编译与烧录

从 SDK 根目录执行以下命令以编译 wowlan_tickless 范例：

./ameba.py build -a wowlan_tickless

编译成功后，使用 Ameba Image Tool 将映像烧录至开发板。

范例源代码位于：

example/network_protocol/wowlan_tickless/

范例使用的源代码：

component/soc/amebapro3/sw/wowlan_ap/      （AP 侧）
component/soc/amebapro3/sw/wowlan_np/      （NP 侧）

执行范例

烧录并开机后，使用 AT 命令连接至 WiFi AP：

AT+WLCONN=ssid,<your_ssid>,pw,<your_password>

等待出现 [$]wifi got ip 消息后，WoWLAN tickless 线程将自动启动并连接至保活服务器。

备注

请确保在 WoWLAN 线程启动前，位于 SERVER_IP:SERVER_PORT 的保活服务器可正常连通。NP 会先等待获取有效的 IP 地址，然后才尝试连接。