IDE/IoT/搭建物联网(LiteOS)集成开发环境，基于 VSCode + IoT Link 插件

概述

本文详细介绍了基于 VSCode + IoT Link + GCC 搭建和开发华为物联网设备侧程序的方式方法，分析了此环境的优劣势和注意事项。本文基于IoTDA 在线文档 <基于NB-IoT小熊派开发智慧路灯>中的说明进行实践，对对其进行了补充和注意事项总结。

@HISTORY
通过些旧资料信息只是推测，华为最开始推出的IDE是 LiteOS Studio + GCC 方案， 如，在HCIP-IoT实验手册中提及使用，偶尔一些帖子里也能看到，但在华为云社区几乎看不到它的身影啦。开发环境 VSCode + IoT Link 可能是中间阶段的一个产物（只是猜哈），在华为云IoTDA在线文档，2025年更新的一些示例程序中依然在使用。关于前者的使用，我们可以参见 #<IDE/IoT/搭建物联网(LiteOS)集成开发环境，基于 LiteOS Studio + GCC + JLink>#，我更推荐的IDE方案，#<IDE/IoT/搭建物联网(LiteOS)集成开发环境，基于 VSCode + GitBash + GCC工具>#。

丑话说在前边，
参考 IoTDA 在线文档 <基于NB-IoT小熊派开发智慧路灯>中的表述，以windows 10 64-bit系统Visual Studio Code为例，请下载1.49版本，其他版本不支持IoT Link。

在VSCode插件库中搜索发现，该插件的停更时间比 LiteOS Studio 发行版的停更时间还早一年，这东东2020年不更新了。好在关于它的使用时尚活跃的，

设备接入 IoTDA 中提及的上述在线文档 ，其更新时间是2025年3月，就是前几天。既然此文档中还是描写使用 IoT Link 插件，那，不至于如此不堪，诓骗用户吧。至少该模式的环境搭建是有文档可参考的，只能硬着头皮来来了。本章基于此帮助文档进行实操实践，记录了一些问题和心得。

后记，
在解决一些安装问题的过程中，我还发现了 https://flyfishzy.github.io/iotstudio-doc/zh/ 这个插件使用说明网站，其中有对于IoT Link Studio 的一个完整全面的安装和使用说明。在Deepseek的辅助分析下，认为该网站是该网站是：基于 GitHub Pages 部署，域名 flyfishzy.github.io 表明是个人或小团队维护的开源项目文档，非企业级官方页面。，某开发者使用 Markdown 编写文档，通过 GitBook 生成结构化输出（如电子书目录导航、交互式网页），并通过 GitHub Pages 托管 GitBook 生成的静态站点。
但再后来，
我在华为云开发者社区博客里也发现了上述网站的身影，参见 202308发表的 <VSCode 搭建 IoT Link 开发环境，华为云IoT+鸿蒙> 这篇文章，其中提到 “在安装插件页，详情的底部，有介绍插件的官网 https://flyfishzy.github.io/iotstudio-doc/zh/”。我重新打开 IoT link 插件安装界面，还果然有， Tutorials/教程，指向上述网址，

如下，是在VSCode在线可得可安装的IoT Link 插件，

可以大致了解到，IoT Link Studio是针对IoT物联网端侧开发的IDE环境，提供了编译、烧录、调试等一站式开发体验，支持 C、 C++、汇编等多种开发语言，让您快速、高效地进行物联网开发。通过上文提到的 IoT link 官方教程，并没有明说这是针对华为云 IoT 的，也没有表明其开发者是华为或子部门，也没有任何的个人署名，我不太好去猜测这其中的原因，可能是怕引起不必要的麻烦吧，从本文档的关联资料中可以看到，它就是针对华为云物联网开发的。

IDE安装

参考 IoTDA 在线文档 <基于NB-IoT小熊派开发智慧路灯>，文中将华为一站式开发工具平台定义为 VS code工具IoTlink插件。

安装旧版本VSCode

现在是202503，比较尴尬的是，我们得下载使用旧版本 Visual Studio Code，且有地方标明了只能是 1.49 版本，其他版本不支持 IoT Link 。

如果你已经安装过较新的版本，请卸载，并最好在断网的情况下安装上述旧版本。
再次提示，安装前先断网，否则在你安装完成后的几十秒内，在你关闭自动更新选项前，VSCode后台就偷偷地默默地替你把升级完成了。如果你不听话断网，你极有可能在试图关闭自动更新功能的过程中，被提示当前软件处于启动状态，无法执行完安装，此时就晚了，即使你点击取消也没有用，看到此提示的时候，后台已经给你升级结束，就等你重启软件了。

安装插件

若英文不过关，先装 Chinese (Simplified) (简体中文) 插件。在菜单栏->文件->设置->应用程序，更改如下2个配置：

接下来，正常安装 IoT Link 插件，

上述安装过程，你看可能会在右下角看到包含但不限于上图中的依赖库或扩展的安装过程。IoT Link 插件安装过程中，会自动安装其依赖的 C/C++插件，推荐自己在安装C++ Intelliense 插件等。一个简单的环境，可能最起码要包含如下基础插件配备，

安装问题和解决

Network Error ！具体如下图，（前文我们关闭了软件自动更新，并不是关闭了全部网络哈）

分析上述问题的可能原因如下，如，外网访问限制、依赖路径配置错误、网络稳定性差、代理未配置等等。我本来在这里写了很多，后来都删了，感觉有点浪费时间。我们稍微说一下，代理配置这个事情：
若用户处于企业内网或需要代理访问外网，但未在VSCode中设置代理（首选项→设置→代理服务器），会导致下载请求被拦截。这种情况下，即使你配置代理通常也没啥鸟用，一般公司网络安全没有那么不堪吧。我回到家，在打开科学上网，并打开VSCode代理服务器的情况下，依然存在上述插件安装异常。

对于这点多说几句，如果你网络知识，比如，对关于什么网络代理、防火墙、证书等概念和操作不是特别在行，不要轻易尝试。即使你尝试了，若不成功，记得修改回去，因为你的这些修改可能导致VSCode不能正常连接到插件市场，一个可能的异常提示如下，

//插件卡中的异常调试
//We cannot connect to the Extension Marketplace at this time，please try again later。

如果最后还是不成功，不要太执着，自动安装依赖毕竟不是最终目的…
可能还存在其他方向的问题，我没有想到。也可能是对上述问题的解决方案没有卡到点上。总之安装 IoT Link Studio 时，并没有出现预期的自动从网络下载最新的SDK包以及gcc依赖环境。我只能临时尝试手动了，这并不丢人。

手动安装SDK包

假如下载SDK包及gcc依赖环境失败，请手动下载SDK包 ，参考实验指导手册，放到C:\Users${用户名}.iotlink\sdk目录下,文件名修改为IoT_LINK。放置完后，重新打开VSCode即可。这里的路径就是后续[用户设置-SDK管理]章节中显示的路径。

当然，放在C盘，让人很不舒服。很遗憾，不支持修改。

手动下载依赖工具

参考Gitbash的环境搭建过程。

IoTLink配置

安装完成旧版本的VSCode和IoT Link等插件后，我们需要配置IoT工程

IoTLink Home

我们启用 IoT link 插件后，可以在VSCode页面左下角看到一个工具栏，如下图，

点击Home按钮，

如上，点击 [IoT Link设置]。建议先进行用户设置，再进行工程设置。

因为在用户设置中，会有方便的工具链安装连接可以使用。而工程设置中，只有选择操作，没有安装入口，若你之前没有安装过相关工具，则无法进行选择，挺矛盾的。

用户设置-工具链-编译器

点击上图GCC下载安装按钮，将跳转到 GNU Arm Embedded Toolchain Downloads，下载 win32.zip 工具链版本，如下图，

下载过程，

如上图，虽然能访问，但是下载速度相当的慢，这也可能是导致不能自动下载的原因之一。如上图，我下载的是较新的版本（小熊派 developTools.zip依赖包中是7.3），安装到D:\Program Files目录下，

用户设置-工具链-构建器

前文提到了，在工具链设置卡中，贴心提供了GCC和JLINK下载链接，但这里并没有提供make的下载链接，如本章节概述图示，此目录默认为${system_default}，即系统Path环境变量配置，这是很危险的配置方式，因为你的系统里可能安装了多个版本的make工具，先识别到哪个不确定，

我昨天刚安装了小熊派 developTools.zip，其中在上述目录包含make工具。在华为云示例文档中，并没有提及make工具的安装，可能是太习以为常啦，这是常用工具。如果你之前没有安装过任何版本，可以访问 Make for Windows，下载zip版本，在必要的情况还需要安装libintl3、libiconv2依赖。上述developTools中的make版本是4.2.1，还挺新的，我就借用了。

要注意的是，Make工具路径的配置应该选择make.exe可执行文件，而不仅是其目录。但这里有bug，开发者将打开文件功能意外开发成了打开目录功能，文件名需要自己输入（并重启软件）。如果你选择的是目录不是文件，则在编译时，可能会报错，大约如下，

D:\Program Files\IoT_developTools\GNU MCU Eclipse\Build Tools\2.11-20180428-1604\bin -f,Makefile,-j
Error: spawn D:\Program Files\IoT_developTools\GNU MCU Eclipse\Build Tools\2.11-20180428-1604\bin ENOENT

最终GCC和Make配置如下，

用户设置-工具链-烧录器

JLink目录是个默认显示，其实它尚不存在。点击跳转 SEGGER Downloads，下载到 JLink_Windows_V824_i386.exe 文件，全默认安装。

在指导书中，使用的是ST-Link驱动适配OpenOCD模式，所以没有提及J-Link驱动安装。在LiteOS Studio环境中，则强制使用Jlink模式，需要将STLink重刷成JLink。本次实验，我们使用的是ST-Link和OpenOCD，按照 <基于NB-IoT小熊派开发智慧路灯>中的相关步骤进行即可，可不去关注J-link。如果你对Jlink及其使用有所了解，它可能是更稳妥的选择。

如果以前刷过烧录器到JLINK，记得恢复哈，

哈哈，光靠上边还不行，还得借助STM32 ST-LINK Utility重新联网烧录STlink固件，

烧录完成后，将小小南瓜派开发板的电源/烧录/串口线，重新拔插下，must哦。

用户设置-SDK管理

回到手动安装SDK包那一小节，这里就是其要求的默认路径，很遗憾，不支持修改。

工程设置-SDK配置

这属于SDK裁剪配置，在对工程树结构不太熟悉的情况下，可先不关注这块。

工程设置-编译器

这里的编译器配置为 ${system_default}，它是指系统Path目录。这里不建议使用此默认目录。因为我们的系统中，可能有好多个地方都存在gcc的可执行文件。我的就被识别到了Qt安装目录下。

修改后的编译器配置，

在该插件下的[工程设置-调试器-OpenOCD路径]、[用户设置-工具链-Make工具路径]，叫做路径配置的地方，都是要具体到文件名，而不是文件夹名。但是这里的编译器路径，却得配置文件夹路径，因为不光要用gcc，还要用gdb工具。

工程设置-调试器

OpenOCD（Open On-Chip Debugger） 是一款开源的片上调试工具，在嵌入式开发中广泛用于芯片初始化、固件烧录、实时调试等场景，尤其在与 GCC 工具链结合时，能够构建完整的交叉编译与调试环境。首先OpenOCD本身是一个跨平台的调试软件，在Windows对应可执行文件openocd.exe，以小熊派 developTools.zip为例，openocd目录下，包含 bin/openocd 和 bin-x64\openocd ，其中bin被默认添加到了系统Path，对于64bit系统，我们建议使用修改配置成bin-x64目录，会更高效稳定些。

调试器配置中的OpenOCD，我们使用 D:\Program Files\IoT_developTools\openocd\bin-x64。还要注意的是，OpenOCD作为协议适配层，通过插件化架构支持多种调试接口协议，如，JTAG协议、SWD协议（Serial Wire Debug）等。
OpenOCD的运作可以分为两个层次，
核心软件层：通过可执行文件提供调试服务，包含GDB服务器、Telnet接口等模块。支持动态加载配置脚本（.cfg文件），定义适配器类型、目标芯片参数等。协议驱动层：通过插件机制支持不同调试接口的协议栈，例如：ST-Link调试器的配置脚本 interface/stlink.cfg、具体系列芯片调试参数target/stm32l4x.cfg。这里提到的stm32l4x.cfg文件，是在安装IoTLink插件的过程中，被下载到VSCode插件extensions目录下的，

还要注意的是，这里的OpenOCD路径应该是文件路径不是文件夹，插件开发者在这里犯了同样的错误，像前边"用户设置-工具链-MAKE工具路径"那样，要自己手动输入文件名，而不能通过选择框搞定，最终调试器配置为，

OpenOCD要与GDB协同工作，
在使用OpenOCD进行嵌入式调试时，GDB是必需的调试工具，两者通过明确的角色分工实现高效协同调试。OpenOCD与GDB的协作是硬件与源码调试的桥梁：OpenOCD作为“翻译官”，负责将GDB的高级指令转换为硬件可识别的信号。GDB作为“指挥官”，提供用户友好的调试界面与逻辑控制。 两者通过RSP协议实现高效通信，是嵌入式开发中不可或缺的工具链组合。

创建工程

新建工程成功后，IoT Link 工具条，对比创建项目前，变化如下，

这里的示例工程的源码，应该是从 C:\Users\qugx0528.iotlink\sdk\IoT_LINK 目录下拷贝出来的。

Demo 源码

在上一小节，我们通过使用IoTLink插件创建IoT工程时，可以选择基于示例工程创建。这里的示例工程，是安装IoTLink插件的过程中被拷贝到安装目录下的。对比小小派社区给出的bearpi-iot_std_liteos项目下的示例程序，两者几乎是一致的。

//E:\IoT\QuickStart\Src\main.c
int main(void) {
    UINT32 uwRet = LOS_OK;
    HardWare_Init();
    uwRet = LOS_KernelInit();
    if (uwRet != LOS_OK)
    {
        return LOS_NOK;
    }

    extern void shell_uart_init(int baud);
    shell_uart_init(115200);

    link_test(); //最终会调用standard_app_demo_main函数

    (void)LOS_Start();
    return 0;
}

//E:\IoT\QuickStart\Demos\oc_streetlight_template\oc_streetlight_template.c
int standard_app_demo_main() {
    ...
    osal_task_create("app_collect",app_collect_task_entry,NULL,0x400,NULL,3);
    osal_task_create("app_report",app_report_task_entry,NULL,0x1000,NULL,2);
    osal_task_create("app_command",app_cmd_task_entry,NULL,0x1000,NULL,3);
	//
    osal_int_connect(KEY1_EXTI_IRQn, 2,0,Key1_IRQHandler,NULL);
    osal_int_connect(KEY2_EXTI_IRQn, 3,0,Key2_IRQHandler,NULL);
	...
    return 0;
}

编译和烧录

单击VSCode底部工具栏的“Build”，等待系统编译完成。编译成功后，界面显示“编译成功”
单击VSCode底部工具栏的“Download”，等待系统烧录完成。烧录成功后，界面显示“烧录成功”

IDE测试

此章节不是本文重点，详情参考 IoTDA在线文档， <基于NB-IoT小熊派开发智慧路灯>。

检查通信模组

在其他的文章中，我们已经进行过相关实验，彼时使用的是独立串口工具，这里使用IoT Link串口终端再行实验。

产品和模型

如上，创建产品，并按照文档说明，导入现有的产品模型，保持ZIP格式导入。

注册设备

基于产品及其模型，创建注册设备的入口有两个，我们在之前的实验中都用过，再回顾下。

方案1：在所有设备界面->设备列表->注册设备，

参见 #<IoT/基于NB28-A/BC28-CNV通信模组使用AT指令连接华为云IoTDA平台># 文中相关内容。

方案2：在产品详情->进入在线调试选项卡->新增测试设备，

就目前的实际观察来说，在调试阶段，我没有感受到两种设备的区别，可以通过不同路径进入相同调试卡。具体比较下这俩入口：
单设备注册（设备列表入口）
适用于正式生产环境中的设备批量或单个接入，需严格遵循产品模型和安全规范。通常用于真实设备的长生命周期管理，支持完整功能（如数据持久化、规则引擎联动、OTA升级等） 。
在线调试中的新增测试设备
专为开发调试阶段设计，简化注册流程，便于快速验证设备与平台的通信功能。此类设备通常用于临时测试，可能不支持某些高级功能（如设备联动规则），且数据可能不持久化。

关于设备秘钥

在"基于NB-IoT小熊派开发智慧路灯"说明书中，其创建设备时，选择的是“不加密”，并使用不加密的Coap协议，5683端口。我在 #<IoT/HCIP/基于NB-IoT模组的AT指令实验（小熊派IoT+NB28-A模组）>#，我临时得出的结论是，似乎不再提供Coap不加密传输协议了，而且若不输入秘钥，平台会自动生成。因此在上述创建设备的过程中，我是添加了秘钥的，在这种情况下，Demo代码也要对应的做出一点点修改，

#if 0
#define cn_endpoint_id        "BearPi_0001"
#define cn_app_server         "119.3.250.80"
#define cn_app_port           "5683"
#else
#define cn_endpoint_id        "67fb1c725367f573f7825201_8600xxxxxxxxxxx3"
#define cn_app_server         "124.70.30.197"
#define cn_app_port           "5684"   //使用coaps协议
#define cn_app_pskid           "8600xxxxxxxxxxx3"
#define cn_app_psk             "0xxxxxxxxxxxxxxxxxxxxx"
#define cn_app_psklen          22
#endif

代码修改后，记得重新编译和烧录。

编解码插件

在注册设备环节，使用哪种方式注册设备都该是你没有问题。但若你沉浸于在线文档，没有认真思考，就会遇到如下问题，

异常信息不难理解，对啊，我还没有开发编解码插件呢？在线说明书竟然跳过了这一步，我也很纳闷。在十几分钟的时间内，我甚至怀疑，难不成使用以下（产品详情->在线调试->新增测试设备）方法创建注册的设备，不需要开发编解码插件？我看了Demo中的源码，确认发出的是二进制数据，又在在线文档中零散的查询了些资料，最终我确定，无论哪种方案注册的设备，在Coap协议下，必须要开发编解码插件。再后来，在小熊派社区提供的教程中，也看到了相关的说明。自己水平不足，文档又不给力，就是这么费劲。

结合在线说明书中的产品模型服务列表和服务能力列表，

结合源代码中的消息标识和结构定义，

#define cn_app_connectivity    0 //对应服务类型Connectivity //实时监测信号质量
#define cn_app_lightstats      1 //对应服务类型Button //监测F2按键的状态 
#define cn_app_light           2 //对应服务类型Sensor //实时监测光照强度
#define cn_app_ledcmd          3 //对应服务类型LED /下发命令
#define cn_app_cmdreply        4 //对应服务类型LED /命令响应

#pragma pack(1)
//对应服务类型Connectivity //实时监测信号质量
typedef struct {
    int8_t msgid;
    int16_t rsrp;
    int16_t ecl;
    int16_t snr;
    int32_t cellid;
}app_connectivity_t;

//对应服务类型Button //监测F2按键的状态 
typedef struct {
    int8_t msgid;
    int16_t tog;
}app_toggle_t;

//对应服务类型Sensor //实时监测光照强度
typedef struct {
    int8_t msgid;
    int16_t intensity;
}app_light_intensity_t;

//对应服务类型LED /下发命令
typedef struct {
    int8_t msgid;
    uint16_t mid;
    char led[3];
}app_led_cmd_t;

//对应服务类型LED /命令响应
typedef struct {
    int8_t msgid;
    uint16_t mid;
    int8_t errorcode;
    char curstats[3];
}app_cmdreply_t;

#pragma pack()

结合上述两类信息，进行编解码插件的图形化开发，添加如下消息，并绑定产品模型的属性和命令。

还要注意的是，完成编解码插件开发后，主要右上角的部署操作。

数据结果

以上述光照强度为例，由于代码上报频率设置和网络延迟等，其变化频率是很慢的，不要着急，耐心观察。

本地调试