★ FEATURED ARTICLE 做鸿蒙物联网开发绕不开的一颗芯片就是Hi3861。这颗面向低成本IoT场景的2.4GHz WiFi SoC是OpenHarmony轻量系统上被用得最多的入门硬件市面上能找到的开发板、教程、实战案例几乎都把它当成默认起点。这篇文章我按自己实际跑通的路子把Hi3861从芯片规格、环境搭建、源码编译、固件烧录到第一个LED点灯Demo完整讲一遍顺手把踩过的坑也全倒出来。刚接触鸿蒙嵌入式开发的朋友或者有单片机基础想转WiFi物联网方向的朋友都可以直接照着操作先把最小闭环跑通再慢慢扩展功能。1. 认识Hi3861它到底是什么水平1.1 芯片规格速览Hi3861V100是一颗高度集成的2.4GHz WiFi SoC芯片内部把射频收发、基带处理、协议栈和应用处理器都打包在一起了。对新手来说最直观的感受就是以前做WiFi项目要外部挂一个ESP8266之类的模块用串口发AT指令控制而Hi3861可以当成一颗正经的“主控MCU WiFi”二合一来用应用代码直接在芯片上跑省掉一颗外置MCU的成本和面积。核心参数大概是这样主控32位RISC-V架构处理器最高主频在160MHz附近无线2.4GHz WiFi支持802.11 b/g/n协议存储片上SRAM为352KB具体Flash配置不同模组有差异通常外挂SPI Flash外设接口GPIO、UART、I2C、SPI、ADC、PWM等常规接口都有低功耗支持多种休眠模式适合电池供电的传感器节点类产品系统支持OpenHarmony轻量系统LiteOS-M内核也能跑厂商SDK这颗芯片的定位很清晰就是给“功耗敏感、成本敏感、功能相对单一”的物联网设备用的比如智能插座、温湿度传感器、智能灯、门磁、烟感这类产品。它不适合跑复杂的图形界面或者大流量应用但在轻量级IoT场景里属于非常能打的一颗料。对比很多开发者熟悉的STM32方案Hi3861最大的差异在于“自带无线协议栈”。传统MCU要做WiFi得外挂模块要处理AT指令帧、串口缓冲、断线重连这些麻烦事而Hi3861的OpenHarmony SDK里直接集成了WiFi能力代码里调接口就能完成STA模式连接、扫描、断开等操作整体开发体验更接近“写应用逻辑”而不是“伺候通信模块”。1.2 开发板与硬件准备市面上的Hi3861开发板种类不少但核心电路差异不大基本都是“芯片模组 电源 USB转串口 若干按键和LED”。选板子时重点看三样东西有没有板载USB转串口芯片、有没有引出足够多的GPIO排针、资料和例程是否完整。没有板载串口芯片的板子你还要自己买USB转TTL模块对新手来说多一道坎所以我的建议是优先选自带串口芯片、插一根USB线就能供电兼通信的板型。硬件准备清单很简单Hi3861开发板一块USB Type-C或者Micro-USB数据线一根关键要支持数据传输不能是只供电的充电线Windows电脑一台用来烧录固件和看串口日志Linux环境一个用来编译源码后面细说杜邦线、面包板、LED灯珠和电阻若干做外设实验用这里有个非常多人踩过的坑线材问题。USB线看着插上了指示灯也亮了但设备管理器死活不出现串口号大概率就是用了纯充电线。我后来专门拿两根线分别测试过数据线一插上端口就出来了所以第一个排查方向永远是先换线。1.3 适合谁学、能做什么项目如果你满足下面任意一条Hi3861这条路径就很适合你做过单片机开发想快速上手带WiFi能力的国产IoT平台被复杂的RTOS开发搞怕了想体验一种更“应用化”的开发方式学校课程或比赛项目里要求基于鸿蒙系统做硬件Demo工作中需要快速评估轻量物联网设备的主控选型通过它你能做出来的东西覆盖了IoT设备最常见的几类需求LED灯控、按键输入、传感器数据采集、WiFi配网连接、MQTT数据上云、OLED屏幕显示、定时任务等。我自己就是从LED和WiFi扫描这两个Demo开始后面接了一个模拟工业环境温湿度采集的项目从零到跑通大概用了一个多星期。2. 环境搭建先把编译链路搞干净2.1 为什么编译推荐用LinuxHi3861的OpenHarmony编译工具链是基于Linux生态的官方推荐的构建环境是Ubuntu。虽然也有开发者在Windows上折腾出一些变通方案但不适合新手因为提前做各种环境移植只会把问题叠加起来。最省心的做法是Linux负责编译Windows负责烧录和看日志两边各干各的互不干扰。Linux环境的选择我给三个方向按推荐程度排序物理机直接装Ubuntu 20.04或22.04性能最好磁盘空间最充裕VMware或VirtualBox虚拟机适合Windows主力机用户代码共享用共享目录或挂载磁盘WSL2能编译但USB串口透传配置比较麻烦前期不建议我个人用的是虚拟机方案分配了4核CPU、8GB内存、60GB磁盘。编译速度比物理机慢一点但完全可以接受整个全量编译大概在十分钟左右。需要注意的是给虚拟机预留足够的磁盘空间OpenHarmony源码加编译产物体积不小我见过不少人在编译中途才报磁盘满的错很折腾。2.2 Ubuntu依赖安装一次配到位进入Ubuntu系统之后先把基础依赖装齐。不同OpenHarmony版本依赖清单略有差异但下面这套是我实测稳定能用的组合sudo apt update sudo apt install -y gcc g make zlib1g-dev libffi-dev \ libssl-dev flex bison ninja-build python3-pip \ python3-setuptools git unzip curl这里有个容易踩的坑Python版本问题。OpenHarmony 3.0 LTS时代官方推荐Python 3.7到3.8左右太新的版本在某些编译脚本上会报语法兼容问题。Ubuntu 20.04自带的Python 3.8就很合适如果你用的是Ubuntu 22.04及以上的Python 3.10先确认当前版本的构建脚本是否兼容不兼容的时候可以装一个3.8版本的Python切换默认指向。装完依赖后验证一下python3 --version ninja --version这两条命令能正常输出版本号说明基础环境基本没毛病。2.3 获取OpenHarmony源码与hb工具Hi3861对应的源码是OpenHarmony的轻量系统分支官方推荐用repo工具做多仓库管理但repo下载对新手来说确实有点折磨。我更建议直接下载官方打包好的完整源码压缩包解压即用省去大量下载和同步时间也避免了中途断流导致仓库不完整的问题。拿到源码之后目录里有一个build文件夹hb编译工具就藏在里面。老版本OpenHarmony的安装方式是在源码根目录执行python3 -m pip install --user build/hb安装完成后把用户bin目录加到PATH里然后执行export PATH$PATH:~/.local/bin hb --version如果打印出版本号说明hb工具安装成功。这里要特别说一句每次打开新的终端窗口PATH导出命令都要重新执行一次嫌麻烦可以写进~/.bashrc里我就是因为忘了这个细节卡在“hb command not found”上很久当时还以为是安装出了问题。另外官方文档有时候会建议先执行build/tools/install_deps.py来完成依赖的自动安装这个脚本确实能省不少事但它默认帮你配置的环境不一定符合你的系统我的建议是脚本跑归跑前面2.2节里的手动安装也别跳过双保险。3. 首次编译跑通官方固件3.1 源码目录结构先看懂再动手OpenHarmony源码目录特别大但Hi3861轻量系统开发真正需要关心的是这几个目录device/soc/hisilicon/hi3861v100芯片相关的SDK、硬件驱动、链接脚本vendor/hisilicon/hispark_pegasus开发板产品定义、编译配置applications/sample/wifi-iot官方示例应用也是我们写业务代码的主战场kernel/liteos-m轻量系统内核build构建框架和hb工具很多新手一上来就在全源码里搜代码看半天不知道从哪下手。实际上你只需要理解一条主线产品配置在vendor目录里定义了“要编译哪个target、启用哪些组件”应用代码在applications/sample/wifi-iot目录里写编译工具根据这些配置把内核、组件、你的应用打包成固件。把握住这条主线整个工程结构就清晰了。3.2 hb set与hb build实操首次编译的完整流程是三步设置产品、执行编译、检查产物。第一步在源码根目录执行hb set命令会进入交互式界面列出可选的开发板/产品配置找到Hi3861对应的选项通常是wifiiot或者类似名字。用键盘上下键选中回车确认根目录下的ohos_config.json配置文件就生成了。第二步执行编译hb build -f-f参数表示全量编译也就是忽略之前的增量缓存强制重新构建。第一次编译没有缓存其实加不加都一样但如果你改了些奇怪的东西导致编译状态混乱全量编译是最好的排障手段。编译过程会打印大量日志不要被刷屏吓到只要最后出现类似build success的提示就是顺利完成了。如果中途报错也不要慌绝大多数错误集中在依赖缺失和Python版本问题上后文常见问题章节会专门列一个速查表。第三步检查编译产物。编译完成后进入输出目录ls out/hispark_pegasus/wifiiot/不同版本输出路径可能有差异你可以在out目录下搜索一下OHOS_Image.bin这个文件名大差不差。3.3 编译产物与分区说明Hi3861的编译产物不只有一个文件常见的包括Hi3861_loader_signed.binbootloader引导程序负责启动时初始化硬件、加载主固件OHOS_Image.bin操作系统和应用打包后的主镜像这是核心固件rootfs_vfat.img、userfs_vfat.img文件系统镜像部分配置会生成这几个文件分别对应Flash的不同分区地址烧录时不能随便乱放。最简配置下烧bootloader和主镜像两个文件就能跑起来但如果你想用文件系统能力rootfs和userfs也要按对应地址烧进去。我在第一次接触时犯过一个错误只烧了OHOS_Image.bin然后抱怨为什么板子不启动。后来才明白bootloader和主镜像是一套完整的启动链路缺一不可。所以请记住一句话最稳妥的做法是编译产物里每次都把全部镜像文件按默认分区地址烧进去而不是挑着烧。4. 烧录与串口调试4.1 Windows下用HiBurn烧录编译运行在Linux完成烧录我建议回到Windows操作。把编译产物从Linux拷到Windows然后用官方提供的HiBurn工具进行串口下载。工具不用额外安装什么复杂环境解压后是一个Windoows可执行程序界面。烧录前先做两件事。第一安装USB转串口驱动多数Hi3861开发板用的是常见串口芯片方案Windows没自动识别的话就手动装一下驱动装完在设备管理器里能看到对应的COM口编号。第二把开发板通过USB线连到电脑确认设备管理器中出现了新串口。HiBurn的基本操作流程打开HiBurn选择正确的COM口设置波特率工具默认的115200即可追求烧录速度可以调高但稳定性跟线材和驱动有关追求稳就保持默认点击连接按钮工具会尝试和开发板建立通信在烧录文件列表中添加编译产物的镜像文件并确认每个文件的烧录地址部分板型需要按住升级/下载按键再上电进入下载模式视具体板子而定点击烧录按钮等待进度条走完整个过程最折磨人的就是“点了烧录但进度条不动”。这种情况九成是开发板没有进入下载模式或者串口连接已经断开。我的经验是先断开物理连接重插一次再点烧录同时关注工具右下角的状态提示看到类似等待设备上电的提示后再给板子上电或按复位键时序卡准了成功率极高。4.2 串口日志怎么看烧录完成后开发板会进入正常运行状态这时候用任意一款串口监视工具打开对应COM口设置波特率115200就能看到系统打印的日志。看日志是嵌入式开发最重要的一项日常操作因为你写的代码一烧进去肉眼看不到运行状态只能靠日志定位问题。Hi3861上跑的系统会有完整的启动日志从bootloader到内核到应用一步步打印。我习惯把串口监视工具的日志保存到文件里这样出问题时可以回头翻而不是只盯着一屏快速滚动的输出。有一点值得注意Windows的串口是独占的串口监视工具开着的时候HiBurn就没法再连同一端口。所以正确顺序是“烧录完关掉HiBurn串口连接再开监视工具”两个工具抢一个串口肯定有一个连不上。4.3 烧录失败三大典型原因我在Hi3861烧录上翻车的次数不少归纳起来无非三类第一驱动没装好设备管理器里没有串口或者出现黄色感叹号。解决方法是重装驱动或者换个USB口笔记本的扩展坞口有时候供电或枚举不稳定。第二没进入下载模式或者时序不对。不同板型的下载模式按键位置不一样有的是按住下载键再上电有的是点击烧录后再按复位键一定要看你板子对应的说明。第三固件文件和地址不匹配。烧错地址导致启动异常的情况现象通常是“看起来烧成功了但板子起不来”。每次烧录前对照一下分区表别凭记忆填地址。5. 第一个业务DemoLED点灯5.1 创建应用目录与BUILD.gn跑通官方固件只是热身真正开始写业务代码才是入门的关键一步。Hi3861上的OpenHarmony应用开发核心就是“在applications/sample/wifi-iot/app目录下建一个业务子目录每个子目录包含一个.c源文件和一个BUILD.gn构建脚本”。我先说目录结构大概长什么样applications/sample/wifi-iot/app/ ├── BUILD.gn └── led_example/ ├── BUILD.gn └── led_example.c外层app/BUILD.gn负责声明要编译哪些子模块。参考写法如下import(//build/lite/config/component/lite_component.gni) lite_component(app) { features [ led_example, ] }内层led_example/BUILD.gn描述这个模块自身的源码和头文件路径static_library(led_example) { sources [ led_example.c, ] include_dirs [ //utils/native/lite/include, //kernel/liteos-m/kernel/include, //base/iot_hardware/peripherals/interfaces/kits, ] }这里要提醒新手一点不同OpenHarmony版本的组件路径和头文件组织会变化如果你用的版本报找不到头文件的错优先去实际目录里确认一下路径。构建配置报错比代码报错更常见别慌照着路径去base或device目录下翻一翻就能解决。5.2 业务代码逐行拆解LED点灯的示例代码看起来简单但里面包含了Hi3861应用开发最核心的几个机制任务创建、GPIO初始化和系统自动注册。我把完整代码贴出来再逐段解释#include stdio.h #include unistd.h #include ohos_init.h #include cmsis_os2.h #include iot_gpio.h #define LED_GPIO 9 #define SLEEP_US 1000000 static void LedTask(void) { IoTGpioInit(LED_GPIO); IoTGpioSetDir(LED_GPIO, IOT_GPIO_DIR_OUT); while (1) { IoTGpioSetOutPutVal(LED_GPIO, IOT_GPIO_VALUE0); usleep(SLEEP_US); IoTGpioSetOutPutVal(LED_GPIO, IOT_GPIO_VALUE1); usleep(SLEEP_US); } } static void LedExampleEntry(void) { osThreadAttr_t attr {0}; attr.name LedTask; attr.priority 25; attr.stack_size 4096; osThreadNew(LedTask, NULL, attr); } SYS_RUN(LedExampleEntry);第一段LedTask是真正的业务逻辑。IoTGpioInit(LED_GPIO)做GPIO初始化相当于把这个引脚从默认状态切换成可控状态IoTGpioSetDir(LED_GPIO, IOT_GPIO_DIR_OUT)把引脚设置为输出模式。接着一个死循环里先把引脚拉低再延时1秒再拉高延时1秒LED就会呈现一亮一灭的效果。第二段LedExampleEntry做了三件事定义一个线程属性结构体、给线程起名字、设置优先级和栈大小然后调用osThreadNew创建线程让LedTask跑起来。这里用到的接口来自CMSIS-RTOS2封装如果你之前接触过RTOS对这些概念不会陌生。栈大小4096字节是官网示例常用的值实际项目里要根据任务内的局部变量和调用深度调整。第三段是精髓SYS_RUN(LedExampleEntry)是一个系统自动注册宏它的作用是让系统在启动流程中自动调用LedExampleEntry不需要你在main函数里手动加调用。这也解释了为什么OpenHarmony应用代码看起来“没有入口”——每个业务模块通过类似的宏机制挂到系统启动链路上系统按初始化优先级依次执行。理解了这一点后面不管是写按键任务还是传感器采集任务套路都一模一样写一个入口函数创建一个或多个线程用对应宏挂到系统启动流程里。5.3 编译烧录与效果验证代码写完后回到源码根目录执行hb build -f如果一切顺利编译完成后把产物里的镜像文件按之前的方式烧录到开发板然后打开串口监视工具你会看到启动日志后板子上的LED按照1秒间隔稳定闪烁。这个环节我要分享一个实际遇到过的低级问题点灯不亮。我当时一度怀疑硬件坏了排查了一圈发现是GPIO引脚号选错了板子的LED并不在默认的9号引脚上。不同开发板LED的引脚连接差异很大有的用GPIO9有的用别的最靠谱的做法是查你自己的开发板原理图或者商家提供的例程别盲目照抄别人的引脚号。6. 常见问题实录与后续方向6.1 编译期问题速查我把编译阶段最常出现的几个问题整理成了一张表遇到直接对照排查现象常见原因解决办法hb command not foundhb工具未安装或PATH未配置重新安装hb确认~/.local/bin在PATH里Python版本相关的语法报错Python版本过高或过低切到3.7到3.8版本检查python3指向找不到某些头文件include_dirs路径与版本不符去实际目录确认组件路径修正BUILD.gn编译中途磁盘满源码和产物太大清理历史产物给虚拟机扩容编译卡死或内存不足虚拟机内存分配太小至少分配4GB以上内存关闭其他大程序这里额外提一句全量编译第一次基本都要跑很久中间日志看起来像卡住了其实多数是在拉依赖组件或者生成中间文件。判断是否正常可以观察CPU占用率或者等一段时间看有没有新日志输出别因为“看起来没动静”就手动中断。6.2 运行期问题速查烧录完成、系统跑起来之后的常见问题也不少现象常见原因解决办法烧录后没有任何日志bootloader缺失或烧录地址错误确认bootloader和主镜像都按正确地址烧录日志刷到一半死机栈溢出或任务优先级配置异常调大线程栈检查任务里是否有超大局部变量LED不亮GPIO引脚号不对查开发板原理图确认LED实际引脚串口监视工具连不上串口被HiBurn或其他工具占用关闭占用程序重新插拔USB线按键无反应GPIO输入模式未配置或上下拉不对用IoTGpioSetDir设为输入检查外部电路运行期排障最重要的基本功就是“分段定位”先确认系统日志是否正常启动再确认自己的任务是否被创建最后用串口打印确认业务逻辑执行到了哪一步。把这三个层次一层层剥开大部分问题都能快速锁定。6.3 下一步可以玩什么点灯跑通之后从“入门”到“会用”之间还差几个进阶模块。我建议按这个顺序深入第一WiFi连接。让开发板作为STA连上你的路由器然后扫描周边的热点这是IoT设备最基本的能力也是后面上云的前提。第二传感器数据采集。接一个温湿度或光照传感器通过GPIO或I2C接口读数据把数据打印到串口。第三MQTT上云。把采集到的数据用MQTT协议发到云端平台再通过云平台反向控制设备。第四低功耗管理。电池供电场景下怎么休眠、怎么定时唤醒这直接关系到产品能不能落地。每一步都有成熟的例程可以参考最核心的能力是学会把OpenHarmony的启动机制、任务模型、硬件接口抽象组合起来。等你能够不看例程自己从零搭一个“传感器采集WiFi上报”的小项目时Hi3861这条入门路线就算真正走完了。最后再分享一个我个人的习惯我会把每次踩坑的结论记在一个文档里包括错误日志的关键行、当时的解决办法、涉及的文件路径。嵌入式开发的信息非常碎片化光靠脑子记根本不靠谱把这些沉淀下来第二次遇到同样问题五分钟内就能解决。开发板上点亮的那个LED只是开始后面那扇门里还有一堆有趣的东西等着你。
阅读完成 · 觉得有帮助？
