产品验证¶

这些教程默认你已掌握子系统集成中的内容：能够完成外设启动调试、接入中间件，并且已亲身遇到过至少一个共存问题。本阶段关注的是如何把“能运行的演示”推进到“可以交付的产品”，包括实测功耗、更新失败后可恢复的 OTA、自定义硬件启动调试、崩溃分析、多连接蓝牙和可复用驱动开发。

产品验证不再主要依赖照抄某一个示例，而是强调建立证据链。建议你为每个教程都保留记录：开发板版本、SDK 版本、示例起点、测试搭建、预期结果、实际结果，以及期间做过哪些改动。

当你的目标不再只是让功能运行一次，而是需要量化功耗、确保更新失败后能够恢复、重复完成自定义硬件启动调试，并为非正常路径下出现的问题留存证据时，就应进入本系列。

SiFli-SDK 示例的路径和支持平台可能随版本变化。构建前，请查看每个示例当前列出的支持平台，以及对应的板级硬件和配置要求；某个练习受支持，不代表同一开发板也支持其他示例或所有功能组合。

调优低功耗模式与唤醒源¶

目标： 用真实测量证明固件具备低功耗表现，而不是因为代码里调用了 sleep 函数就默认它“应该省电”。

时间： 2 小时以上，外加测量搭建时间

起点示例： example/pm/classical、example/pm/raise_wrist

按照低功耗概览搭建电流测量环境。
记录启动、活动态、已连接空闲、灭屏空闲，以及深度睡眠（Deep Sleep，如支持）下的基线电流。
从 classical PM 示例入手，找出系统在哪里通过 rt_pm_request(PM_SLEEP_MODE_IDLE) 阻止进入比 IDLE 更深的低功耗模式，以及之后在哪里通过 rt_pm_release(PM_SLEEP_MODE_IDLE) 解除这项限制。还要检查外设处于活动状态时，驱动框架是否会自动阻止系统睡眠。
再看 raise-to-wake 示例，了解它如何采样加速度计、识别抬腕动作、点亮显示屏并重新进入睡眠。应核对该示例实际采用的采样和唤醒流程，不要预设它使用了中断。
把这种低功耗设计思路迁移到自己的产品中：在硬件和驱动支持的前提下，优先采用中断或事件驱动方式，避免不必要的定时器和轮询。
每改动一次就重新测量一次。
如果深睡电流没有预期那么低，使用 list_thread、list_device、PM 日志和唤醒源诊断信息，定位仍在活动的子系统。

成功标准： 固件能进入预期低功耗状态，电流结果在多次测试中可重复，而且唤醒源都是有意设计的，而不是偶然触发的。

排查思路： 如果某次测试功耗很好、下一次又变差，重点检查错误路径、重连路径、显示关闭流程、音频会话清理，以及启动后动态创建的定时器。

你学到的内容： 如何从“理论上应该低功耗”转向“已经实测的低功耗”，以及如何定位被悄悄遗留未释放的 PM 请求。

通过 BLE 增加 OTA 固件更新¶

目标： 在没有有线连接的情况下完成现场固件更新。

时间： 2 小时

起点示例： example/ble/peripheral_with_ota

构建并烧录带 OTA 的外设示例。
在尝试升级前，先确认普通 BLE 外设功能仍然正常。
触发一次 OTA 更新，并确认设备能启动新镜像。
仅在具备明确恢复路径的测试设备上逐项验证中断场景，例如在传输过程中断开连接或让设备移出通信范围。除非开发板文档和产品恢复设计明确允许，否则不要断电测试。
验证产品在更新中断或镜像被拒绝后实际实现的行为，例如重试、续传、进入恢复模式或回滚。只有当启动流程和分区设计确实实现回滚时，才将回滚列为验收要求。
分别在以下场景下测试 OTA：设备中留有过期的绑定信息、手机端已“忘记”该设备，以及设备重启后。
如果你的产品已经使用 PAN 传输数据，要把 PAN OTA 作为单独设计路线评估。

成功标准： 更新成功后设备能启动新镜像；更新中断或镜像被拒绝后，设备按产品文档规定的恢复策略处理；用户也能明确判断设备当前状态。不要默认所有 OTA 方案都支持回滚。

排查思路： 检查分区布局、镜像签名或完整性校验（如果有）、启动选择与恢复行为、设计中是否实现回滚、传输期间的连接参数，以及绑定信息或其他存储数据是否能在升级后保留。

你学到的内容： 分区布局、镜像校验、启动选择和恢复策略如何共同决定 OTA 行为，以及为什么只验证升级成功并不能证明中断后可恢复。

自定义显示模组启动调试¶

目标： 适配一个新的 LCD、AMOLED、EPD 或内存型显示屏（memory display），而不是只用 SDK 已支持的参考屏。

时间： 3 小时以上

起点示例： SDK 中和目标面板最接近的显示驱动

收集面板数据手册、初始化序列、时序参数、接口类型、复位要求和上电顺序。
确认选定的 SF32 器件和封装确实支持所需接口与引脚。
复制最接近的现有显示驱动，并替换面板专用的初始化序列和寄存器映射。
先实现纯色填充。在面板能稳定显示简单图案之前，不要急着调试 LVGL 控件。
验证颜色顺序、字节序、方向、地址窗口以及局部刷新行为。
再把“子系统集成”练习 2 中使用的 LVGL 加回来。
只有在所选芯片、显示通路、驱动和 SDK 均支持时，才逐项启用 DMA、局部刷新和 ePicasso 加速。
测试灭屏、睡眠、唤醒和重新初始化路径。

成功标准： 面板在冷启动和复位后都能可靠初始化，能够正确显示已知图案，并且在睡眠和唤醒循环后不会出现画面损坏。

排查思路： 如果纯色填充都不对，先检查像素格式、MADCTL/方向位、字节序、命令/数据连线、复位时序和电源轨的上电时序，再去改 UI 层代码。

你学到的内容： 如何将电气和时序正确性与 UI 框架配置问题拆开处理。

分析 CPU 占用并定位崩溃¶

目标： 调试那些不容易在在线调试器下稳定复现的问题。

时间： 2 小时

起点示例： example/system/cpu_usage_profiler、example/system/coredump

使用 CPU 使用率分析器（CPU usage profiler）示例，分析一次你在“子系统集成”阶段组合的负载。
找出究竟是哪一个任务消耗了 CPU 时间，并判断是否符合预期。
在练习分支或可随时丢弃的示例里人为制造一个受控故障，并捕获核心转储（core dump）。
使用 SDK 提供的转储（dump）分析工具定位故障函数和调用栈。
把崩溃上下文与 list_thread 输出、日志和最近事件对照起来。
去掉故意引入的故障后，如果手头有真实的间歇性问题，再按同样流程做一次。

成功标准： 你能依据采集到的证据解释一个性能问题和一个崩溃问题，而不是停留在猜测层面。

排查思路： 在解读调用栈前，要先确认符号文件和已烧录二进制一致，日志里包含固件版本，并且你清楚当前编译优化级别的影响。

你学到的内容： 如何主动分析慢路径，以及如何对难以在线捕获的故障进行事后转储分析。

构建多连接 BLE 产品¶

目标： 支持一个以上的 BLE 角色或同时连接。

时间： 2 小时

起点示例： example/ble/central_and_peripheral、example/ble/multi_connection

从你在“子系统集成”练习 3 中已经验证的 BLE 外设行为开始。
在此基础上再增加一个中心（central）角色，例如一边作为手机的外设，一边作为某个传感器附件的中心设备。
再扩展到多个并发连接。
记录每条链路的连接间隔、从机延迟（slave latency）、监督超时（supervision timeout）和通知（notification）速率。
在归咎于应用代码之前，先用 SDK 吞吐示例建立一个吞吐基线。
测试重连、手机睡眠、附件丢失，以及同时高频通知突发的情况。

成功标准： 所有目标角色都能稳定连接、断开和重连，而且连接参数在组合负载下仍保持稳定。

排查思路： 重点看参数请求是否互相冲突、通知流量是否过大、应用回调是否阻塞，以及功耗策略是否让主 CPU 因每个链路事件而被唤醒。

你学到的内容： SiFli-SDK 在受支持的 BLE 配置中可以组合外设（peripheral）和中心（central）角色，部分配置还支持多个并发连接。具体角色和连接数取决于目标芯片、协议栈配置及示例支持；多个连接共享无线调度时，连接参数之间的取舍会相互影响。

编写自定义 RT-Thread 设备驱动¶

目标： 将一个没有现成 SDK 驱动的外设，按照 RT-Thread 设备（device）模型集成为正式驱动，而不是写成一次性的应用层硬编码。

时间： 3 小时以上

起点示例： SDK 应用开发指导，加上架构上最接近的现有驱动

先梳理 SDK 如何组织开发板定义、引脚复用（pin mux）、时钟和外设驱动。
从在架构上最接近目标外设的驱动开始改。
把总线访问、设备注册、配置流程和应用逻辑明确分层。
注册设备，并确认它能出现在 list_device 中。
像之前操作 ADC、PWM、I2C 和存储设备那样去验证它。
补上缺失硬件、非法参数、超时，以及挂起/恢复（suspend/resume）的错误处理。
如果这个驱动具备复用价值，就把它整理成 SDK 组件，而不是在产品之间复制粘贴。

成功标准： 应用代码可通过标准 RT-Thread 设备模型找到并使用这个驱动，而且它在初始化、使用、错误处理和睡眠/唤醒路径上都表现稳定。

排查思路： 如果驱动只能在某一个应用文件里工作，很可能说明它绕过了设备模型。继续重构，直到它用起来像 SDK 内置设备一样自然。

你学到的内容： 如何干净地扩展 SDK 生态，而不是给未来留下维护负担。

产品验证发布检查清单¶

功耗数据已经实测、可重复，并且与明确命名的测试场景绑定。
已依据产品文档规定的策略验证 OTA 成功、完整性检查和中断恢复；只有设计实现了回滚时，才将回滚列为已验证能力。
自定义显示启动调试已先通过图案验证，再逐步引入 LVGL 的复杂功能。
性能分析和核心转储工作流已记录在团队文档中。
多连接蓝牙已经覆盖重连、手机端和附件端边界场景。
自定义驱动遵循 RT-Thread 设备模型，并正确处理睡眠和唤醒。
组合负载测试已覆盖显示、蓝牙、存储、音频、传感器，以及适用时的 AI 工作负载。

下一步去哪里¶

到这里，你已经掌握了外设与中间件集成、共存问题意识、功耗管理、OTA、自定义硬件启动调试、事后崩溃分析和驱动集成等方法。接下来，示例目录和图形概览可作为按需查阅的参考，无须按顺序逐篇通读。

最后更新: 2026-10-21