企业官网建设流程全解析

【星闪 SLE 学习笔记 01】深入理解技术体系、协议栈架构与核心通信机制

这是我的星闪 SLE 系列学习笔记第一篇。这一篇先不操作开发板，而是根据国际星闪联盟公开标准与技术资料、BearPi 官方文档，以及 BearPi-Pico H3863 公开 SDK，把 SLE 的技术体系、协议分层和基本通信过程梳理清楚。文中不包含实板性能测试，也不会把未经验证的速率、时延或功耗宣传数字当成自己的结论。

文章摘要：本文是星闪 SLE 系列学习笔记的第一篇，主要梳理星闪、SLB 与 SLE 的关系，介绍接入层、基础服务层和基础应用层的分工，并结合 BearPi-Pico H3863 公开 SDK，分析 announce、seek、连接与配对、SSAP 服务发现及数据交互的基本流程。文章严格区分标准定义、官方公开信息、SDK 可观察实现和实板结果，为后续双开发板实验建立技术基础。

关键词：星闪；SLE；BearPi-Pico H3863；SSAP；协议栈；设备发现

前言：我为什么先从技术体系学起

刚开始了解星闪 SLE 时，我最先看到的也是各种速率、时延、连接数量和功耗指标。但继续查资料后，我发现如果没有先弄清协议体系，这些数字很容易被错误地带入开发场景：空口峰值不等于应用吞吐，示例参数不等于标准规定，SLE 也不等于整个星闪系统。

所以，我决定第一篇先不做性能比较，也不急着搭建开发环境，而是先解决三个最影响后续学习的问题：

1. SLE 在星闪技术体系中处于什么位置？
2. 两台设备从发现彼此到传输应用数据，要经历哪些阶段？
3. BearPi-Pico H3863 示例中的announce、seek和SSAP，分别位于这条通信链路的哪里？

把这些问题理顺以后，后面再读 SDK、看串口日志和做双板实验，才不容易把不同层次的概念混在一起。

一、我先弄清楚了：星闪、SLB 和 SLE 不是一回事

我一开始把“SLE”和“星闪”当成了几乎相同的概念。查阅国际星闪联盟公开的 Release 1.0 技术资料后才发现，星闪无线通信系统并不是一个单独的空口协议，而是由以下三部分组成：

• 星闪接入层；
• 基础服务层；
• 基础应用层。

星闪接入层向上提供无线接入能力，其中包括 SLB 和 SLE 两类技术。相关技术资料可参考国际星闪联盟公开的《星闪无线短距通信技术（SparkLink 1.0）》。

为了方便自己记忆，我把它简化成下面这张技术地图：

星闪无线通信系统 │ ├─ 基础应用层 │ └─ 面向具体业务和通用原子能力 │ ├─ 基础服务层 │ └─ 设备发现、服务管理、连接、QoS、测量、安全、数据适配等 │ └─ 星闪接入层 ├─ SLB └─ SLE：面向低功耗诉求的星闪接入技术

我从这里得到的第一个重要结论是：

SLE 是星闪接入层的一种技术，不是整个星闪体系的同义词。

设备发现、服务管理和连接管理等能力位于基础服务层；温度采集、遥控器、键鼠或串口透传等具体业务，还会继续向上进入应用层。

一个必须提醒自己的问题：不要直接用 BLE 解释 SLE

由于之前更容易接触到 BLE，我阅读 SLE 资料时会下意识寻找对应概念。但 SLE 与 BLE 都可用于低功耗短距通信，并不意味着二者的角色、状态机、报文格式、服务访问协议或参数单位相同。

在 H3863 SDK 中，我们会看到announce、seek、SSAP、property等术语。某些概念可能让熟悉 BLE 的读者产生联想，但“便于理解的类比”不能替代标准定义，更不能据此断言两套协议的底层过程相同。

因此，这篇笔记会尽量保留星闪资料与 H3863 SDK 中实际使用的术语。即使某个概念看起来很像 BLE，我也不会直接把两者写成同一种机制。

查资料时遇到的一个细节：SLE 名称存在版本差异

联盟公开目录中的不同标准版本对英文题名有所调整：

• T/XS 10002-2022 使用 “Air-interface Low Energy”；
• T/XS 10002-2025 V2.1.1 使用 “Air-interface Synchronous Low Energy”。

因此，查阅公开资料时会看到 SparkLink Low Energy 和 Synchronous Low Energy 两种展开方式。为了避免在名称上反复绕圈，后文统一写SLE；需要引用具体规范时再标明版本，不把某一版本中的写法当成跨版本的唯一名称。相关标准文本可在国际星闪联盟公开的标准目录中查阅。

二、我是怎样理解星闪三层协议体系的

经过整理，我暂时用一句话记住三层分工：

接入层解决“如何通过无线链路传输”，基础服务层解决“设备如何发现、连接和使用通用服务”，基础应用层解决“具体业务如何协同”。

1. 星闪接入层：提供无线传输能力

T/XS 10002 系列规定 SLE 空口的技术要求与测试方法。站在协议栈上层观察，接入层负责提供和维持无线传输所需的底层能力，但不定义某个温度服务、遥控器按键或串口透传业务本身。

频谱、信道、调制编码、帧结构与接入控制属于空口和接入问题；“设备提供哪些服务、某项数据是否允许读写”则属于更上层的问题。

这里我只先记住层次边界。对于 PHY 或 MAC 的具体机制，后续必须对照标准条文继续学习，不能凭其他无线协议的经验自行补全。

2. 基础服务层：把无线链路组织成通用能力

T/XS 20001-2022《星闪无线通信系统 基础服务层 设备发现与服务管理》覆盖的内容包括：

• 设备角色；
• 设备公开信息；
• 设备发现过程；
• 广播数据格式；
• 服务及其元素；
• 服务结构；
• 服务交互信令。

该标准适用于采用 SLB 和/或 SLE 接入技术的星闪设备。标准目录页可在国际星闪联盟公开的标准目录中查阅。

联盟公开架构还将连接管理、QoS 管理、测量管理、安全管理以及数据传输与适配列入基础服务层。换句话说，接入层先提供无线链路，基础服务层再把链路组织成上层能够使用的通用通信能力。

这一点也帮我解决了阅读 H3863 示例时的一个困惑：公开自身、寻找设备、建立连接、管理服务和交换数据虽然连续发生，却不是同一个步骤，更不能全部笼统地叫作“广播”。

3. 基础应用层：定义具体业务如何协同

基础应用层面向具体业务定义应用配置，也可以调用音频、视频等原子能力。它关注的不是某个寄存器如何配置，而是不同设备为了完成同一种业务，应交换哪些信息、遵循怎样的业务流程。

以之后的双板串口透传实验为例：

• 无线信号怎样传输，属于接入层问题；
• 怎样发现对端、建立连接并访问服务，主要涉及基础服务层；
• 如何把收到的字节解释为温度、按键或控制命令，则进入应用语义。

现在回头看，三层并不是三套互不相关的系统，而是从无线接入 → 通用通信服务 → 具体业务语义逐层抽象。

三、沿着 H3863 示例走一遍 SLE 通信过程

理解协议分层之后，我开始沿着 BearPi-Pico H3863 的sle_uart示例读代码，想弄明白两台设备如何从“尚未发现彼此”走到“能够交换应用数据”。

先说明两个术语：H3863 SDK 使用announce表示设备对外发布可发现信息，使用seek表示寻找周围设备。本文分别将它们解释为“发布/宣告”和“寻找”，但这只是中文释义，不表示它们与其他无线协议中的相似过程完全相同。

把服务端和客户端代码放在一起看，我整理出了下面这条软件流程：

服务端 客户端 注册并启动 SSAP 服务 设置 announce 参数与公开数据 启动 announce ←── 开始 seek，接收公开信息 按名称筛选目标设备 ──→ 发起连接 收到连接状态回调 ←────────→ 收到连接状态回调 ←──→ 配对 ←──→ 交换 SSAP 信息与 MTU ←── 查找 service/property 处理写请求或发送通知 ←────────→ 交换应用数据

需要注意：这张图描述的是 H3863sle_uart示例中可观察的软件流程，不是标准规定的完整空口时序图。图中省略了回调注册、错误处理、控制报文和底层接入过程。

1. announce：服务端先告诉周围“我在这里”

在两台陌生设备建立连接之前，至少要有一方先公开必要信息，使另一方能够找到它。

在 H3863 服务端示例中，程序先构造 announce 参数，选择可连接、可 seek 的模式，并设置 announce interval、连接参数范围、信道映射、发送功率和本机地址。

随后，示例准备两部分公开数据：

• announce data：包含发现等级和接入模式；
• seek response data：包含发送功率和本地名称sle_uart_server。

参数和数据准备完成后，程序依次设置 announce 参数、设置 announce 数据，最后调用sle_start_announce()。相关实现可参考 BearPi 官方公开源码仓库中sle_uart_server_adv.c文件。

读到这里时，我需要特别区分“公开信息”和“业务数据”。设备名称、发现等级等内容用于帮助对端发现或识别设备，它们不是串口透传业务本身。真正的应用数据需要在后续连接与服务访问阶段传输。

示例将 announce interval 设置为0xC8，源码注释说明其单位为 125 μs，对应 25 ms。这是当前示例的配置值，不能写成“SLE 的 announce 间隔固定为 25 ms”。

2. seek：客户端从周围设备中找到目标

服务端开始 announce 后，客户端主动寻找周围设备。

H3863 客户端示例设置 seek 参数并调用sle_start_seek()。SDK 返回 seek 结果后，回调函数检查结果数据中是否包含名称sle_uart_server：

1. 没有匹配时，继续等待其他结果；
2. 匹配成功时，保存对端地址；
3. 调用sle_stop_seek()停止寻找；
4. 在 seek 停止回调中发起连接。

相关实现可参考 BearPi 官方公开源码仓库中sle_uart_client.c文件。

这段代码让我注意到一个很重要的区别：发现设备与选择设备是两件事。SDK 可以报告多个周围设备，应用仍要根据名称、地址、公开数据或自己的业务规则决定连接哪一个。

当前示例使用名称匹配，适合演示流程；正式产品是否可以把名称作为唯一筛选条件，还需要结合设备身份、安全认证和多设备管理重新设计。

3. 连接与配对：从“看见”走向受管理的链路

发现阶段解决的是“我看到了谁”，连接阶段解决的则是“我要与谁建立受管理的通信关系”。

收到 seek 结果不代表连接已经成功，更不代表双方已经可以按照业务服务交换数据。

客户端调用连接接口后，通过连接状态回调获得结果。示例在状态变为SLE_ACB_STATE_CONNECTED时检查配对状态；如果尚未配对，就调用sle_pair_remote_device()。如果链路断开，示例会移除已有配对记录并重新开始 seek。

配对完成后，客户端构造ssap_exchange_info_t，请求交换 SSAP 信息，其中包括 MTU 和版本。因此，这一阶段还可以继续拆成三步：

1. 建立连接；
2. 根据当前状态执行配对；
3. 为后续服务访问交换必要的 SSAP 参数。

客户端示例把请求 MTU 设置为 520。这个数字不表示每次 UART 输入都能形成 520 字节的有效空口载荷，也不等于端到端吞吐。实际生效值、数据分片和应用有效负载，需要结合双方回调和后续实板测试确认。

4. 服务发现：连接成功还不等于知道对方能做什么

连接只建立了通信关系。客户端还需要知道：

• 对端提供哪些服务？
• 服务中有哪些可访问的数据？
• 应使用哪个标识或句柄访问它们？

H3863 服务端通过 SSAP 接口注册 server，依次添加 service、property 和 descriptor，然后启动 service。

客户端完成 SSAP 信息交换后调用ssapc_find_structure()，在指定句柄范围内查找服务结构。SDK 再通过回调返回找到的 service 和 property 信息，客户端保存 property handle，供后续写入等操作使用。服务端源码、客户端源码

为了继续读代码，我先用下面这张表记住几个核心对象：

这张表是帮助阅读 SDK 的概念摘要，各对象的正式定义、字段和交互规则仍应以对应版本标准为准。

尤其不能因为源码中出现 service、property、descriptor 和 UUID，就得出“SLE 只是换了名称的 GATT”这一结论。结构上的相似性不能证明协议编码、状态机和互操作规则相同。

5. 数据交互：服务结构最终要落到具体操作

服务发现完成后，双方才具备围绕目标 property 交换数据的条件。

在sle_uart示例中，客户端保存发现到的 property handle，并可通过 SSAP client 写接口向服务端发送数据；服务端注册读写请求回调，接收客户端操作。

另一个方向上，SSAP 服务端接口支持向指定连接发送 notification 或 indication，客户端注册相应回调接收数据。H3863 SSAP 服务端公开头文件

notification 和 indication 的确认方式、可靠性语义以及示例最终选择的操作，需要结合具体 API 参数、源码路径和标准说明，不能仅凭英文名称套用其他协议的结论。

整理到这里，我才算把一次通信的完整闭环串了起来：

公开信息 ↓ 发现并选择目标 ↓ 建立连接与配对 ↓ 交换 SSAP 参数 ↓ 发现 service/property ↓ 通过 handle 执行读、写、通知或指示

这条链路也是之后观察双板日志的基本顺序。串口只打印“连接成功”，并不能说明服务发现和应用数据收发已经完成；还要继续核对配对、MTU、结构发现、handle 和数据回调。

四、读源码时必须适应：它是回调驱动的

梳理服务端和客户端代码后，我发现一个贯穿示例的特点：通信过程是异步、回调驱动的。

服务端主要路径

1. 注册 announce/seek、连接和 SSAP server 回调；
2. 注册 SSAP server；
3. 添加 service、property、descriptor，并启动 service；
4. 设置 announce 参数和公开数据；
5. 启动 announce；
6. 建链后通过回调处理 MTU、读写及通知/指示。

客户端主要路径

1. 注册 seek、连接和 SSAP client 回调；
2. 开启 SLE；
3. 配置并开始 seek；
4. 根据公开名称筛选目标并停止 seek；
5. 连接、配对并交换 SSAP 信息；
6. 查找服务结构与 property；
7. 保存 handle，执行写入或接收通知/指示。

这是我阅读代码时最需要转变的思路：一个函数返回成功，通常只能说明请求已被接口接受，最终结果还要等待对应回调。

例如，“发起连接接口返回成功”和“连接状态回调报告已经连接”不是同一件事；“调用服务发现接口成功”和“已经收到全部服务发现结果”也不是同一件事。

H3863 的 SSAP 公开头文件还特别提醒：部分回调运行在 SLE service 上下文中，不应阻塞或长时间等待。这意味着实际开发时，不宜直接在回调里执行耗时业务；更合理的做法通常是快速保存数据或投递消息，再交给其他任务处理。

后一条是基于 SDK 回调约束给出的工程建议，不是本文对标准行为的扩展定义。

五、为什么我选择 BearPi-Pico H3863 继续学习

我手上有两块 BearPi-Pico H3863，后续可以让它们分别承担 Server 和 Client 角色。根据 BearPi 官方资料，这款核心板集成 2.4 GHz Wi-Fi 6、BLE 和 SLE，采用 WS63、RISC-V 32 位 CPU，最高主频 240 MHz，并提供 SRAM、ROM、Flash 及 GPIO、UART、I²C、SPI、PWM、ADC 等外设资源。BearPi-Pico H3863 产品页

BearPi 官方资料入口还提供以下公开示例：

• SLE 串口透传；
• SLE 串口 1 对 8 透传；
• SLE 网关透传；
• BLE 与 Wi-Fi 相关示例。

BearPi-Pico H3863 资料入口

从学习角度看，这些资料已经覆盖发现、连接、服务访问与数据收发等基本流程。不过，我也不能因为官方提供了示例，就直接认为它们已经证明：

• 应用层吞吐能够达到产品页列出的峰值空口速率；
• 任意距离、遮挡和干扰条件下都有固定时延；
• 串口透传示例已经采用最低功耗或最高吞吐参数；
• 两块板在不同固件、供电和射频环境下会得到相同结果。

所以，我会在整个系列中始终区分四类信息：

这一篇完成的是前三类资料的梳理。实板测试要从下一篇开始，因此这里不会虚构运行结果。

六、这次学习后，我先记住五条边界

1. SLE 不等于整个星闪系统

SLE 位于星闪接入层。星闪体系还包括基础服务层和基础应用层。

2. SLE 不等于 BLE

可以用已有知识帮助理解，但不能直接复制 BLE 的角色、报文、状态机和服务协议结论。

3. SDK API 不等于标准原文

sle_start_announce()、ssapc_find_structure()等是 H3863 SDK 接口。其他厂商的 API 可能采用不同名称与封装，但仍需遵循相应互操作标准。

4. 示例参数不等于协议固定值

25 ms announce interval、示例中的连接间隔以及请求 MTU 520，都是当前源码的配置或请求值。

5. 空口峰值不等于应用吞吐

协议开销、调度、确认与重传、主机处理、缓冲区和串口速率都会影响最终可用吞吐。

七、这篇笔记的阶段性总结

这一篇没有从性能宣传数字出发，而是先建立了我继续学习星闪 SLE 所需的技术地图：

1. 星闪无线通信系统由接入层、基础服务层和基础应用层构成；
2. SLE 是星闪接入层的一种技术，而不是整个星闪体系；
3. 基础服务层负责把无线链路组织成发现、连接、服务访问等通用能力；
4. H3863sle_uart示例呈现了 announce → seek → 连接与配对 → SSAP 参数交换 → 服务发现 → 数据交互的实现路径；
5. SDK API、示例参数、官方规格和实板测试结果必须分开陈述；
6. SLE 不能简单理解为“换了名称的 BLE”。

写完这篇笔记后，我并没有立刻记住所有协议字段，但已经知道主要概念位于哪一层、分别解决什么问题，以及阅读 SDK 时应该沿着哪条主线追踪。这正是第一篇想要达到的目标。

下一篇开始进入实战。我会使用两块 BearPi-Pico H3863，分别运行 SLE Server 和 Client，完成编译与烧录，再通过真实串口日志观察设备发现、连接、配对、服务发现和数据收发过程。

参考资料

1. 国际星闪联盟：《星闪无线短距通信技术（SparkLink 1.0）》
2. T/XS 10002-2022：星闪无线通信系统 低功耗技术要求和测试方法
3. T/XS 10002-2025 V2.1.1：接入层 同步低功耗空口 SLE 技术要求和测试方法
4. T/XS 20001-2022：基础服务层 设备发现与服务管理
5. BearPi-Pico H3863 官方产品页
6. BearPi-Pico H3863 官方资料入口
7. BearPi-Pico H3863 官方公开源码仓库

源码观察基线：BearPi 官方公开仓库提交08d2880956249642cc90d7eae9b80ed721646967。仓库后续更新可能改变示例目录、接口或默认参数。
在这里插入图片描述