（VSCode是最好的編輯器，沒有之一！嗯，就是這樣！） TI的處理器，官方庫是很豐富的，不論官方庫是否混亂、是否難理解，豐富多樣這一點就足夠吸引人，以至於總想著在VSCode里順利地操著官方庫來寫代碼。 前文提過，在VSCode下有兩種擴展插件可以盤弄TI的單片機開發，分別是“PlatformIO ...
（VSCode是最好的編輯器，沒有之一！嗯，就是這樣！）
TI的處理器，官方庫是很豐富的，不論官方庫是否混亂、是否難理解，豐富多樣這一點就足夠吸引人，以至於總想著在VSCode里順利地操著官方庫來寫代碼。
前文提過，在VSCode下有兩種擴展插件可以盤弄TI的單片機開發，分別是“PlatformIO IDE”和“IAR Embedded Workbench”，“PlatformIO IDE”由於採用自家的編譯環境，還不讓改#include路徑，劣勢是很明顯的，而“IAR Embedded Workbench”實際上有一大問題，就是對於同一個ewp文件（文件夾名稱不變，文件名稱不變），再次build的時候會被插件拒絕更新，這就很尷尬了！難不成，只能一次編譯？這不科學！
由於暫時找不到其他更好用的擴展插件，所以……嗯……怎麼辦呢？
我們知道，單片機開發中，C語言代碼可以用arm-none-eabi-gcc來編譯（項目文件和官方boot文件），然後鏈接成bin，過程可以由Makefile組織，Makefile可以由Cmakefile.txt在Cmake中生成（關於Cmake只是順帶一提，暫時不用，可以忽略），只要得到bin文件，剩下的就是燒寫而已。
在編譯過程中，不考慮項目文件的情況下，除了官方庫，我們主要還需要的是例如”startup_TM4C123.s”這樣的官方boot文件，將這些文件編譯、鏈接到項目文件中最終生成bin文件算是Keil和IAR這樣的IDE在build階段所做的最獨特的事（相對於號稱宇宙最強悍IDE的Visual Studio而言）。
所以，核心問題在於，是否能搞到以Makefile組織的常式，這樣我們可以通過常式中的文件來改自己的項目模板。
上述是思路，如下以TI的TivaWare C庫為例（這個庫文件比較充足，自帶全能光環，符合省心、省事、省時間的基本原則），在VSCode里調用該庫進行開發並完成編譯。
/*———————————哪裡來的線？————————————————*/
---必備插件：C/C++ for Visual Studio Code
---必備環境：Cygwin、GNU Arm Embedded Toolchain
1、精簡庫文件
TivaWare C庫中所有尾碼為dep、eww、ewd、ewp文件都是IAR相關文件，尾碼以uv開頭的文件都是Keil相關文件，尾碼為json的文件不知道做什麼用，名稱為“startup_ccs.c”、“startup_ewarm.c”、“startup_rvmdk.S”的文件是非gcc平臺啟動文件，這四種文件都可以直接刪除。
接著可以將所有名稱為“ewarm”、“ccs”、“rvmdk”的文件夾全部刪除。
這一波精簡可以砍掉上千個文件……
（可選：將TivaWare C庫的文件夾名稱“TivaWare_C_Series-2.1.3.156”改為“TivaWareC”）
2、建立模板文件夾
通過查看常式中的Makefile文件，可以看到常式的Makefile（也包括庫文件的Makefile）先是調用了
makedefs文件的內容，而makedefs文件則把編譯環境整理的差不多了，Makefile剩下的內容則是針對常式本身的編譯、鏈接進行組織，其中關於啟動文件的一行（例如“${COMPILER}/blinky.axf: ${COMPILER}/startup_${COMPILER}.o”），關於分支庫（driverlib、grlib、IQmath、nfclib、sensorlib、usblib）每個文件夾可以有一行（例如“${COMPILER}/blinky.axf: ${ROOT}/driverlib/${COMPILER}/libdriver.a”），其他部分基本可以暫時不管。
所以，依然採用常規的修改常式的方式來建立項目的模板文件。
選取常式文件夾（TivaWareC/examples/)下任意一個文件夾（比如boards/ek-tm4c123gxl/blinky)，將整個文件夾複製到工作區根目錄下（方便管理），作為模板文件夾。
由於此時文件夾的路徑已然改變，所以需要修改項目模板中的Makefile，將其中ROOT和IPATH的賦值從“../../../..”修改為“../TivaWareC”。
3、開始新的項目
(1)將模板文件夾複製一份到工作區根目錄下作為項目文件夾，改名為預期的項目名稱（假定為“test01”）；
(2)修改工作區的code-workspace文件，將項目名稱（“name”）和目錄（“path”）作為一組值添加到“folder”項中（方便項目管理）；
(3)項目文件夾中的文件名，以及Makefile中的內容，全部從模板文件夾的名稱（“blinky”）改名為項目名稱（“test01”）；
(4)在VSCode的資源管理器中，在項目文件夾（test01）下新建文件夾“.vscode”，在文件夾“.vscode”下新建文件“tasks.json”，“tasks.json”內容為：
1 { 2 "version": "2.0.0", 3 "tasks": [ 4 { 5 "label": "test01", 6 "type": "shell", 7 "command": "make", 8 "args": [ 9 "all" 10 ], 11 "group": "build", 12 "presentation": { 13 "reveal": "always", 14 "panel": "new" 15 }, 16 "problemMatcher": "$msCompile" 17 } 18 ] 19 }tasks.json
//-------文件“tasks.json”也可以通過按下F1，輸入tasks，
//選擇“tasks:Configure task”（任務：配置任務），來讓VSCode自動生成，
//但內容要註意修改！
(5)快捷鍵Ctrl+Shift+B（替代方式為按下F1後輸入tasks，選擇Run Task），選擇任務test01，可以進行編譯，在項目文件夾下的gcc目錄中能夠看到生成的bin文件。
開始搬磚……搬磚……磚……
4、修正引用關係
對於分支庫（driverlib、grlib、IQmath、nfclib、sensorlib、usblib）的調用，對照著常式直接在Makefile里添加對.a文件的依賴行即可，但TivaWare C庫中還有其他庫文件可以#include，比如freeRTOS.h，此時對於依賴關係，對照著freertos_demo常式中的Makefile文件內容，相應修改即可。
/*———————————線到哪裡去？————————————————*/
關於搬磚過程中，代碼補全的問題，可以按快捷鍵Ctrl+Shift+P，選擇“C/C++:Edit configurations…”，在“includePath”項中，將”${workspaceFolder}/**”修改為"${workspaceFolder}/../TivaWareC"，然後重新打開工作區即可（有時候不用重新打開也行）。
這種方式完全採用Makefile完成生成bin文件的過程，arm-none-eabi-gcc.exe是由Cygwin下的make.exe調用的（arm-none-eabi-gcc.exe需要在命令行中能夠調用，即需要添加所在目錄至系統環境變數path中），所以對於VSCode的設置而言，完全不需要考慮編譯器、鏈接器等設置……所幸，TI的TivaWare C庫比較完整，工程文件安排比較合理……但對於其他一些廠商的庫（不考慮Arduino和STM32，這倆貨用這種方式純屬捨近求遠），應當特別註意Makefile的內容是否完整可靠。
至於調試嘛……留個串口來輸出調試信息如何？
/*———————————沒有看到線！————————————————*/
從上述思路想到，如果用Cmake來生成Makefile，也許能更好的解決依賴項的問題……（但是還不會寫Cmake，暫放）
