完全常规Windows环境，构建一套完整的鸿蒙南北向远程温湿度监控系统：下位机[Hi3861(OpenHarimuny-LiteOS) + SHT30]采集环境温湿度，经 WiFi/UDP 上报；上位机（HarmonyOSnext APP）实时显示、下发控制命令；并可用 PC 端网络调试助手替代任一端构成测试闭环。

1 Windows开发环境构建

安装以下工具软件：

1 DevEcoStudio--北向APP IDE

2 网络调试助手

3 Python3.7~3.9--南向编译基础依赖

表1 应用开发环境要求列表

项目

取值

上位机 IDE

DevEco Studio 26.0.0（Windows 64 位）

上位机 SDK

HarmonyOS 26.0.0（API 26）

上位机语言

ArkTS（Stage 模型）+ ArkUI 声明式

上位机构建

hvigor

下位机 SDK

OpenHarmony 1.1.4 LTS（Hi3861，LiteOS-M）

下位机硬件

HiSpark WiFi IoT 开发板 + SHT30 模块

下位机语言

C（C99）

通信

UDP over WiFi（IPv4）

2 整体方案规划设计

2.1 整体设计

南向Hi3861外挂SHT30温湿度模块，构成简易终端HiSpark。

WiFi局域短距离无线组网，UDP通信。

纯血鸿蒙APP掌上监护。

C/S架构采集控制系统：APP--客户端C，终端--服务器S。

2.2 IMA-DeepSeek借力

咨询提示词：1 给出远程SHT30温湿度计的鸿蒙APP监控详细设计软件工程包和相应的设计说明及其测调试步骤：Windows下DevEco Studio26.0.0开发，UDP通信，网络调试助手代替远程SHT30温湿度计构成测试闭环。2 给出基于Hi3861及其HiSpark的底层鸿蒙南向SHT30温湿度计的驱动编码设计及其应用编码，包括整个工程目录结构与文件，能够配合该鸿蒙APP远程监控运行，使用上述制订的UDP通信协约。3 注意UDP通信协约的统一与上下位编解码处理一致。

图1 温湿度监护项目的IMA-DS借力截图

2.3 通信协约

1) 传输层与网络参数

表2 温湿度监护项目的传输网络参数列表

项目

取值

说明

传输协议

UDP

无连接数据报，不保证可达，靠周期上报+心跳维护状态

设备侧监听端口

8000

接收 APP 下发的命令

APP 侧监听端口

8001

接收设备上报的数据与心跳

设备上报目标地址

APP_IP : 8001

APP_IP 由 APP 界面显示，烧录前写入固件配置

APP 下发目标地址

DEVICE_IP : 8000

DEVICE_IP 由 APP 自动从收到的数据包源地址学习，也可手工指定

单帧最大长度

70 字节

远小于 MTU，无需分片

设备默认上报周期

2 秒

运行期可通过 0x81 命令修改（1~3600 秒）

设备心跳周期

5 秒

固定，不可修改

APP 离线判定

10 秒

连续 10 秒未收到任何帧即判定设备离线

设计取舍说明：采用 UDP 而非 TCP，是因为工业现场遥测场景下"最新数据优先"，丢一两帧不影响监控结论，且无需维护连接状态机；代价是需要心跳+超时机制来判定在线状态，本协议已覆盖。

2) 字节序（Byte Order）

全部多字节整数一律采用大端（Big-Endian，网络字节序）：高字节在前，低字节在后。

  • 温度 25.36℃ → 整数值 2536 → 大端字节 09 E8
  • 湿度 60.12%RH → 整数值 6012 → 大端字节 17 7C

3) 帧结构（通用帧）

所有消息共用一种帧格式：

图2 温湿度监护项目的帧结构图

表3 温湿度监护项目的帧结构列表

偏移

长度

字段

说明

0

1

SOF1

固定 0xAA

1

1

SOF2

固定 0x55

2

1

MsgType

消息类型

3

1

Seq

帧序号，0x00~0xFF 循环递增，用于丢帧统计与应答匹配

4

1

Len

Payload 长度，取值 0~64

5

Len

Payload

载荷，格式见第 7 章

5+Len

1

Checksum

校验字节，算法见第 5 章

4) 校验算法

采用单字节累加和取低 8 位（简单、可手工计算、便于网络调试助手验证）：

Checksum = ( MsgType + Seq + Len + Payload[0] + ... + Payload[Len-1] ) & 0xFF

5) 消息类型定义

a) 上行消息（设备 → APP）

表4 温湿度监护项目的上行消息列表

MsgType

名称

Payload 长度

说明

0x01

TEMP_HUMI_REPORT

5

温湿度数据上报

0x02

HEARTBEAT

0

心跳/在线保活

0x04

CMD_ACK

2

对下行命令的应答

b) 下行消息（APP → 设备）

表5 温湿度监护项目的下行消息列表

MsgType

名称

Payload 长度

说明

0x81

SET_PERIOD

2

设置上报周期

0x82

QUERY_ONCE

0

立即查询一次

0x83

SET_HEATER

1

加热器开关

0x84

SET_ALARM

8

设置告警阈值

0x85

REBOOT

0

设备重启

命名约定：0x0x 段为上行，0x8x 段为下行。APP 收到 0x8x 或设备收到 0x0x 应丢弃并可选回错误应答。

6) 载荷（Payload）格式定义

a) 0x01温湿度数据上报--Payload = 5字节

表6 温湿度监护项目的数据载荷列表

Payload 偏移

长度

字段

类型/单位

取值范围

0

2

Temperature

int16 大端，单位 0.01℃，补码

-4000 ~ 12500（-40.00 ~ 125.00℃）

2

2

Humidity

uint16 大端，单位 0.01%RH

0 ~ 10000（0.00 ~ 100.00%RH）

4

1

Status

位域，见下表

—

Status 位域定义：

表7 温湿度监护项目的状态域列表

位

掩码

名称

置 1 含义

bit0

0x01

HEATER_ON

加热器已开启

bit1

0x02

ALARM_T_HIGH

温度超上限

bit2

0x04

ALARM_T_LOW

温度低于下限

bit3

0x08

ALARM_H_HIGH

湿度超上限

bit4

0x10

ALARM_H_LOW

湿度低于下限

bit5

0x20

保留

恒 0

bit6

0x40

保留

恒 0

bit7

0x80

SENSOR_FAULT

传感器读取失败（此时温湿度字段填最后一次有效值）

b) 0x02心跳--Payload = 0字节

仅表示设备存活。APP 以此刷新在线状态。不使用载荷携带IP--APP 直接取 UDP 数据报的源地址作为设备地址。

c) 0x04命令应答--Payload = 2字节

表8 温湿度监护项目的命令应答列表

Payload 偏移

长度

字段

说明

0

1

AckMsgType

被应答的下行 MsgType，如 0x81

1

1

Result

0x00=成功；0x01=参数错误；0x02=不支持该命令；0x03=执行失败

d) 0x81设置上报周期--Payload = 2字节

表9 温湿度监护项目的设置上报周期列表

Payload 偏移

长度

字段

说明

0

2

PeriodSec

uint16 大端，单位秒，有效范围 1 ~ 3600

e) 0x82立即查询--Payload = 0字节

设备收到后立即采集并发送一帧 0x01，不受上报周期限制。

f) 0x83加热器开关--Payload = 1字节

表10 温湿度监护项目的加热器开关设置列表

Payload 偏移

长度

字段

说明

0

1

On

0x00=关闭；0x01=开启

HiSpark 板载无加热器时，固件以 GPIO 驱动 LED 指示代替，状态位 HEATER_ON 同步更新。

g) 0x84设置告警阈值--Payload = 8字节

表11 温湿度监护项目的警告阀值设置列表

Payload 偏移

长度

字段

类型/单位

0

2

TempHigh

int16 大端，0.01℃

2

2

TempLow

int16 大端，0.01℃

4

2

HumidityHigh

uint16 大端，0.01%RH

6

2

HumidityLow

uint16 大端，0.01%RH

设备校验TempLow<TempHigh且HumidityLow< HumidityHigh，非法则应答Result=0x01且不生效。

h) 0x85重启--Payload = 0字节

设备回 0x04 应答后延时 200ms 调用 hi_reboot()。

7) 交互时序

​

 图3 温湿度监护项目的通信交互图

APP 侧：

绑定 8001 → 收到任意帧 → 刷新"在线"，记录源 IP 为设备地址

连续 10s 无帧 → 标记"离线"

收到 0x01 → 更新温湿度/告警显示

收到 0x04 → 更新对应命令的执行结果

7) 示例报文（十六进制，可直接粘贴到网络调试助手验证）

a) 上行：温湿度上报（25.36℃ / 60.12%RH / 无告警 / Seq=1）

AA 55 01 01 05 09 E8 17 7C 00 8B       (11 字节)

b) 上行：心跳（Seq=1）

AA 55 02 01 00 03                       (6 字节)

c) 上行：应答（对 0x81 成功，Seq=1）

AA 55 04 01 02 81 00 88                 (8 字节)

d) 下行：设置上报周期 2 秒（Seq=1）

AA 55 81 01 02 00 02 86                 (8 字节)

e) 下行：立即查询（Seq=1）

AA 55 82 01 00 83                       (6 字节)

f) 下行：加热器开（Seq=1）

AA 55 83 01 01 01 86                     (7 字节)

g) 下行：设置阈值（上限30.00℃/下限10.00℃/上限70.00%/下限30.00%，Seq=1）

AA 55 84 01 08 0B B8 03 E8 1B 58 0B B8 71   (14 字节)

h) 异常帧（校验错，应被丢弃）

AA 55 01 01 05 09 E8 17 7C 00 FF       (校验位故意错误 → 丢弃)

4 系统总体架构

 图4 温湿度监护项目的系统总体架构图

核心设计原则：协议层独立于业务层。两端都把编解码收敛到单一文件（`Protocol.ets` / `protocol.c`），业务代码只处理结构化的 `Frame` / `proto_frame_t`，绝不直接操作字节。这是保证"上下位编解码一致"的工程前提。

3 北向鸿蒙APP开发调试

3.1 工程目录结构

harmony_app/
 ├── build-profile.json5              工程级构建配置（API 26）
 ├── hvigorfile.ts
 ├── oh-package.json5
 ├── hvigor/hvigor-config.json5
 ├── .gitignore
 ├── AppScope/
 │   ├── app.json5                    应用信息（包名/版本/图标）
 │   └── resources/base/
 │       ├── element/string.json
 │       └── media/app_icon.png
 └── entry/                         主模块
      ├── build-profile.json5
      ├── hvigorfile.ts
      ├── oh-package.json5
      ├── obfuscation-rules.txt
      └── src/main/
          ├── module.json5              模块配置 + 权限声明
          ├── ets/
          │   ├── entryability/EntryAbility.ets  应用入口
          │   ├── entrybackupability/EntryBackupAbility.ets
          │   ├── common/
          │   │   ├── Protocol.ets            协议编解码（真源落地）
          │   │   ├── Constants.ets           全局常量
          │   │   └── Logger.ets             日志
          │   ├── model/
          │   │   ├── FrameType.ets          帧类型定义与长度约束
          │   │   └── DeviceState.ets         设备状态模型
          │   ├── service/
          │   │   ├── UdpService.ets          UDP 收发
          │   │   └── NetUtils.ets            本机 IP 获取
          │   ├── viewmodel/MonitorViewModel.ets  状态编排
          │   ├── components/
          │   │   ├── MetricCard.ets          数值卡（@Prop）
          │   │   ├── StatusChip.ets          状态标签（@Prop）
          │   │   ├── ControlPanel.ets         控制区（@Link）
          │   │   └── LogPanel.ets            日志区（@Link）
          │   └── pages/Index.ets            主页面
          └── resources/
               ├── base/element/{string,color}.json
               ├── base/media/{icon,startIcon}.png
               ├── base/profile/{main_pages,backup_config}.json
               ├── en_US/element/string.json
               └── zh_CN/element/string.json

3.2 分层架构

表12 温湿度监护项目的分层架构说明列表

层

文件

职责

依赖方向

表现层

Index.ets + components/*

渲染温湿度、状态、控制项、日志

只依赖 ViewModel

逻辑层

MonitorViewModel.ets

维护设备状态、在线判定、日志缓冲、命令构造入口

依赖 Service + Protocol

通信层

UdpService.ets / NetUtils.ets

Socket 生命周期、收发字节流

依赖 Protocol

协议层

Protocol.ets

帧编解码、流式状态机、定点换算

无依赖（纯函数）

单向数据流：UDP 字节 → Protocol 解帧 → ViewModel 更新状态 → UI 刷新； 反向：UI 事件 → ViewModel 构造帧 → Protocol 封帧 → UdpService 发送。

3.3 协议层：Protocol.ets

  • 常量：SOF1/SOF2/MAX_PAYLOAD_LEN/HEADER_LEN/MIN_FRAME_LEN/DEVICE_PORT/APP_PORT/...，与 protocol.h 一一对应。
  • MsgType 枚举：8 个值，与固件严格相同。
  • checksum(bytes, start, end)：闭区间累加和 & 0xFF；封帧时区间为 [2, 4+len]。
  • buildFrame(msgType, seq, payload): Uint8Array：按协议 9.1 七步封帧，返回 6+len 字节。
  • FrameParser 类：
    • push(chunk: Uint8Array): Frame[] —— 喂入字节流，返回本次能解出的全部完整帧；
    • 内部 number[] 缓冲 + 滑动丢弃，实现协议 9.2 的 a~h 状态机：定位 SOF1 → 校验 SOF2 → 头完整性 → Len>64 丢弃 → 整帧完整性 → 校验比对（失败丢 1 字节）→ 提取字段 → 消费 frameLen。
    • 天然支持半帧等待、粘连帧连续出帧、脏字节滑动、非法帧与校验错丢弃。
  • 结构化编解码：parseReport / parseAck / buildSetPeriod / buildQueryOnce / buildSetHeater / buildSetAlarm / buildReboot。
  • 定点换算：toFixed001(25.36)=2536、fixedToText(2536)="25.36"、encodeInt16BE/decodeInt16BE（手拆大端，不依赖宿主字节序）。

与 C 端的语义差异（有意为之，结果等价）：ArkTS 有动态数组，push() 一次返回全部帧；C 端内存受限，proto_parser_feed() 采用"每次取一帧、可重复调用"的 pull 语义。两者对同一字节流产出的帧序列完全相同--已由verify/交叉验证证实。

3.4 通信层：UdpService.ets

  1. socket.constructUDPSocketInstance() 创建实例；
  2. bind({ address: '0.0.0.0', port: 8001 })；
  3. on('message', cb)：回调携带 { message: ArrayBuffer, remoteInfo: { address, port } }；
    1. 将 ArrayBuffer 转 Uint8Array 送入 FrameParser；
    2. 把 remoteInfo.address 学习为"当前设备 IP"，界面无需手工填写即可回发；
  4. sendFrame(bytes, ip, port) 下发命令；
  5. start() 做重复绑定去重与失败回滚；stop() 先 off('message'/'error') 再 close()。

NetUtils.ets用@ohos.net.connection的getDefaultNet() + getConnectionProperties()遍历linkAddresses 取 IPv4，供界面显示本机 IP。

3.5 逻辑层：MonitorViewModel.ets

  • 接收 UdpService 抛出的每一帧，按 MsgType 分发：
    • 0x01 → 更新温度/湿度/状态位，刷新"最近收到时间"；
    • 0x02 → 仅刷新在线时间；
    • 0x04 → 匹配命令 Seq，记录执行结果到日志；
    • 0x8x → 上行口收到下行帧，判定异常并记 WARN 后丢弃（协议第 6 章方向约定）。
  • 在线判定：定时器每 1s 检查 now - lastRecvTime > 10000ms 则置离线。
  • 对外通过 MonitorListener 接口把状态打散为基本类型回调 UI（避免 ArkUI 深层对象变更不触发刷新）。

3.6 表现层：Index.ets与子组件

表13 温湿度监护项目的APP界面分区[自上而下]列表

区域

内容

组件

传参方式

状态栏

本机 IP、监听端口、设备 IP、在线/离线

内联 + StatusChip

@Prop

数据卡

温度、湿度（2 位小数，告警变红）

MetricCard

@Prop

状态位

加热器/高温/低温/高湿/低湿/传感器故障

StatusChip × 6

@Prop

控制区

设备 IP、上报周期、立即查询、加热器、阈值、重启

ControlPanel

@Link

日志区

时间戳 + HEX + 解析结果

LogPanel

@Link

ArkUI 响应式约束（重要设计决策）：ArkUI 中 @Builder 的按值传参不会触发内部 UI 刷新——官方规则是"仅‘单参数 + 对象字面量’按引用传递，其余一律按值传递"。因此本工程全量避免 @Builder(带参) 渲染动态数据，统一改用： ① @State 基本类型在 build() 内联渲染；② 子组件 @Prop / @Link 接收。 这是从"远程舵机监控 APP 出现角度刷新、转速/电流恒为 --"的同类故障中总结出的硬性约束（根因即 @Builder 传参）。

3.7 权限与配置

entry/src/main/module.json5：

"requestPermissions": [

  { "name": "ohos.permission.INTERNET" },
  { "name": "ohos.permission.GET_NETWORK_INFO" }
]

main_pages.json：{ "src": ["pages/Index"] }。

版本口径：compileSdkVersion "26.0.0(26)" / compatibleSdkVersion "5.0.0(12)" / targetSdkVersion "26.0.0(26)" / runtimeOS "HarmonyOS"。

3.8 运行测调试

图5 温湿度计监控项目的APP IDE设计窗口界面截图

 

图6 温湿度计监控项目的APP IDE运行测试A组合截图

图7 温湿度计监控项目的APP IDE运行测试B组合截图

图8 温湿度计监控项目的APP IDE运行测试网络助手调试截图

4 南向鸿蒙驱动应用开发调试

4.1 工程目录结构

hi3861_fw/
├── BUILD.gn         # gn 构建脚本（static_library 聚合全部源码）
├── README.md             # 本文件
└── src/
  ├── sys_config.h      # 全局配置：SSID/密码/APP_IP/端口/周期/引脚
  ├── protocol.h         # 协议常量、枚举、帧结构、状态机、函数声明
  ├── protocol.c         # 协议编解码实现（核心）
  ├── sht30.h / sht30.c   # SHT30 I2C 驱动
  ├── wifi_connect.h/.c  # WiFi STA 连接
  ├── udp_app.h / .c     # UDP 收发 + 命令处理 + 上报调度
  └── app_main.c        # 入口：连接 WiFi → 初始化 SHT30 → 启动 UDP

4.2 分层架构

表14 温湿度监护项目的Hi3861-HiSpark分层架构列表

层

文件

职责

应用层

app_main.c

启动编排：WiFi → I2C/SHT30 → UDP 任务

业务层

udp_app.c

Socket 收发、命令分发、上报调度、状态位构造

协议层

protocol.c/.h

封帧/解帧/流式状态机/载荷构造与解析

驱动层

sht30.c/.h

I2C0 读写、CRC8 校验、原始值→物理量整数换算

网络层

wifi_connect.c/.h

STA 连接与重试、本机 IP 打印

4.3 任务与调度模型

SYS_RUN(sht30_udp_entry)
      │
      ├─ wifi_connect()           阻塞至连接成功（每 3s 重试）
      ├─ sht30_init()              失败则置 SENSOR_FAULT，不中断
      └─ udp_app_start()
              │
              └─ osThreadNew(udp_task, 栈 0x2000, osPriorityNormal)
                      │
                      loop:
                      ├─ recvfrom (SO_RCVTIMEO = 100ms，非阻塞轮询)
                      │     └─ proto_parser_feed → proto_dispatch → 回 0x04
                      ├─ 每 5000ms → 发心跳 0x02
                      └─ 每 period_sec(默认2s) → report_once() 发 0x01

采用"单线程 + 非阻塞轮询"而非多线程，原因：① Hi3861 RAM 仅 352KB，多线程栈开销大；② 无阻塞点，调度延迟可控。

4.4 SHT30 驱动设计

表14 温湿度监护项目的Hi3861-HiSpark驱动设计列表

项

取值

总线

I2C0，400 kHz

引脚

SDA = GPIO13（HI_IO_FUNC_GPIO_13_I2C0_SDA），SCL = GPIO14（HI_IO_FUNC_GPIO_14_I2C0_SCL），上拉

从机地址

0x44（ADDR 接地），7 位地址，调用时左移 1 位 → 0x88

测量命令

0x2C06（高重复性、时钟拉伸使能）

返回数据

6 字节：T_MSB, T_LSB, T_CRC, H_MSB, H_LSB, H_CRC

数据校验

CRC-8，多项式 0x31，初值 0xFF，无反转（SHT3x 标准）

物理量换算（整数运算，禁浮点）：

温度(0.01℃)  = (int32_t)t_raw  * 17500 / 65535 - 4500;   // 范围 -4500 ~ 13000
湿度(0.01%RH) = (uint32_t)h_raw * 10000 / 65535;          // 范围 0 ~ 10000

溢出校核：17500 × 65535 = 1,146,862,500 < 2^32，10000 × 65535 = 655,350,000 < 2^32，32位运算安全。

接口：int sht30_init(void); / int sht30_read(int16_t *temp_001, uint16_t *humi_001);（返回 0 成功）。

4.5 UDP 应用层设计

  • Socket：socket(AF_INET, SOCK_DGRAM, 0) → bind(0.0.0.0:8000) → SO_RCVTIMEO = 100ms；
  • 上报目标：APP_SERVER_IP : 8001（来自 sys_config.h，烧录前配置）；
  • 稳态内存：收发缓冲用 static uint8_t g_tx_buf[128] / g_rx_buf[128]，无 malloc；
  • 命令处理（proto_dispatch）：

表16 温湿度监护项目的Hi3861-HiSpark命令处理列表

下行

行为

应答

0x81 设置周期

校验 1..3600 秒

合法 0x00；非法 0x01

0x82 立即查询

先 ACK，再立即 report_once()

0x00

0x83 加热器

校验 len==1，驱动 GPIO/LED

合法 0x00；非法 0x01

0x84 设置阈值

校验 TempLow<TempHigh && HumiLow<HumiHigh

合法 0x00；非法 0x01

0x85 重启

先 ACK，延时 200ms 后 hi_reboot()

0x00

其他/上行类型

丢弃

0x02（不支持）

  • 状态位构造（build_status）：加热器在开 → bit0；传感器读失败 → bit7；阈值有效且越限 → bit1~bit4。
  • 序号码 g_seq 全局递增，uint8_t 自然回绕，符合 0x00~0xFF 循环。

4.6 内存与资源约束

表17 温湿度监护项目的Hi3861-HiSpark内存与资源约束列表

资源

用量估算

说明

收发缓冲

128 × 2 = 256 B

静态

解析状态机

70 B

proto_parser_t

UDP 任务栈

8 KB

0x2000

最大帧

70 B

远小于 MTU，UDP 单包可达

4.7 关键设计决策与取舍

表18 温湿度监护项目的Hi3861-HiSpark关键设计决策与取舍列表

#

决策

理由

代价

D1

选 UDP 而非 TCP

遥测场景"最新数据优先"，无需连接状态机，设备侧资源占用低

需心跳 + 超时判定在线

D2

校验用"累加和"而非 CRC16

计算量极小、便于网络调试助手手工构造与验算

检错能力弱于 CRC（但配合定长帧已足够）

D3

固定 5 字节头 + 变长载荷

兼容定长数据帧与变长扩展，解析逻辑统一

Len 字段需校验

D4

两端均实现流式解析状态机

应对网络调试助手一次粘贴多帧；统一处理模型

少量缓冲与滑动开销

D5

温湿度全用整数定点（0.01 单位）

避免浮点，两端换算结果严格一致；Hi3861 无 FPU

显示时需转文本

D6

ArkTS 侧禁用 @Builder(带参) 渲染动态数据

规避 ArkUI 按值传参不刷新的陷阱

需拆分子组件

D7

设备不携带 IP，APP 从数据报源地址学习

减少协议字段，简化设备实现

APP 必须收到过至少一帧才能回发

D8

C 端 pull / ArkTS 端 push 的帧返回语义

各自贴合语言与内存约束

需文档说明二者等价

4.8 编译、构建与部署

图9 温湿度计监控项目的硬件驱动与应用添加组合截图

图10 温湿度计监控项目的Hi3861-HiSpark驱动设计与应用及硬件组合截图

图11 南向软件体系编译过程组合截图

图12 南向软件体系烧录过程截图

1) 操作步骤

  1. 把 hi3861_fw/ 整体拷贝到 OpenHarmony 源码树 applications/sample/wifi-iot/app/sht30_udp_monitor/；
  2. 在 applications/sample/wifi-iot/app/BUILD.gn 的 features 中加入 "sht30_udp_monitor:sht30_udp_demo"；
  3. 修改 src/sys_config.h：WIFI_SSID / WIFI_PWD / APP_SERVER_IP；
  4. hb set 选择 wifiiot_hispark_pegasus，hb build -f；
  5. 用 HiBurn 烧录 Hi3861_wifiiot_app_allinone.bin。

2) 烧录前必改配置（src/sys_config.h）

表19 温湿度监护项目的Hi3861-HiSpark配置修改列表

宏

说明

默认值

WIFI_SSID

路由器 SSID（仅 2.4G，Hi3861 不支持 5G）

HiSpark-AP

WIFI_PWD

WiFi 密码（WPA2-PSK）

12345678

APP_SERVER_IP

上位机（手机/PC）实际 IP，即上报目标

192.168.1.100

APP_SERVER_PORT

上位机监听端口（别名 APP_UDP_PORT）

8001

LOCAL_LISTEN_PORT

设备监听端口（别名 DEVICE_UDP_PORT）

8000

3) 硬件接线（SHT30 ↔ Hi3861 / HiSpark）

表20 温湿度监护项目的Hi3861-HiSpark硬件连线列表

SHT30

Hi3861 引脚

说明

VCC

3V3

供电

GND

GND

共地

SDA

GPIO13

I2C0_SDA（固件已设内部上拉）

SCL

GPIO14

I2C0_SCL（固件已设内部上拉）

ADDR

GND

从机地址 = 0x44

加热器以板载 LED（GPIO9，低电平点亮）指示，无实际加热元件。

5 南北向系统联合调试完善

图13 舵机监控项目南北向联合调试组合截图

Logo
人工智能6S服务平台

作为“人工智能6S店”的官方数字引擎，为AI开发者与企业提供一个覆盖软硬件全栈、一站式门户。

更多推荐

cover

鸿蒙原生应用 ArkUI 实战：技能交换首页的分类胶囊横滑与推荐列表

avatar 人工智能6S服务平台
cover

鸿蒙原生应用 ArkUI 实战：技能交换我的页 —— 渐变卡 + 悬浮统计 + 技能卡三段式写法

avatar 人工智能6S服务平台
cover

鸿蒙原生应用实战：HarmonyOS ArkTS下，技能交换交流页聊天列表与未读红点

avatar 人工智能6S服务平台