Beken AT Server 框架

tags: [IoT, BK7258, AT, 量产, EasyFlash, 嵌入式]
created: 2026-05-11
updated: 2026-05-11
sources: [raw/snippets/bk7258-build/mass-production-knowledge-2026-05-11.md, raw/snippets/bk7258-build/mass-production-actual-implementation-2026-05-11.md]

定义¶

Beken AT Server 是 bk_aidk SDK 自带的 AT 命令服务器框架（路径 bk_aidk/.../components/at_server/），把 BK7258 固件变成一个对外通过 UART 接收 AT 命令、返回 OK/ERROR 响应的设备。框架已经支撑 BK 原厂的 AT+WLMAC（读 MAC）等基础命令；新增自定义命令只需 3 步。

2026-05-11 修正：本页首版定位为"Sentino BK7258 项目走量产烧录路径的具体技术通道"。代码核查后的事实是：当前项目烧三元组走的不是 AT 命令路径，而是厂测 AP（!FT@IOT1#）+ UDP 40000/40001 或厂测 MQTT 下发 thing.testing.burn 消息（详见 triple-burning 路径 2）。本页 AT 通道在 Sentino 项目里当前承担的是 AT+WLMAC 验 MAC 等出厂检测命令，不烧三元组。AT Server 框架仍是未来设计离线烧录通道时的候选基础设施——在工厂 WiFi 不能联网的场景下，治具串口直接喂三元组到固件、固件本地校验后写 FLASH 是离线方案的自然形态。

为什么单独成页¶

iot-mass-production 讲产线工位 + 治具物理形态，triple-burning 讲三元组烧录的三种范式与本项目实际实现。本页独立维护"AT Server 框架本身的技术细节"——三件套挂法、与 AT+WLMAC 同源、EasyFlash KV 写入坑、产线时代 SSH 等价物的工程含义——以便未来 Sentino 真要做离线烧录通道（基于本框架新增烧三元组命令）时有现成的技术底座。

框架三件套（注册新 AT 命令）¶

// 1. ATSVR_CMD_HADLER 注册命令处理函数
ATSVR_CMD_HADLER(at_triple_set_handler) {
    // 解析参数 → 调 EasyFlash KV → 应答
    if (success) {
        atsvr_cmd_rsp_ok();
    } else {
        atsvr_cmd_rsp_error();
    }
}

// 2. 命令表（命令名 + handler + 参数说明）
static const at_command_t triple_cmds[] = {
    {"AT+TRIPLE", at_triple_set_handler, "Set device triple"},
    {"AT+TRIPLE_QUERY", at_triple_query_handler, "Query device triple"},
};

// 3. atsvr_register_commands 挂模块
void at_triple_module_init(void) {
    atsvr_register_commands(triple_cmds, ARRAY_SIZE(triple_cmds));
}

→ 三步挂一个新命令——比起在 embedded-firmware-layering 业务层加新 DP 点（要走业务/适配/SDK 三层），AT 命令路径更短、专门为产线工具用。

与 AT+WLMAC 同源 — 现状与未来¶

宣德代工厂产线已经通过 UART AT 通道跑 AT+WLMAC 验 MAC（确认 BK7258 出厂 efuse 已正确烧入 MAC 地址）。这是 Sentino BK7258 项目里 AT Server 框架当前承担的实际职责——出厂检测命令通道，不烧三元组。

治具侧	命令	期待应答	状态
验 MAC	`AT+WLMAC?`	`+WLMAC:c8:47:8c:xx:xx:xx\r\nOK\r\n`	当前已用
烧三元组（假设性）	`AT+TRIPLE=<pid>,<uuid>,<secret>`	`OK\r\n`	未实现——当前烧三元组走厂测 AP + UDP/MQTT，不走 AT
回读验证（假设性）	`AT+TRIPLE_QUERY`	`+TRIPLE:<pid>,<uuid>,<secret>\r\nOK\r\n`	未实现

→ 如果未来 Sentino 要做离线烧录通道（解决"工厂 WiFi 不能连外网 + 工厂内不愿自建厂测 MQTT"的真实约束，详见 triple-burning "真正的产品缺口"），最自然的载体就是基于 AT Server 框架新增 AT+TRIPLE 类命令——治具侧只需在已有的 AT 协议交互序列里增加几行命令，不需要新装驱动 / 新刷固件 / 新接物理通道。这是"通道复用"的工程价值——产线已经被验证可用的物理通道，新功能搭上即可。

但这是未来选项，不是当前实现。

EasyFlash KV：为什么不能让烧录器直写裸 offset¶

三元组的 Flash 存储路径：

Beken EasyFlash KV
   ├─ key = "triple_data"
   ├─ 分区 = 0x7e9000
   └─ 通过 bk_set_env_enhance(key, value) 写入

EasyFlash 是 RT-Thread 派生的轻量 KV 存储库，封装在 BK SDK 里。它不是裸字节存储，是结构化 KV——每条记录有元数据（key 长度 / value 长度 / CRC / 版本号 / 链表指针），写入和读取必须走库函数。

裸写 offset 的失败模式： - 烧录器（譬如 tyutool）按"在 0x7e9000 写一段二进制"的方式直接落 Flash - EasyFlash 启动时扫描分区，找不到合法的 KV 元数据头，认为分区被损坏 → 整片擦除 / 报错 - 即使勉强能"猜对"元数据格式，CRC / 版本号变化时立刻挂——库版本升级就会破坏

正确路径： - 治具发 AT+TRIPLE AT 命令 - 固件 handler 调 bk_set_env_enhance("triple_data", value) - EasyFlash 自己生成元数据 + CRC，写入 Flash - 治具发 AT+REBOOT 或断电 → 重启 → 设备启动时从 EasyFlash 读三元组确认成功

→ 这一条是 IoT 项目从"开发期编译期硬编码"过渡到"量产烧录"时最容易踩的坑：以为 Flash 是裸字节存储，结果 KV 库根本不让裸写。

与其他烧录路径的对比¶

路径	通道	特点	在 Sentino 项目当前状态
`tyutool` 直写裸 Flash	USB 串口 + 自定义二进制协议	烧 bootloader / app 固件用，不能用来烧 EasyFlash KV	当前用
厂测 AP + UDP/MQTT 下发	WiFi（`!FT@IOT1#`）+ UDP 40000/40001 或 MQTT `thing.testing.burn`	烧三元组的实际实现，需要工厂内有 MQTT/UDP 服务	已实现（路径 2）
云端动态注册	WiFi（`!FT@IOT0#`）+ 外网 MQTT `mqtt-iot.sentino.jp:1883`	白板首次激活，需要外网	已实现 v1.0.5
自定义 AT 命令（本页）	UART + AT 协议	修配置 / 单条命令交互 / 离线场景，与 EasyFlash 兼容	当前承担 `AT+WLMAC` 验 MAC，不烧三元组
OTA 升级	MQTT + HTTPS	量产后远程升级，sentino-iot OTA 通道	已实现
配网下发	BLE V1 协议	ble-provisioning，配网时下发 MQTT 接入信息	已实现

→ 不同事情走不同通道："灌固件" vs "灌每片唯一的小数据" vs "OTA" vs "配网"是四件不同的事。混淆会出工程问题。当前 Sentino 烧三元组的"主流量产路径"是厂测 AP + UDP/MQTT，AT 命令是"未来要做离线通道时的候选载体"。

工程含义：把 AT Server 当作"产线时代的 SSH"¶

后台世界给一台机器加运维入口的标准做法是开 SSH。嵌入式没有 SSH，UART + AT 命令服务器就是产线时代的等价物——治具操作员 / 工厂 IT / 客户售后都通过它对设备做受控操作：

后台 SSH 用途	IoT AT Server 用途
改配置文件	`AT+TRIPLE` 改三元组
查日志	`AT+LOG_DUMP` 读日志（待实现）
重启	`AT+REBOOT`
跑诊断	`AT+SELFTEST` 跑自检（待实现）
看版本	`AT+VERSION`

→ 这意味着 AT 命令集本身就是产品对外暴露的"运维 API"，需要按 API 设计原则对待——版本演进 / 向前兼容 / 错误码规范 / 文档化 / 安全（生产固件 vs 工厂固件 AT 命令集应不同，避免出厂后被任意 AT 操作）。

Sentino BK7258 项目的当前接入路径与未来选项¶

当前：AT Server 框架挂载 AT+WLMAC 等出厂检测命令，烧三元组走的是另一套机制（厂测 AP + UDP/MQTT 下发，详见 triple-burning 路径 2）。

未来选项 — 离线烧录通道：如果未来要解决"工厂 WiFi 不能连外网 + 工厂内不愿自建厂测 MQTT"这个真实约束（详见 triple-burning "真正的产品缺口"），自然路径是基于本框架新增 AT+TRIPLE 类命令：

在 projects/{产品}/main/ 加 at_triple_cmd.c，调 EasyFlash 写 triple_data KV
app_main.c 启动时调 at_triple_module_init() 挂命令
宣德产线治具脚本：AT+WLMAC? 验 MAC → 治具本地工具从离线三元组池或事先下载好的清单取一条 → AT+TRIPLE=<...> 烧 → AT+TRIPLE_QUERY 回读校验 → AT+REBOOT → 等待重启后 AT+TRIPLE_QUERY 二次确认 → 治具记录销账（联网时再批量上报销账给云端）
生产固件 vs 工厂固件：建议两套——工厂固件保留 AT+TRIPLE 写命令，生产固件去掉写命令只留读命令，避免出厂后被任意 AT 改三元组

开放问题（如果未来要做离线烧录通道）¶

是否基于 AT Server 框架新增烧三元组命令、还是另选载体（譬如治具直接 SPI 写整个 EasyFlash 分区）？AT 命令路径优势是"治具侧已通"
AT+TRIPLE 失败时的具体错误码定义（写 Flash 失败 vs 参数错 vs 已烧不允许覆盖）
离线三元组池的分发方式（治具本地 SQLite？事先用 USB 灌一批？）
销账时机（联网后批量上报 vs 工厂内自建简易销账服务）
工厂固件 vs 生产固件的差异化构建路径（条件编译宏 / 不同 target？）
是否需要 AT+TRIPLE 加密（密钥静态分发 vs 治具会话级密钥）——本项目当前 UART 物理隔离，攻击面仅限工厂内网，但出厂后如果 AT 还能用就需要更严格保护

定义¶