本帖最后由 Zarlinq 于 2019-3-1 15:25 编辑
（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里调用该库进行开发并完成编译。
/*———————————哪里来的线？————————————————*/
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: ${**}/driverlib/${COMPILER}/libdriver.a”），其他部分基本可以暂时不管。
所以，依然采用常规的修改例程的方式来建立项目的模板文件。
选取例程文件夹（TivaWareC/examples/)下任意一个文件夹（比如boards/ek-tm4c123gxl/blinky)，将整个文件夹复制到工作区根目录下（方便管理），作为模板文件夹。
由于此时文件夹的路径已然改变，所以需要修改项目模板中的Makefile，将其中**和IPATH的赋值从“../../../..”修改为“../TivaWareC”。
3、开始新的项目 (1)将模板文件夹复制一份到工作区根目录下作为项目文件夹，改名为预期的项目名称（假定为“test01”）； (2)修改工作区的code-workspace文件，将项目名称（“name”）和目录（“path”）作为一组值添加到“folder”项中（方便项目管理）； (3)项目文件夹中的文件名，以及Makefile中的内容，全部从模板文件夹的名称（“blinky”）改名为项目名称（“test01”）； (4)在VSCode的资源管理器中，在项目文件夹（test01）下新建文件夹“.vscode”，在文件夹“.vscode”下新建文件“tasks.json”，“tasks.json”内容为：
{ "version": "2.0.0", "tasks": [ { "label": "test01", "type": "shell", "command": "make", "args": [ "all" ], "group": "build", "presentation": { "reveal": "always", "panel": "new" }, "problemMatcher": "$msCompile" } ]}
//-------文件“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，暂放）
原贴为本人的文章：编译环境
| 
投票
