概述

本文詳細介紹了基于 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()

結合上述兩類信息，進行編解碼插件的圖形化開發，添加如下消息，并綁定產品模型的屬性和命令。

還要注意的是，完成編解碼插件開發后，主要右上角的部署操作。

數據結果

以上述光照強度為例，由于代碼上報頻率設置和網絡延遲等，其變化頻率是很慢的，不要著急，耐心觀察。

本地調試