登录社区云,与社区用户共同成长
邀请您加入社区
一、为什么要区分 BLE 直连与 BLE+Wi-Fi Combo 统一互联 3.0 的应用终端可以采用不同的网络形态,但首次配网通常都从近端 BLE 开始。BLE 的职责是让配置对端发现设备、建立安全会话、完成设备认证并下发长期配置;它并不天然等同于设备后续的运行期网络。 本文以 WS63 应用终端为例,整理两种常见形态: 两种形态不能被理解为“两套完全独立的协议”。它们的前半段应尽可能复用同一套
嵌入式MQTT开发中,通信稳定性往往不取决于协议本身,而取决于数据流如何在不同线程间流动。本文从数据流视角,梳理MQTT语音导航模块的设计思路。 一、整体数据流 云端MQTT Broker↓设备MQTT客户端(tcpip线程回调)↓消息队列↓工作线程↓地图引擎接口↓JSON构造↓tcpip_callback↓MQTT发布↓云端 text 整个链路是单向异步的:下行指令从云端到达设备,在工作线程中完
一、项目背景 最近在做一个车载仪表的语音导航功能,核心需求是通过MQTT协议实现云端与设备的双向通信——云端下发搜索指令,设备端搜索POI后上报结果,再通过语音或旋钮选择目的地和路线,最终完成导航启动。 项目基于OpenHarmony L0轻量系统,跑在D21X开发板上。MQTT作为轻量级物联网协议,天然适合这种资源受限、需要实时通信的场景。 二、整体架构 整个模块分为三层: MQTT通信层:负责
一、前言 & 背景 开发 OpenHarmony 应用时,数据存内存里会碰到三个典型痛点: 进程被杀数据就没了:用户配置的 WiFi 名称、设备参数、开关状态,App 一退出全部丢失,每次都要重新配置;跨页面/跨启动无法共享:A 页面保存的配置,B 页面和下次启动都拿不到;查询效率低:设备列表、历史记录这类结构化数据,如果每次启动都重新扫描/重新组装,体验很差。 OpenHarmony 提
一、为什么需要公共事件? 开发 OpenHarmony 应用时,组件之间经常需要传递"状态变化"消息,典型场景: 跨页面通知:A 页面设备状态变了,B 页面需要同步刷新,但两个页面没有直接的引用关系;跨 Ability/跨应用广播:一个模块采集到的数据,需要分发给多个订阅方(如测试框架收集用例结果);监听系统事件:蓝牙开关变化、网络连接变化、屏幕亮灭等系统级事件。 如果全部用全
OpenHarmony 后台服务(ServiceExtensionAbility)开发总结 文档概述 说明: 本文结合 OpenHarmony 官方文档《ServiceExtensionAbility(仅对系统应用开放)》与后台服务工程的开发经验整理而成;以下内容包含了个人理解,仅供参考,如有不合理处,请联系笔者修改。 一、前言 & 背景 在很多 OpenHarmony 产品上,应用需要处
文档概述说明:1.文章由移远通信技术股份有限公司提供2.以下内容包含了个人理解,仅供参考,如有不合理处,请联系笔者修改 引言:标准系统启动与孵化问题的排查往往令人望而生畏——链条长、模块多、现象相似但根因各异。本文提供一套经过实战检验的排查方法论,通过「先定链、再定阶段、最后定代码点」的三步法,帮助开发者快速将复杂问题收敛到具体模块和失败点。无论您是面对 SA 起不来、appspawn 超时还是
OpenHarmony 采用 repo 工具统一管理数百个 Git 子仓库,掌握 repo 的拉取与编译流程是参与 OpenHarmony 开发的第一步。本文从环境准备、源码拉取、编译构建到常见问题排查,带你完整走通全流程。 一、环境准备 1.1 宿主机要求 推荐使用 Ubuntu 20.04 LTS 或 Ubuntu 22.04 LTS,这是社区
ARGB8888 → RGB565 像素格式转换详解 在嵌入式 Linux 显示开发中,ARGB8888 到 RGB565 的像素格式转换是一项高频操作。无论是帧缓冲区(framebuffer)输出、DRM/KMS 显示管线,还是 GUI 渲染引擎,都可能涉及这一转换。本文从原理到实现,系统梳理这一转换的方方面面。 一、两种格式的基本结构 ARGB8888(32位/像素) 每个像素占用 4 字节,
1. 为什么“编译成功”仍可能烧出错误镜像 OpenHarmony 设备开发中,经常出现一种看似矛盾的现象:源码已经修改,完整构建也输出 build success,烧录后板端却仍表现为旧问题。 原因通常不在编译器,而在交付链路: 源码 -> GN/Ninja 中间产物 -> kernel / rootfs / FIT -> 产品 OUT -> Windows 烧录目录 -