1. 為什么我最終把STM32的開發(fā)環(huán)境從Keil搬到了VS Code搞STM32的朋友大概率都經(jīng)歷過這個階段一開始用Keil或者IAR編譯下載調(diào)試一條龍確實省心。但用久了就會碰到幾個繞不過去的坎——代碼補全基本靠猜、界面停留在上個時代、跨平臺協(xié)作幾乎不可能、版本管理一團糟。尤其是當(dāng)項目里同時有STM32固件、上位機Python腳本、還有一些前端配置的時候在幾個IDE之間來回切換簡直是折磨。我大概是從兩年前開始認(rèn)真考慮把STM32的開發(fā)環(huán)境遷移到VS Code上。動機很樸素我日常寫代碼的主力編輯器就是VS Code如果能把嵌入式開發(fā)也統(tǒng)一進來整個工作流會順暢很多。但說實話第一次嘗試的時候踩了不少坑——插件選型混亂、編譯工具鏈配不通、調(diào)試器連不上、中文亂碼、頭文件路徑找不到……這些問題每一個都夠折騰半天。后來經(jīng)過幾個項目的反復(fù)打磨我總結(jié)出了一套相對穩(wěn)定、可復(fù)現(xiàn)的VS Code STM32開發(fā)環(huán)境搭建方案。這套方案的核心思路是用VS Code做代碼編輯和項目管理用ARM GCC做編譯工具鏈用OpenOCD或J-Link做下載調(diào)試用Makefile或CMake做構(gòu)建管理。整套環(huán)境完全開源、跨平臺、可版本控制而且代碼補全和跳轉(zhuǎn)體驗比Keil好出一個量級。這篇文章我會把這套方案完整拆開講從工具選型、環(huán)境安裝、工程配置到調(diào)試實操再到常見問題排查盡量做到你照著做就能跑通。適合已經(jīng)有一定STM32基礎(chǔ)、想提升開發(fā)效率的工程師也適合剛?cè)腴T想直接上手現(xiàn)代工具鏈的新手。文章會比較長建議收藏后按需查閱。2. 整體方案設(shè)計與工具選型思路2.1 為什么選VS Code而不是繼續(xù)用Keil先說結(jié)論Keil能做的事VS Code都能做但VS Code能做的事Keil不一定能做。這不是貶低KeilKeil在STM32開發(fā)領(lǐng)域的地位毋庸置疑它的優(yōu)勢在于開箱即用、生態(tài)成熟、調(diào)試器兼容性好。但它的短板也很明顯代碼編輯體驗落后智能補全、代碼跳轉(zhuǎn)、重構(gòu)功能基本停留在十年前的水平跨平臺支持差macOS和Linux用戶基本被排除在外版本管理不友好工程文件是二進制格式Git diff基本看不出改了什么插件生態(tài)封閉想集成個代碼格式化、靜態(tài)檢查工具都很麻煩多項目管理困難同時開幾個工程窗口切換很繁瑣VS Code恰好在這些方面全面勝出。它的IntelliSense基于clangd或C/C插件代碼補全和跳轉(zhuǎn)精度非常高Git集成是原生級別的插件市場里有大量嵌入式開發(fā)相關(guān)的擴展而且完全跨平臺Windows、macOS、Linux體驗一致。當(dāng)然VS Code不是沒有代價。它本身只是一個編輯器編譯、下載、調(diào)試這些功能都需要額外配置工具鏈。這就是為什么很多人嘗試后放棄了——配置成本確實比Keil高。但一旦配好后續(xù)的開發(fā)效率提升是值得的。2.2 工具鏈的組成與各自職責(zé)整套環(huán)境由以下幾個部分組成我先把它們的關(guān)系理清楚組件作用推薦選擇代碼編輯器寫代碼、補全、跳轉(zhuǎn)VS Code編譯器把C/C源碼編譯成機器碼ARM GNU Toolchain (arm-none-eabi-gcc)構(gòu)建工具管理編譯流程、依賴關(guān)系Make 或 CMake調(diào)試服務(wù)器連接調(diào)試器和芯片OpenOCD 或 J-Link GDB Server調(diào)試器硬件物理連接PC和STM32ST-Link / J-Link / DAPLinkVS Code插件把上述工具集成到編輯器Cortex-Debug、C/C、Makefile Tools這個架構(gòu)的核心邏輯是VS Code負(fù)責(zé)編輯體驗命令行工具負(fù)責(zé)實際干活插件負(fù)責(zé)把兩者粘合起來。理解這一點很重要因為后續(xù)所有配置問題基本都出在粘合環(huán)節(jié)。2.3 兩種構(gòu)建方案Makefile vs CMake在實際操作中構(gòu)建系統(tǒng)有兩種主流選擇方案一Makefile。這是最傳統(tǒng)的方式STM32CubeMX可以直接生成Makefile工程。優(yōu)點是簡單直接、依賴少、編譯速度快缺點是手寫Makefile比較繁瑣跨平臺時需要處理路徑分隔符等問題。方案二CMake。更現(xiàn)代的構(gòu)建系統(tǒng)STM32CubeMX從較新版本開始也支持生成CMake工程。優(yōu)點是跨平臺好、依賴管理清晰、支持復(fù)雜的項目結(jié)構(gòu)缺點是學(xué)習(xí)曲線稍陡配置不當(dāng)容易出現(xiàn)各種找不到文件的錯誤。我的建議是如果你是新手或者項目比較簡單直接用Makefile如果你需要跨平臺協(xié)作或者項目結(jié)構(gòu)復(fù)雜上CMake。本文主要基于Makefile方案講解因為它的配置過程更透明出問題時更容易定位。2.4 調(diào)試器的選擇與對比調(diào)試器這塊市面上常見的有三種ST-LinkST官方出品價格便宜山寨版十幾塊兼容性好配合OpenOCD或ST-Link GDB Server都能用。缺點是山寨版質(zhì)量參差不齊偶爾會掉線。J-LinkSEGGER出品性能強、穩(wěn)定性好支持芯片范圍廣。缺點是正版價格貴山寨版有法律風(fēng)險。DAPLink開源方案很多開發(fā)板自帶性價比高。缺點是不同廠商的實現(xiàn)質(zhì)量差異大。我個人的配置是日常開發(fā)用ST-Link V2正版復(fù)雜項目用J-Link。OpenOCD對ST-Link的支持已經(jīng)非常成熟基本不會出問題。3. 環(huán)境搭建的完整實操流程3.1 第一步安裝VS Code和基礎(chǔ)插件VS Code的安裝沒什么好說的官網(wǎng)下載對應(yīng)平臺的安裝包一路下一步即可。安裝完成后有幾個基礎(chǔ)設(shè)置建議先調(diào)整關(guān)閉自動更新嵌入式開發(fā)環(huán)境講究穩(wěn)定不建議頻繁更新。在設(shè)置里搜索update.mode改為manual。配置文件編碼為UTF-8搜索files.encoding設(shè)置為utf8。這個很重要后面講中文亂碼時會詳細(xì)說。開啟自動保存搜索files.autoSave設(shè)置為afterDelay避免忘記保存導(dǎo)致編譯的是舊代碼。接下來安裝核心插件。打開擴展面板CtrlShiftX依次搜索并安裝C/CMicrosoft出品提供代碼補全、跳轉(zhuǎn)、錯誤檢查。這是必裝插件。Cortex-Debug專門用于ARM Cortex-M調(diào)試的插件支持OpenOCD、J-Link、ST-Link等多種調(diào)試服務(wù)器。Makefile Tools如果你用Makefile構(gòu)建這個插件能提供目標(biāo)識別、編譯錯誤解析等功能。ARM Assembly提供匯編語法高亮看啟動文件時有用。Chinese (Simplified)中文語言包看個人習(xí)慣。注意C/C插件和clangd插件不要同時裝兩者功能重疊會沖突。我推薦用Microsoft的C/C插件配置更簡單。3.2 第二步安裝ARM GCC工具鏈ARM GCC是整套環(huán)境的核心沒有它什么都編譯不了。下載地址在ARM官方開發(fā)者網(wǎng)站選擇對應(yīng)平臺的安裝包。Windows下的安裝要點下載arm-gnu-toolchain-xxx-mingw-w64-i686-arm-none-eabi.exe32位或x86_64版本安裝時務(wù)必勾選Add path to environment variable這樣命令行才能直接調(diào)用安裝路徑不要有空格和中文建議用C:\arm-gnu-toolchain安裝完成后打開命令行驗證arm-none-eabi-gcc --version如果輸出了版本信息說明安裝成功。如果提示不是內(nèi)部或外部命令說明環(huán)境變量沒配好需要手動把bin目錄加到PATH里。驗證工具鏈?zhǔn)欠裢暾€需要檢查這幾個命令arm-none-eabi-gcc --version arm-none-eabi-gdb --version arm-none-eabi-objcopy --version arm-none-eabi-size --version這四個命令分別對應(yīng)編譯、調(diào)試、格式轉(zhuǎn)換、大小分析缺一不可。3.3 第三步安裝構(gòu)建工具MakeWindows下默認(rèn)沒有Make需要單獨安裝。推薦兩種方式方式一安裝MinGW。下載MinGW安裝器勾選mingw32-make組件。安裝后把bin目錄加到PATH然后把mingw32-make.exe復(fù)制一份改名為make.exe這樣就能直接用make命令了。方式二使用MSYS2。MSYS2提供了更完整的Unix工具集安裝后通過pacman -S make安裝。這種方式的好處是后續(xù)如果需要其他Unix工具如rm、cp也能直接用。macOS和Linux用戶通常自帶Make無需額外安裝。驗證命令make --version3.4 第四步安裝OpenOCDOpenOCD是連接調(diào)試器和芯片的橋梁。Windows下推薦從官方或第三方預(yù)編譯版本下載解壓后把bin目錄加到PATH。驗證安裝openocd --versionOpenOCD需要兩個配置文件一個是調(diào)試器接口配置如interface/stlink.cfg一個是目標(biāo)芯片配置如target/stm32f1x.cfg。這些文件在OpenOCD安裝目錄的scripts文件夾里都有后續(xù)在VS Code的調(diào)試配置里引用即可。3.5 第五步生成STM32工程用STM32CubeMX生成工程是最省事的方式。打開CubeMX選擇芯片型號配置好時鐘、外設(shè)、引腳然后在Project Manager里做幾個關(guān)鍵設(shè)置Toolchain/IDE選擇MakefileProject Name不要有中文和空格Project Location路徑不要有中文和空格Code Generator勾選Generate peripheral initialization as a pair of .c/.h files生成工程后目錄結(jié)構(gòu)大致如下Project/ ├── Core/ │ ├── Inc/ │ └── Src/ ├── Drivers/ │ ├── CMSIS/ │ └── STM32F1xx_HAL_Driver/ ├── Makefile ├── STM32F103C8Tx_FLASH.ld └── Project.ioc其中Makefile是構(gòu)建腳本.ld是鏈接腳本這兩個文件是編譯的核心。3.6 第六步配置VS Code工程用VS Code打開工程目錄然后創(chuàng)建.vscode文件夾里面放三個配置文件c_cpp_properties.json告訴C/C插件頭文件在哪里、宏定義是什么。{ configurations: [ { name: STM32, includePath: [ ${workspaceFolder}/Core/Inc, ${workspaceFolder}/Drivers/STM32F1xx_HAL_Driver/Inc, ${workspaceFolder}/Drivers/STM32F1xx_HAL_Driver/Inc/Legacy, ${workspaceFolder}/Drivers/CMSIS/Device/ST/STM32F1xx/Include, ${workspaceFolder}/Drivers/CMSIS/Include ], defines: [ USE_HAL_DRIVER, STM32F103xB ], compilerPath: C:/arm-gnu-toolchain/bin/arm-none-eabi-gcc.exe, cStandard: c11, cppStandard: c17, intelliSenseMode: gcc-arm } ], version: 4 }這里的defines必須和Makefile里的宏定義一致否則代碼補全會出現(xiàn)大量紅色波浪線。STM32F103xB這個宏是根據(jù)芯片型號來的不同型號不一樣可以在Makefile里找到。tasks.json定義編譯任務(wù)讓你可以在VS Code里直接按快捷鍵編譯。{ version: 2.0.0, tasks: [ { label: build, type: shell, command: make, args: [-j8], group: { kind: build, isDefault: true }, problemMatcher: [$gcc] }, { label: clean, type: shell, command: make, args: [clean] } ] }-j8表示用8個線程并行編譯能顯著加快編譯速度。根據(jù)你的CPU核心數(shù)調(diào)整。launch.json配置調(diào)試會話這是最關(guān)鍵也最容易出問題的部分。{ version: 0.2.0, configurations: [ { name: Debug (OpenOCD), type: cortex-debug, request: launch, servertype: openocd, cwd: ${workspaceFolder}, executable: ${workspaceFolder}/build/Project.elf, device: STM32F103C8, configFiles: [ interface/stlink.cfg, target/stm32f1x.cfg ], svdFile: ${workspaceFolder}/STM32F103xx.svd, runToEntryPoint: main, preLaunchTask: build } ] }幾個關(guān)鍵點說明executable指向編譯生成的.elf文件路徑要和Makefile的輸出路徑一致device填芯片型號Cortex-Debug會根據(jù)這個選擇調(diào)試參數(shù)configFiles里的兩個cfg文件路徑是相對于OpenOCD的scripts目錄的svdFile是可選的配了之后調(diào)試時能看到外設(shè)寄存器的值非常有用preLaunchTask設(shè)為build這樣每次調(diào)試前會自動編譯3.7 第七步編譯與下載驗證配置完成后按CtrlShiftB執(zhí)行編譯。如果一切正常終端會輸出編譯進度最后生成.elf、.hex、.bin文件。如果編譯報錯常見原因有找不到頭文件檢查c_cpp_properties.json里的includePath是否完整找不到編譯器檢查arm-none-eabi-gcc是否在PATH里Makefile報錯檢查Makefile里的路徑分隔符Windows下可能需要把/改成\編譯成功后按F5啟動調(diào)試。如果OpenOCD能連上芯片程序會下載并停在main函數(shù)入口。這時候你可以設(shè)置斷點、查看變量、單步執(zhí)行體驗和Keil基本一致但代碼編輯體驗好太多。4. 調(diào)試配置的深度解析與避坑指南4.1 OpenOCD配置文件的門道OpenOCD的配置文件分兩層interface和target。interface描述調(diào)試器硬件target描述目標(biāo)芯片。這兩個文件的選擇直接決定了能不能連上芯片。以ST-Link為例interface/stlink.cfg是通用配置但有些山寨ST-Link需要改用interface/stlink-v2.cfg或interface/stlink-v2-1.cfg。如果連不上可以逐個試。target文件的選擇要看芯片系列芯片系列target配置文件STM32F0target/stm32f0x.cfgSTM32F1target/stm32f1x.cfgSTM32F4target/stm32f4x.cfgSTM32F7target/stm32f7x.cfgSTM32H7target/stm32h7x.cfgSTM32G0target/stm32g0x.cfgSTM32L4target/stm32l4x.cfg選錯target文件會導(dǎo)致芯片識別失敗或者Flash編程出錯。4.2 SVD文件讓調(diào)試器看懂外設(shè)寄存器SVDSystem View Description文件是ARM定義的一種XML格式文件描述了芯片所有外設(shè)寄存器的地址、位域、讀寫權(quán)限等信息。配置了SVD文件后調(diào)試時可以在VS Code的側(cè)邊欄看到所有外設(shè)的寄存器狀態(tài)不用再手動查手冊算地址。SVD文件可以從ST官網(wǎng)或者Keil的芯片包Pack里提取。以STM32F103為例文件名叫STM32F103xx.svd放到工程目錄下然后在launch.json里用svdFile字段引用。提示SVD文件不是必須的但強烈建議配置。調(diào)試外設(shè)問題時能直接看到寄存器的值比在代碼里打斷點打印高效得多。4.3 中文亂碼問題的根治方案中文亂碼是STM32開發(fā)中的經(jīng)典問題根源在于編碼格式不統(tǒng)一。Keil默認(rèn)用GBK編碼而VS Code默認(rèn)用UTF-8兩者混用就會出現(xiàn)亂碼。解決方案有三個層次層次一統(tǒng)一源文件編碼為UTF-8。在VS Code設(shè)置里把files.encoding設(shè)為utf8然后打開每個源文件用CtrlShiftP調(diào)出命令面板執(zhí)行Change File Encoding選擇UTF-8保存。如果文件原來是GBK可以用Reopen with Encoding先以GBK打開再Save with Encoding存為UTF-8。層次二編譯器指定輸入編碼。在Makefile的CFLAGS里加上CFLAGS -finput-charsetUTF-8 -fexec-charsetUTF-8這樣編譯器會按UTF-8解析源文件按UTF-8生成字符串常量。層次三串口輸出端也要支持UTF-8。如果你的程序通過串口打印中文串口助手也要設(shè)置為UTF-8編碼否則PC端顯示還是亂碼。三個層次都統(tǒng)一成UTF-8后中文亂碼問題基本就根治了。我踩過的坑是只改了源文件編碼忘了改編譯器參數(shù)結(jié)果編譯出來的字符串還是亂的。4.4 調(diào)試時連不上芯片的排查思路這是新手最容易卡住的地方。按以下順序排查檢查硬件連接SWD接口的SWCLK、SWDIO、GND、VCC四根線是否接好。注意有些開發(fā)板的SWD接口順序不是標(biāo)準(zhǔn)的要對照原理圖。檢查調(diào)試器驅(qū)動Windows下ST-Link需要裝驅(qū)動設(shè)備管理器里能看到STLink USB Device才算正常。檢查OpenOCD能否單獨連上在命令行執(zhí)行openocd -f interface/stlink.cfg -f target/stm32f1x.cfg看輸出信息。如果提示Error: open failed說明調(diào)試器沒連上如果提示Info : stm32f1x.cpu: hardware has 6 breakpoints說明連上了。檢查芯片是否被讀保護有些芯片出廠時開了讀保護需要用ST-Link Utility或STM32CubeProgrammer解除保護。檢查復(fù)位電路有些板子的復(fù)位引腳接了電容導(dǎo)致SWD時序異?？梢栽贠penOCD配置里加reset_config none試試。4.5 編譯速度優(yōu)化技巧STM32工程文件多全量編譯可能要一兩分鐘。幾個優(yōu)化技巧并行編譯make -j8數(shù)字根據(jù)CPU核心數(shù)調(diào)整增量編譯Makefile本身支持增量編譯只編譯改動的文件。但如果頭文件改了依賴關(guān)系沒配好可能不會重新編譯這時候需要make clean后全量編譯ccache安裝ccache并配置為編譯器前綴能緩存編譯結(jié)果重復(fù)編譯時速度提升明顯預(yù)編譯頭文件把不常變的HAL庫頭文件預(yù)編譯能減少重復(fù)解析時間5. 常見問題速查與實戰(zhàn)經(jīng)驗5.1 編譯類問題速查表問題現(xiàn)象可能原因解決方法arm-none-eabi-gcc: command not found工具鏈未加入PATH把工具鏈bin目錄加到系統(tǒng)環(huán)境變量fatal error: stm32f1xx_hal.h: No such file頭文件路徑未配置檢查Makefile的C_INCLUDES和c_cpp_properties.jsonundefined reference to HAL_Init源文件未加入編譯檢查Makefile的C_SOURCES是否包含對應(yīng).c文件region FLASH overflowed代碼超出Flash容量優(yōu)化代碼或換更大Flash的芯片multiple definition of xxx變量在頭文件里定義頭文件里用extern聲明.c文件里定義cannot find -lc鏈接庫路徑錯誤檢查鏈接腳本和庫路徑配置5.2 調(diào)試類問題速查表問題現(xiàn)象可能原因解決方法OpenOCD連不上調(diào)試器驅(qū)動或接線問題檢查驅(qū)動、換USB口、檢查SWD接線下載后程序不運行復(fù)位向量或時鐘配置錯誤檢查鏈接腳本和SystemInit函數(shù)斷點不生效優(yōu)化等級過高調(diào)試時把優(yōu)化等級設(shè)為-O0變量值顯示不對變量被優(yōu)化掉加volatile關(guān)鍵字或降低優(yōu)化等級單步跳轉(zhuǎn)亂匯編和C對應(yīng)關(guān)系錯亂正常現(xiàn)象以C源碼為準(zhǔn)調(diào)試時芯片發(fā)熱引腳配置沖突檢查GPIO初始化避免推挽輸出短路5.3 我踩過的幾個典型坑坑一路徑里有中文或空格。這個問題看似低級但非常常見。ARM GCC和Make對中文路徑支持不好經(jīng)常報莫名其妙的錯誤。我的建議是所有工程路徑、工具鏈路徑、用戶名都盡量用純英文。如果Windows用戶名是中文可以在C盤根目錄建一個Dev文件夾專門放工程?？佣﨧akefile里的路徑分隔符。Windows下Makefile里用/通常沒問題但某些情況下需要\。如果遇到路徑解析錯誤可以試試把/改成\\?？尤齇penOCD版本和配置文件不匹配。不同版本的OpenOCD配置文件路徑和內(nèi)容可能有差異。建議用較新的穩(wěn)定版并且確保scripts目錄完整?？铀腣S Code的C/C插件緩存。有時候改了c_cpp_properties.json但代碼補全還是不對。這時候執(zhí)行CtrlShiftP→C/C: Reset IntelliSense Database重置一下緩存就好了。坑五調(diào)試時優(yōu)化等級。Release版本通常開-O2或-Os但調(diào)試時建議改成-O0 -g3否則變量被優(yōu)化掉、斷點跳轉(zhuǎn)混亂調(diào)試體驗極差?？梢栽贛akefile里根據(jù)DEBUG變量切換優(yōu)化等級。5.4 進階技巧集成代碼格式化和靜態(tài)檢查環(huán)境跑通之后可以進一步集成一些提升代碼質(zhì)量的工具clang-format統(tǒng)一代碼風(fēng)格。在工程根目錄放.clang-format文件VS Code里裝Clang-Format插件保存時自動格式化。cppcheck靜態(tài)代碼檢查能發(fā)現(xiàn)潛在的數(shù)組越界、空指針等問題。可以配置成VS Code的task編譯前自動跑一遍。Git hooks提交前自動跑格式化和靜態(tài)檢查保證入庫代碼質(zhì)量。這些工具不是必須的但用上之后代碼質(zhì)量會有明顯提升。尤其是團隊協(xié)作時統(tǒng)一的代碼風(fēng)格能減少很多無意義的diff。5.5 關(guān)于STM32CubeMX重新生成代碼的注意事項用CubeMX重新生成代碼時用戶代碼必須寫在/* USER CODE BEGIN */和/* USER CODE END */之間否則會被覆蓋。這是鐵律我見過太多人因為把代碼寫在外面重新生成后全沒了。另外如果修改了外設(shè)配置重新生成后要檢查Makefile是否更新了源文件列表。有時候CubeMX會新增.c文件但Makefile沒同步導(dǎo)致編譯報錯找不到函數(shù)。6. 從Keil遷移到VS Code的過渡策略如果你手頭有現(xiàn)成的Keil工程想遷移到VS Code有兩條路路線一用CubeMX重新生成。如果你的工程是用CubeMX創(chuàng)建的直接重新生成Makefile工程即可用戶代碼手動遷移。這種方式最干凈但需要重新配置外設(shè)。路線二手動移植。把Keil工程的源文件、頭文件、鏈接腳本提取出來自己寫Makefile。這種方式適合不用CubeMX的工程但工作量大容易漏文件。我的建議是優(yōu)先用路線一。CubeMX生成的工程結(jié)構(gòu)清晰、依賴完整后續(xù)維護也方便。遷移時注意幾點Keil的.uvprojx文件里的宏定義要同步到MakefileKeil的分散加載文件.sct要轉(zhuǎn)換成GCC的鏈接腳本.ldKeil的啟動文件startup_stm32f1xx.s要換成GCC版本的startup_stm32f1xx.s注意匯編語法不同遷移完成后建議先編譯一個最簡單的點燈程序驗證環(huán)境確認(rèn)無誤后再遷移業(yè)務(wù)代碼。7. 關(guān)于這套環(huán)境的一些個人體會這套VS Code ARM GCC OpenOCD的方案我從兩年前開始用中間經(jīng)歷過無數(shù)次配置調(diào)整現(xiàn)在算是比較穩(wěn)定了。最大的感受是前期配置成本確實高但一旦跑通后續(xù)的開發(fā)效率提升是數(shù)量級的。代碼補全的準(zhǔn)確率、Git diff的可讀性、多工程切換的流暢度這些都是Keil給不了的。尤其是當(dāng)項目里同時有STM32固件和Python上位機的時候一個編輯器全搞定不用來回切換。當(dāng)然這套方案也不是沒有缺點。比如調(diào)試體驗相比Keil還是稍遜一籌某些復(fù)雜斷點場景下OpenOCD不如Keil穩(wěn)定比如團隊協(xié)作時如果同事都用Keil你一個人用VS Code工程文件的管理會有些麻煩。但總體來說我覺得這個投入是值得的。尤其是對于需要長期維護的項目一套現(xiàn)代化、可版本控制、跨平臺的開發(fā)環(huán)境能省下大量溝通和維護成本。最后分享一個小技巧把.vscode文件夾加入Git版本控制。這樣團隊里其他人克隆工程后直接就有配好的編譯和調(diào)試任務(wù)不用每個人重新配一遍。當(dāng)然c_cpp_properties.json里的工具鏈路徑可能因人而異可以用${env:ARM_GCC_PATH}這樣的環(huán)境變量來適配不同機器。