openharmony

nullregedit12 天前
openharmony·语音交互·开源鸿蒙·ws63·ci1302
OpenHarmony 小鸿 AI 开发实战 10:CI1302 语音上行的 UART 帧、Opus 与 VADCI1302 不是把一段 WAV 文件一次性交给 WS63。它通过 UART2 连续发送带帧头、命令字、payload 长度和帧尾的协议帧:唤醒事件触发会话,0x0105 携带一小帧 Opus,0x0106 表示本段 VAD 结束。WS63 在中断回调里只收字节,在任务中解析,再把 Opus 交给 Agent 通过 WebSocket 上行。
nullregedit16 天前
openharmony·嵌入式开发·开源鸿蒙·ws63·burntool
OpenHarmony 小鸿 AI 开发实战 04:WS63 BurnTool 烧录、Loader、导出与回滚上一篇已经把 OpenHarmony mini 产品构建到 WS63 .fwpkg 的过程拆开,这一篇继续处理构建之后最容易混淆的部分:BurnTool 到底证明了什么、Loader 在什么时候参与、怎样做完整内部 Flash 导出,以及出问题后如何回到已知可工作的固件。本文依据小鸿项目自带的 Windows 烧录指南、本地真实固件包和一份已经完成长度、内容分布与 SHA-256 核对的 4 MiB 原始备份整理,不把官方操作说明、历史烧录结果和本轮文件核验混成同一条证据。
nullregedit16 天前
openharmony·gpio·故障排查·开源鸿蒙·ws63
OpenHarmony 小鸿 AI 开发实战 05:烧录成功仍黑屏的 GPIO14/PWR_ON 故障复盘这次故障最容易误判的地方,是 BurnTool 已经完成写入,设备却黑屏。若只看下载结果,很容易继续怀疑 USB 线、显示屏排线、ST7789 驱动或包格式;但真实根因落在更靠前的板级初始化:试验固件把 GPIO14 当成中键候选进行配置,而这块 WS63 V1 板上 GPIO14 属于 PWR_ON 电源保持/显示供电相关保留脚。
nullregedit17 天前
openharmony·嵌入式开发·开源鸿蒙·esp32-p4·ws63
OpenHarmony 小鸿 AI 开发实战 01:先认对工程,WS63 与 ESP32-P4 路径怎么选拿到小鸿 AI 源码后,最先要解决的不是“怎样改界面”,而是“当前硬件究竟由哪套工程生成固件”。同一棵源码树里同时存在 xiaohong、xiaohong-se 和 xiaohong-p4,三个名字很接近,却分别对应不同硬件角色、构建入口和产物格式。选错目录以后,即使代码能编译,也可能根本没有进入正在烧录的镜像。
北京麟卓23 天前
openharmony·安卓应用兼容
卓奕引擎×OrangePi 5B开发板 | 面向开源鸿蒙的一站式安卓兼容验证方案想实现开源鸿蒙安卓应用兼容的厂商,90%都在这些事上踩过坑:从零研发兼容层,砸了几十万、耗了大半年,效果还不达预期;
Industio_触觉智能1 个月前
嵌入式硬件·物联网·硬件架构·智能硬件·openharmony·开源鸿蒙
开源鸿蒙OpenHarmony再进阶,OneConnect规范即将升级为国家级行业标准近日,工业和信息化部科技司正式发布标准立项公示公告,《开源鸿蒙设备统一互联接入与控制接口》核心标准成功进入立项征求意见阶段。本次立项以全球智慧物联网联盟(GIIC)OneConnect三项团体标准为核心基础,标志着开源鸿蒙互联互通规范正式从行业联盟共识,升级为国家级权威技术标尺,是OpenHarmony生态标准化、规模化落地的里程碑突破。。
北京麟卓1 个月前
openharmony·安卓兼容
鸿蒙平板生态建设遇阻?卓奕引擎:安卓应用快速迁移+迁移成本直降80%以上作为鸿蒙平板厂商,您是否正面临这样的困境:01平板设备已经量产,但应用生态匮乏。客户拿到设备,最先吐槽的是常用软件装不上。
Industio_触觉智能2 个月前
嵌入式硬件·openharmony·开源鸿蒙·核心板·鸿蒙开发板·rk3576·农机平板
瑞芯微RK3576落地智能农业新生态,鸿蒙农机平板应用场景拓展现代农业比拼精准度与作业效率,农机驾驶室里的中控平板,早已不再只是一块简单的显示屏幕。市面大量老旧农机配套触控屏多为消费设备改造而来,扛不住田间暴晒霜冻、颠簸震动,无AI检测识别、无统一设备组网能力,严重制约精细化农事落地。
fakerth2 个月前
操作系统·openharmony
【OpenHarmony】communication_ipc模块https://gitee.com/openharmony/communication_ipccommunication_ipc 是 OpenHarmony 操作系统的**进程间通信(IPC)与远程过程调用(RPC)**基础框架组件,属于 foundation/communication/ipc 子系统。
Industio_触觉智能3 个月前
人工智能·嵌入式硬件·边缘计算·openharmony·开源鸿蒙·瑞芯微·rk3576
瑞芯微RK3576迷你工控整机边缘计算盒子规格书参数配置性能说明,触觉智能IPC7609触觉智能研发的RK3576整机,完整型号为IDO-IPC7609-V1,可用于边缘计算、机器视觉、算力盒子、工业控制等。
深开鸿3 个月前
人工智能·openharmony·政务
福田区全栈式鸿蒙AI数智机关入选全市首批OR示范应用项目,深开鸿筑牢政务安全底座5月13日,在第五次深圳市OR大会暨软信投促大会上,福田区机关事务管理局申报的全栈式鸿蒙AI数智机关,作为全市首批OR示范应用项目亮相,让区委大院成为备受瞩目的“实景展厅”,吸引了24家企业组团实地调研。
fakerth3 个月前
操作系统·openharmony
【OpenHarmony】startup_init 模块源码地址:https://gitee.com/openharmony/startup_initstartup_init 主模块是系统用户态的启动入口(pid=1),负责从早期引导到系统服务拉起的全链路编排。核心目标如下:
weixin_386468963 个月前
c语言·c++·git·python·vim·harmonyos·openharmony
openharmony 6.0编译rk3568过程记录目标 openharmony 6.0编译rk3568虚拟机信息 系统信息ubuntu@ubuntu:~/tmp$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal
小菜刀_3 个月前
openharmony·loongarch·liteos-m
OpenHarmony LiteOS-M 产品参数全为空?一起因初始化顺序引发的调试实录在龙芯 LS2K300 平台(OpenHarmony 6.1,LiteOS-M 内核)上运行 HCTest 测试框架时,系统输出的产品参数信息全部为空值或占位符 "****":
九流下半4 个月前
签名·openharmony·系统信息·系统应用签名
OpenHarmony签名指南:自动与手动详解openharmony 签名有两种情况:自动签名和手动签名。手动签名又分两种:普通应用签名和系统应用签名
特立独行的猫a4 个月前
harmonyos·openharmony·命令行·openssh·vcpkg·鸿蒙pc
使用 vcpkg 为OpenHarmony(鸿蒙PC)构建 OpenSSH 命令行工具本文面向需要构建可运行在OpenHarmony或 鸿蒙PC(arm64-ohos 等 triplet) 上的openssh命令行工具的开发者。通过使用vcpkg的方式构建。同时说明 OpenSSH 是什么、为何用 vcpkg构建、如何构建、产物在哪、以及本 port 在适配过程中处理过的典型问题。
特立独行的猫a4 个月前
华为·harmonyos·openharmony·vcpkg·三方库移植
HarmonyOS 鸿蒙PC三方库移植:vcpkg方式的 Port 脚本编写简明教程本文面向鸿蒙三方库移植适配,需要在 vcpkg 中维护或新增端口的开发者,结合通用约定与本仓库中 ports/libpng、ports/curl、ports/openssl、ports/libmediainfo 等 portfile.cmake 里的常见写法,说明如何组织端口脚本、与 vcpkg.json 配合,以及处理特性、平台差异与安装收尾工作。
特立独行的猫a4 个月前
harmonyos·移植·openharmony·vcpkg·crshpad
HarmonyOS / OpenHarmony 平台三方库移植:使用vcpkg 移植 Crashpad 过程实战总结本文记录了使用 vcpkg 中 crashpad 移植到 arm64-ohos 的完整过程。 其中报错不断,出现各种问题。不过最终都一一解决了,这里记录下来。目标是让后续同类移植工作可以少走弯路,遇到类似报错时能快速定位。
特立独行的猫a4 个月前
harmonyos·openharmony·vcpkg·三方库移植·鸿蒙pc·lycium_plusplus
HarmonyOS鸿蒙三方库移植:选 vcpkg 还是 lycium_plusplus?两种“框架化”方案对比如果你做过原生 C/C++ 在移动/嵌入式类系统上的落地,多半经历过同一种疲惫:同一个开源库,在 Linux 上 cmake && make 很顺滑,一旦换成交叉编译,立刻变成“每个库一套脚本、每个库一坑”。鸿蒙(HarmonyOS / OpenHarmony 语境下也常写作 OHOS)这条线也不例外——图像、网络、压缩、国际化、字体渲染……依赖一多,可复现构建和依赖拓扑就会从“工程问题”升级成“团队治理问题”。