【星闪 SLE 学习笔记 01】深入理解技术体系、协议栈架构与核心通信机制这是我的星闪 SLE 系列学习笔记第一篇。这一篇先不操作开发板而是根据国际星闪联盟公开标准与技术资料、BearPi 官方文档以及 BearPi-Pico H3863 公开 SDK把 SLE 的技术体系、协议分层和基本通信过程梳理清楚。文中不包含实板性能测试也不会把未经验证的速率、时延或功耗宣传数字当成自己的结论。文章摘要本文是星闪 SLE 系列学习笔记的第一篇主要梳理星闪、SLB 与 SLE 的关系介绍接入层、基础服务层和基础应用层的分工并结合 BearPi-Pico H3863 公开 SDK分析 announce、seek、连接与配对、SSAP 服务发现及数据交互的基本流程。文章严格区分标准定义、官方公开信息、SDK 可观察实现和实板结果为后续双开发板实验建立技术基础。关键词星闪SLEBearPi-Pico H3863SSAP协议栈设备发现前言我为什么先从技术体系学起刚开始了解星闪 SLE 时我最先看到的也是各种速率、时延、连接数量和功耗指标。但继续查资料后我发现如果没有先弄清协议体系这些数字很容易被错误地带入开发场景空口峰值不等于应用吞吐示例参数不等于标准规定SLE 也不等于整个星闪系统。所以我决定第一篇先不做性能比较也不急着搭建开发环境而是先解决三个最影响后续学习的问题SLE 在星闪技术体系中处于什么位置两台设备从发现彼此到传输应用数据要经历哪些阶段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没有匹配时继续等待其他结果匹配成功时保存对端地址调用sle_stop_seek()停止寻找在 seek 停止回调中发起连接。相关实现可参考 BearPi 官方公开源码仓库中sle_uart_client.c文件。这段代码让我注意到一个很重要的区别发现设备与选择设备是两件事。SDK 可以报告多个周围设备应用仍要根据名称、地址、公开数据或自己的业务规则决定连接哪一个。当前示例使用名称匹配适合演示流程正式产品是否可以把名称作为唯一筛选条件还需要结合设备身份、安全认证和多设备管理重新设计。3. 连接与配对从“看见”走向受管理的链路发现阶段解决的是“我看到了谁”连接阶段解决的则是“我要与谁建立受管理的通信关系”。收到 seek 结果不代表连接已经成功更不代表双方已经可以按照业务服务交换数据。客户端调用连接接口后通过连接状态回调获得结果。示例在状态变为SLE_ACB_STATE_CONNECTED时检查配对状态如果尚未配对就调用sle_pair_remote_device()。如果链路断开示例会移除已有配对记录并重新开始 seek。配对完成后客户端构造ssap_exchange_info_t请求交换 SSAP 信息其中包括 MTU 和版本。因此这一阶段还可以继续拆成三步建立连接根据当前状态执行配对为后续服务访问交换必要的 SSAP 参数。客户端示例把请求 MTU 设置为 520。这个数字不表示每次 UART 输入都能形成 520 字节的有效空口载荷也不等于端到端吞吐。实际生效值、数据分片和应用有效负载需要结合双方回调和后续实板测试确认。4. 服务发现连接成功还不等于知道对方能做什么连接只建立了通信关系。客户端还需要知道对端提供哪些服务服务中有哪些可访问的数据应使用哪个标识或句柄访问它们H3863 服务端通过 SSAP 接口注册 server依次添加 service、property 和 descriptor然后启动 service。客户端完成 SSAP 信息交换后调用ssapc_find_structure()在指定句柄范围内查找服务结构。SDK 再通过回调返回找到的 service 和 property 信息客户端保存 property handle供后续写入等操作使用。服务端源码、客户端源码为了继续读代码我先用下面这张表记住几个核心对象对象在示例中的作用service将一组相关能力组织成服务结构property服务中可被读、写或用于通知等交互的数据单元descriptor为 property 提供补充描述或配置信息UUID标识应用、service 或 property 等对象handle服务发现后用于定位某个结构元素的句柄SSAPH3863 SDK 中用于服务访问相关操作的一组接口和数据结构这张表是帮助阅读 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 和数据回调。四、读源码时必须适应它是回调驱动的梳理服务端和客户端代码后我发现一个贯穿示例的特点通信过程是异步、回调驱动的。服务端主要路径注册 announce/seek、连接和 SSAP server 回调注册 SSAP server添加 service、property、descriptor并启动 service设置 announce 参数和公开数据启动 announce建链后通过回调处理 MTU、读写及通知/指示。客户端主要路径注册 seek、连接和 SSAP client 回调开启 SLE配置并开始 seek根据公开名称筛选目标并停止 seek连接、配对并交换 SSAP 信息查找服务结构与 property保存 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 资料入口从学习角度看这些资料已经覆盖发现、连接、服务访问与数据收发等基本流程。不过我也不能因为官方提供了示例就直接认为它们已经证明应用层吞吐能够达到产品页列出的峰值空口速率任意距离、遮挡和干扰条件下都有固定时延串口透传示例已经采用最低功耗或最高吞吐参数两块板在不同固件、供电和射频环境下会得到相同结果。所以我会在整个系列中始终区分四类信息类型含义标准定义联盟标准明确规定的机制或术语官方公开信息联盟、芯片或开发板厂商公开说明SDK 可观察实现在固定版本源码中直接看到的 API 与流程实板测试结果在明确环境、参数和方法下得到的数据这一篇完成的是前三类资料的梳理。实板测试要从下一篇开始因此这里不会虚构运行结果。六、这次学习后我先记住五条边界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 所需的技术地图星闪无线通信系统由接入层、基础服务层和基础应用层构成SLE 是星闪接入层的一种技术而不是整个星闪体系基础服务层负责把无线链路组织成发现、连接、服务访问等通用能力H3863sle_uart示例呈现了 announce → seek → 连接与配对 → SSAP 参数交换 → 服务发现 → 数据交互的实现路径SDK API、示例参数、官方规格和实板测试结果必须分开陈述SLE 不能简单理解为“换了名称的 BLE”。写完这篇笔记后我并没有立刻记住所有协议字段但已经知道主要概念位于哪一层、分别解决什么问题以及阅读 SDK 时应该沿着哪条主线追踪。这正是第一篇想要达到的目标。下一篇开始进入实战。我会使用两块 BearPi-Pico H3863分别运行 SLE Server 和 Client完成编译与烧录再通过真实串口日志观察设备发现、连接、配对、服务发现和数据收发过程。参考资料国际星闪联盟《星闪无线短距通信技术SparkLink 1.0》T/XS 10002-2022星闪无线通信系统 低功耗技术要求和测试方法T/XS 10002-2025 V2.1.1接入层 同步低功耗空口 SLE 技术要求和测试方法T/XS 20001-2022基础服务层 设备发现与服务管理BearPi-Pico H3863 官方产品页BearPi-Pico H3863 官方资料入口BearPi-Pico H3863 官方公开源码仓库源码观察基线BearPi 官方公开仓库提交08d2880956249642cc90d7eae9b80ed721646967。仓库后续更新可能改变示例目录、接口或默认参数。在这里插入图片描述
【星闪 SLE 学习笔记 01】深入理解技术体系、协议栈架构与核心通信机制这是我的星闪 SLE 系列学习笔记第一篇。这一篇先不操作开发板而是根据国际星闪联盟公开标准与技术资料、BearPi 官方文档以及 BearPi-Pico H3863 公开 SDK把 SLE 的技术体系、协议分层和基本通信过程梳理清楚。文中不包含实板性能测试也不会把未经验证的速率、时延或功耗宣传数字当成自己的结论。文章摘要本文是星闪 SLE 系列学习笔记的第一篇主要梳理星闪、SLB 与 SLE 的关系介绍接入层、基础服务层和基础应用层的分工并结合 BearPi-Pico H3863 公开 SDK分析 announce、seek、连接与配对、SSAP 服务发现及数据交互的基本流程。文章严格区分标准定义、官方公开信息、SDK 可观察实现和实板结果为后续双开发板实验建立技术基础。关键词星闪SLEBearPi-Pico H3863SSAP协议栈设备发现前言我为什么先从技术体系学起刚开始了解星闪 SLE 时我最先看到的也是各种速率、时延、连接数量和功耗指标。但继续查资料后我发现如果没有先弄清协议体系这些数字很容易被错误地带入开发场景空口峰值不等于应用吞吐示例参数不等于标准规定SLE 也不等于整个星闪系统。所以我决定第一篇先不做性能比较也不急着搭建开发环境而是先解决三个最影响后续学习的问题SLE 在星闪技术体系中处于什么位置两台设备从发现彼此到传输应用数据要经历哪些阶段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没有匹配时继续等待其他结果匹配成功时保存对端地址调用sle_stop_seek()停止寻找在 seek 停止回调中发起连接。相关实现可参考 BearPi 官方公开源码仓库中sle_uart_client.c文件。这段代码让我注意到一个很重要的区别发现设备与选择设备是两件事。SDK 可以报告多个周围设备应用仍要根据名称、地址、公开数据或自己的业务规则决定连接哪一个。当前示例使用名称匹配适合演示流程正式产品是否可以把名称作为唯一筛选条件还需要结合设备身份、安全认证和多设备管理重新设计。3. 连接与配对从“看见”走向受管理的链路发现阶段解决的是“我看到了谁”连接阶段解决的则是“我要与谁建立受管理的通信关系”。收到 seek 结果不代表连接已经成功更不代表双方已经可以按照业务服务交换数据。客户端调用连接接口后通过连接状态回调获得结果。示例在状态变为SLE_ACB_STATE_CONNECTED时检查配对状态如果尚未配对就调用sle_pair_remote_device()。如果链路断开示例会移除已有配对记录并重新开始 seek。配对完成后客户端构造ssap_exchange_info_t请求交换 SSAP 信息其中包括 MTU 和版本。因此这一阶段还可以继续拆成三步建立连接根据当前状态执行配对为后续服务访问交换必要的 SSAP 参数。客户端示例把请求 MTU 设置为 520。这个数字不表示每次 UART 输入都能形成 520 字节的有效空口载荷也不等于端到端吞吐。实际生效值、数据分片和应用有效负载需要结合双方回调和后续实板测试确认。4. 服务发现连接成功还不等于知道对方能做什么连接只建立了通信关系。客户端还需要知道对端提供哪些服务服务中有哪些可访问的数据应使用哪个标识或句柄访问它们H3863 服务端通过 SSAP 接口注册 server依次添加 service、property 和 descriptor然后启动 service。客户端完成 SSAP 信息交换后调用ssapc_find_structure()在指定句柄范围内查找服务结构。SDK 再通过回调返回找到的 service 和 property 信息客户端保存 property handle供后续写入等操作使用。服务端源码、客户端源码为了继续读代码我先用下面这张表记住几个核心对象对象在示例中的作用service将一组相关能力组织成服务结构property服务中可被读、写或用于通知等交互的数据单元descriptor为 property 提供补充描述或配置信息UUID标识应用、service 或 property 等对象handle服务发现后用于定位某个结构元素的句柄SSAPH3863 SDK 中用于服务访问相关操作的一组接口和数据结构这张表是帮助阅读 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 和数据回调。四、读源码时必须适应它是回调驱动的梳理服务端和客户端代码后我发现一个贯穿示例的特点通信过程是异步、回调驱动的。服务端主要路径注册 announce/seek、连接和 SSAP server 回调注册 SSAP server添加 service、property、descriptor并启动 service设置 announce 参数和公开数据启动 announce建链后通过回调处理 MTU、读写及通知/指示。客户端主要路径注册 seek、连接和 SSAP client 回调开启 SLE配置并开始 seek根据公开名称筛选目标并停止 seek连接、配对并交换 SSAP 信息查找服务结构与 property保存 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 资料入口从学习角度看这些资料已经覆盖发现、连接、服务访问与数据收发等基本流程。不过我也不能因为官方提供了示例就直接认为它们已经证明应用层吞吐能够达到产品页列出的峰值空口速率任意距离、遮挡和干扰条件下都有固定时延串口透传示例已经采用最低功耗或最高吞吐参数两块板在不同固件、供电和射频环境下会得到相同结果。所以我会在整个系列中始终区分四类信息类型含义标准定义联盟标准明确规定的机制或术语官方公开信息联盟、芯片或开发板厂商公开说明SDK 可观察实现在固定版本源码中直接看到的 API 与流程实板测试结果在明确环境、参数和方法下得到的数据这一篇完成的是前三类资料的梳理。实板测试要从下一篇开始因此这里不会虚构运行结果。六、这次学习后我先记住五条边界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 所需的技术地图星闪无线通信系统由接入层、基础服务层和基础应用层构成SLE 是星闪接入层的一种技术而不是整个星闪体系基础服务层负责把无线链路组织成发现、连接、服务访问等通用能力H3863sle_uart示例呈现了 announce → seek → 连接与配对 → SSAP 参数交换 → 服务发现 → 数据交互的实现路径SDK API、示例参数、官方规格和实板测试结果必须分开陈述SLE 不能简单理解为“换了名称的 BLE”。写完这篇笔记后我并没有立刻记住所有协议字段但已经知道主要概念位于哪一层、分别解决什么问题以及阅读 SDK 时应该沿着哪条主线追踪。这正是第一篇想要达到的目标。下一篇开始进入实战。我会使用两块 BearPi-Pico H3863分别运行 SLE Server 和 Client完成编译与烧录再通过真实串口日志观察设备发现、连接、配对、服务发现和数据收发过程。参考资料国际星闪联盟《星闪无线短距通信技术SparkLink 1.0》T/XS 10002-2022星闪无线通信系统 低功耗技术要求和测试方法T/XS 10002-2025 V2.1.1接入层 同步低功耗空口 SLE 技术要求和测试方法T/XS 20001-2022基础服务层 设备发现与服务管理BearPi-Pico H3863 官方产品页BearPi-Pico H3863 官方资料入口BearPi-Pico H3863 官方公开源码仓库源码观察基线BearPi 官方公开仓库提交08d2880956249642cc90d7eae9b80ed721646967。仓库后续更新可能改变示例目录、接口或默认参数。在这里插入图片描述
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
