★ FEATURED ARTICLE 用惯了 Keil 的人多半都吐槽过它的编辑器代码补全基本等于没有跳转定义经常失灵高亮和主题也停留在十年前的水平。但 Keil 的编译器、链接脚本和下载调试流程又是嵌入式开发绕不开的成熟方案。VSCode Keil 这套组合就是让 VSCode 负责写代码Keil 负责编译烧录两边干各自最擅长的事。这篇文章我会把从安装到日常使用的完整过程捋一遍包括工具链的工作原理、每个配置项为什么这么设以及我实际踩过的坑。适合刚接触单片机开发、想改善编码体验的朋友也适合已经在用 Keil、想换一套更舒适的编辑环境的开发者。1. 为什么是VSCode加Keil这个组合解决的问题1.1 Keil编辑器让我忍不了的几个点Keil MDK 是老牌嵌入式 IDE在 STM32、C51、M0 这类项目上它的编译器亲和度最好出问题少芯片厂商给的库和例程也都是围绕 Keil 工程组织的。但它的编辑器体验确实跟不上时代函数跳转偶尔失灵结构体成员提示不全光标操作、多选编辑这些现代编辑器的基础功能更是一个没有。大一点的项目在一个几千行的文件里靠 CtrlF 找定义效率实在太低了。我最早接触 Keil 的时候以为写单片机代码就是这样直到在一台机器上装了 VSCode 做对比才发现差距有多大。VSCode 打开工程后代码高亮、鼠标悬停看类型、Ctrl点击跳转定义、全局搜索引用这些东西几乎是开箱即用的。把编辑和编译分开等于把两个工具各自最擅长的能力都用上了。1.2 VSCode和Keil的分工逻辑这套环境的核心思路是VSCode 只做一个前端编辑器Keil 在后台作为编译器和调试器。具体分工如下环节负责工具说明代码编辑、补全、跳转VSCode通过 C/C 插件提供 IntelliSense工程文件解析Keil Assistant 插件直接读取 .uvprojx 工程文件编译、链接Keil 编译器工具链调用 UV4.exe 或 armclang 在后台编译下载程序Keil 的 FLM 烧录算法通过 ST-Link / J-Link 等调试器写入在线调试Keil 调试器或 Cortex-Debug打断点、看变量、寄存器中间的关键连接点是 Keil 工程文件 .uvprojx。它是一份 XML 格式的文件包含了源文件清单、编译选项、芯片型号、烧录算法等所有配置。Keil Assistant 插件解析这个文件把工程结构展示在 VSCode 侧边栏里编译和下载按钮直接调用 Keil 的命令行接口完成。1.3 几种常见替代方案的对比在决定用这套组合之前我确实比较过其他路线这里把我的对比结论放出来供参考。方案优点缺点适合场景纯 Keil官方出品兼容性最稳编辑器体验差不想折腾环境的人VSCode Keil Assistant编辑强编译烧录沿用 Keil零迁移成本调试仍需回到 Keil 或额外配置大多数基于 Keil 工程的中小项目VSCode CMake Ninja GCC全流程现代化编译速度快需要自己改工程结构、写 CMakeLists新项目、有一定工程能力的人其他 IDE如 IAR、Eclipse各有特色配套资料少迁移成本高特定芯片或特定团队要求如果你是手头已经有一堆 Keil 工程不想动工程结构只希望提升写代码的舒适度VSCode Keil 是最平滑的方案。不需要迁移工程不需要写 CMake装好插件直接把 .uvprojx 拖进去就能用。这也是我写这篇博文想重点讲的路线。2. 环境搭建前的核心组件与工作原理2.1 工具链的四个角色先弄清楚这套环境里有哪些角色后面配置的时候才知道每一步在干嘛。第一个角色是Keil MDK 本体。它提供编译器、链接器、芯片支持包Pack、烧录算法和调试引擎。装好 Keil 意味着你已经有了一条完整的编译下载链路。第二个角色是VSCode。它是一个通用编辑器本身不懂单片机但通过插件可以具备 C/C 开发能力。第三个角色是C/C 插件微软官方那款。它负责代码补全、语法检查、跳转定义、悬停提示。它不参与编译只分析和展示代码。第四个角色是Keil Assistant 插件。它负责解析 .uvprojx把 Keil 的编译、下载动作封装成 VSCode 里的按钮。没有它VSCode 无法知道你打开的是什么芯片、有哪些源文件、用什么编译器选项。2.2 UV4.exe命令行接口一切自动化的基础Keil 的命令行工具是 UV4.exe一般位于 Keil 安装目录的 UV4 文件夹下。它的常用参数有UV4.exe -b 工程名.uvprojx -o build.log -j0各参数的含义我实际解释一下-b表示构建Build打开工程并编译。-r表示重新构建Rebuild相当于 Keil 里的“重新编译所有目标”。-o指定输出日志文件的路径编译信息会写入这个文件而不是弹 GUI 窗口。-j0表示编译结束后自动关闭软件避免弹窗阻塞自动化流程。-f表示调用下载算法将程序烧录到芯片。-d表示调用调试器进入调试模式。这个接口是后面所有自动化操作的基础。VSCode 的编译任务本质上就是一条 UV4.exe 命令行理解了这一点你就知道 Keil Assistant 插件在后台做了什么也知道为什么它可以不打开 Keil 界面就完成编译。这里有个小提醒UV4.exe 一次只能处理一个工程而且如果 Keil GUI 正开着同一个工程命令行再用-b去编编译器可能报文件占用错误。所以我实际使用的习惯是日常用 VSCode 编译时保持 Keil 关闭要靠 Keil 调试试再打开它。2.3 Keil Assistant插件在中间扮演什么角色Keil Assistant 插件扩展 ID 为mcu-debug.keil-assisted直接在扩展市场搜索 Keil Assistant 能找到的工作流程是打开一个 .uvprojx 文件插件解析 XML识别出 Targets、源文件分组、编译宏定义、头文件路径、芯片型号等信息。在 VSCode 左侧资源管理器里生成一个 Keil 工程视图列出源文件和 target点一下就能打开对应代码。提供 Build、Rebuild、Download 三个按钮点击后通过 UV4.exe 执行对应操作。读取 UV4.exe 生成的日志把编译错误和警告解析成 VSCode 的“问题”面板这样你可以 Ctrl点击错误直接跳到对应文件行。有一点要说明这个插件在插件市场上现在显示为已弃用deprecated但实测下来核心功能仍然正常社区里大量开发者还在用它。如果你在意维护状态也可以选择手动配置 tasks.json 调用 UV4.exe效果类似只是少了工程文件解析和按钮。我建议新手先用这个插件把流程跑通后再考虑要不要手动配置。3. 完整安装配置流程从零到编译烧录一次跑通3.1 安装Keil与芯片器件包第一步是安装 Keil MDK。去 Keil 官网下载最新版本现在是 MDK v5 系列安装包是标准 Windows 安装程序一路 Next 就行。安装目录建议保持默认或者使用纯英文无空格的路径比如D:\Keil_v5不要装在C:\Program Files (x86)这种带空格和括号的路径后面在配置脚本时容易出幺蛾子。装完 Keil 之后还要装芯片器件包Device Family Pack。比如用 STM32F1 系列需要到 Keil 官网的 Pack 页面下载对应的 STM32F1xx_DFP然后在 Keil 的 Pack Installer 里双击导入。这个包里面包含了 SVD 文件、Flash 编程算法、启动文件模板等没有它 Keil 无法识别芯片也就无法编译和下载。这里提醒新手一个容易忽略的点有时候你在 Keil 里能看到芯片型号但打开工程编译时提示缺设备就是因为器件包版本不对或没装全。建议在 Pack Installer 的 Devices 标签页里搜到你的芯片型号确认右侧状态显示 Installed。3.2 安装VSCode和必备插件安装 VSCode 就没有什么特别的了从官网下安装包安装时可以勾选“添加到 PATH”和“打开支持”后面用命令行启动比较方便。打开 VSCode 后在扩展商店搜索并安装以下插件插件作用备注C/C微软官方提供 IntelliSense、跳转、调试支持必装Keil Assistant解析 Keil 工程、提供编译烧录按钮必装Cortex-Debug在 VSCode 里直接调试 Cortex-M 芯片需要调试时安装Encoding Helper / GBK 支持解决 Keil 源文件中文乱码问题强烈建议装Cortex-Debug: Device Support PackCortex-Debug 的器件支持扩展使用 Cortex-Debug 时需要安装完这些插件后先把 VSCode 的默认字符集设置为自动检测。很多 Keil 工程里的源文件是 GBK 编码而 VSCode 默认用 UTF-8 打开直接打开会满屏乱码注释全是“锟斤拷”。设置方法打开设置Ctrl,搜索files.autoGuessEncoding勾选“Controls whether the editor should guess the character encoding when opening a file”或者直接在 settings.json 里加上files.autoGuessEncoding: true这一步务必在做其他配置之前搞定否则你打开一个老工程看到满屏乱码会瞬间没心情继续。3.3 配置Keil Assistant并打开第一个工程装好 Keil Assistant 后需要在扩展设置里指定 Keil 的安装路径。打开 VSCode 设置搜索Keil.Assistant在 Keil 路径那里填 UV4.exe 的完整路径比如D:\Keil_v5\UV4\UV4.exe然后随便找一个 Keil 工程目录用 VSCode 的“文件 - 打开文件夹”打开工程所在目录在文件列表里找到.uvprojx文件右键选择“Open with Keil Assistant”。插件会解析这个工程在资源管理器下方出现 Keil 工程视图。这里有一个操作细节值得注意不要用“文件 - 打开文件”直接打开 .uvprojx那样 VSCode 只会把它当 XML 文本展示没有工程化处理。正确姿势是先把整个工程目录作为文件夹打开再通过右键菜单交给 Keil Assistant。工程打开后左侧会列出 Targets编译目标、源文件组、源文件。双击源文件就可以在 VSCode 里编辑了代码补全和语法高亮此时应该已经工作。3.4 配置C/C智能提示消灭红色波浪线Keil Assistant 解析的是 Keil 的工程配置但 VSCode 的 C/C 插件并不读 .uvprojx它需要自己的配置。打开一个源文件你会发现满屏红色波浪线因为 IntelliSense 不知道头文件在哪里、芯片的宏定义是什么。在 VSCode 中按 CtrlShiftP输入C/C: Edit Configurations (UI)打开配置界面。重点关注这几个字段配置项填什么为什么这么填编译器路径D:\Keil_v5\ARM\ARMCC\bin\armcc.exeAC5 编译器或D:\Keil_v5\ARM\ARMCLANG\bin\armclang.exeAC6让 IntelliSense 知道用哪套编译器的规则来解析语法IntelliSense 模式windows-gcc-x64或windows-armcc影响语法分析方式选错可能导致结构体解析异常包含路径把 Keil 工程用到的所有头文件目录都加进来包括芯片官方库的Libraries\CMSIS\Device\ST\STM32F1xx\Include、Libraries\STM32F10x_StdPeriph_Driver\inc等不添加就无法找到头文件波浪线最多的地方就是这个宏定义如USE_STDPERIPH_DRIVER, STM32F10X_MD或你工程需要的宏Keil 工程里在 C/C 的 Define 列表里有对应内容照抄过来配置之后会在工程目录下生成.vscode/c_cpp_properties.json文件。如果不想用 UI 界面也可以手动编辑这个 JSON一个典型的配置长得像这样{ configurations: [ { name: Win32, includePath: [ ${workspaceFolder}/**, D:/Keil_v5/ARM/ARMCC/arm_compiler/include, D:/Keil_v5/ARM/Packs/Keil/STM32F1xx_DFP/2.3.0/Device/Include ], defines: [ USE_STDPERIPH_DRIVER, STM32F10X_MD ], compilerPath: D:/Keil_v5/ARM/ARMCC/bin/armcc.exe, cStandard: c99, cppStandard: c11, intelliSenseMode: windows-gcc-x64 } ], version: 4 }在调整包含路径时建议直接引用 Keil Pack 安装目录下的头文件路径而不是复制一份到工程目录。原因很直接芯片厂商更新 Pack 时你会自动获得最新寄存器定义如果复制一份到工程里更新了 Pack 以后你只会用到旧版本的拷贝排查寄存器名不对的问题时会非常困惑。配置完成后重启 VSCode 窗口或者等待几秒让 IntelliSense 重新加载红色波浪线会明显减少。如果还有通常是某个宏定义缺失或某个头文件目录没加全根据错误提示逐个补。3.5 在VSCode里完成编译、下载编译不需要打开 Keil。在 VSCode 的 Keil 工程视图里鼠标悬停在工程名或某个 Target 上会出现几个按钮Build增量编译只编译改动的文件日常开发用这个。Rebuild重新编译所有文件改动了工程配置后会用。Download编译完成后调用烧录算法把程序写进 Flash。如果你看不到这些按钮可能是 Keil Assistant 插件没有识别到 Keil 路径或者 .uvprojx 文件打开方式不对回到 3.3 节检查一遍。点击 Build 后插件会在终端窗口调用 UV4.exe。编译日志会显示在输出面板里错误和警告会被解析到“问题”面板。按 CtrlShiftM 打开问题面板点击某条错误就会跳到源文件对应的行。下载之前要保证调试器连接正常。我这里用的是 ST-Link接好 SWD 四根线SWDIO、SWCLK、GND、3.3V在 Keil 里把 Debug 选项设置为 ST-Link并确认 Settings 里能识别到芯片型号。注意这里说的“在 Keil 里设置”指的是在 Keil 工程选项里设置这套环境编译下载用的还是 Keil 的下载引擎所以调试器配置依然在 Keil 的工程选项中完成。第一次 Download 时如果 Keil Assistant 的按钮失效报Target not connected或No ULINK/ME found先别急着折腾插件去 Keil 里手动下载一次排除硬件连接和驱动的问题。因为这个时候问题多半在调试器驱动、接线或芯片供电上而不是 VSCode 的配置。3.6 工程路径与编码的预设置这一步是我后来反复踩坑后总结出来的值得在一开始就设好。首先整个 Keil 工程路径尽量不要有中文、空格和特殊符号。编译器、烧录算法、C/C 插件解析路径时在不同环节对非 ASCII 字符的容忍度不一样。路径带中文轻则某些工具链处理不了重则 IntelliSense 全部失效或者烧录失败。我一般会把所有单片机工程放在D:\EmbeddedProjects\xxx这样的纯英文路径下。其次若你的工程目录里既有 UTF-8 文件又有 GBK 文件建议统一用手动设置编码的方式处理。在 VSCode 右下角状态栏点击编码显示选择“通过编码重新打开”选择 GBK 或 UTF-8保持文件原本编码不变。千万不要因为有乱码就用“保存为 UTF-8”去批量重存这些改动会在 Keil 里造成注释乱码因为 Keil 老版本默认按 GBK 读取源文件。4. 调试环境与自动化脚本的进阶配置4.1 方式一用Keil Assistant直接进入Keil调试最快的调试方式其实是不折腾。Keil Assistant 的工具链里有一个按钮是 Debug点击后它会调用 UV4.exe 的-d参数打开 Keil 的调试窗口进入断点调试。这个方案的好处是零额外配置调试体验和你在 Keil 里按 CtrlF5 完全一致缺点是又回到了那个古老的界面。这种方式适合快速验证一个问题比如功能出了 bug需要马上看某个变量的值或某个外设寄存器的状态。VSCode 里写完代码点编译点下载再点 Debug 进 Keil就能开始调试。整个过程衔接很顺不需要额外配置 launch.json。4.2 方式二用Cortex-Debug在VSCode里打断点调试如果你希望全程不离开 VSCode用现代调试器的体验来打断点、看调用栈、看变量那就要配置 Cortex-Debug。前提条件安装 Cortex-Debug 插件。调试器驱动已装好ST-Link 驱动或 J-Link 驱动。Keil 工程编译时勾选了 Debug Information默认是勾选的生成包含调试符号的 .axf 文件。这个文件通常在工程的 Objects 或 Listings 输出目录里。然后在工程目录下创建.vscode/launch.json一个适用于 ST-Link 的典型配置{ version: 0.2.0, configurations: [ { name: ST-Link Debug, cwd: ${workspaceFolder}, executable: ./Objects/xxx.axf, request: launch, type: cortex-debug, servertype: stlink, device: STM32F103C8, interface: swd, serialNumber: , svdFile: ./svd/STM32F103xxx.svd } ] }每个字段的含义我说一下executable指向 .axf 文件它就是编译产物里面既有机器码又有调试符号。路径根据你 Keil 工程的输出目录来如果 Keil 的 Output 目录改了这里要同步改。servertype选择你用的调试服务器ST-Link 写stlinkJ-Link 写jlink。Cortex-Debug 会自动启动对应的 OpenOCD 或 pyOCD 来连接调试器。device填芯片型号要和你 Keil 工程 Target 里的型号一致。interface一般用swd除非你用的是 JTAG。svdFile指向芯片的 SVD 外设描述文件。这个文件可以在芯片 Pack 的目录里找到搜索*.svd。填了之后调试时可以在外设寄存器窗口看到每个寄存器的位域含义强烈建议配置。配置完成后在 VSCode 里给源文件某一行打断点按 F5 启动调试。Cortex-Debug 会自动连接 ST-Link下载程序并停在断点处。变量监视、调用栈、寄存器窗口都在调试侧边栏里体验接近现代 IDE。有一点要注意Cortex-Debug 调试时Keil 工程里的 Debug 设置虽然不影响 Cortex-Debug 连接它走的是自己的调试器接口但芯片的烧录算法文件FLM是 Keil 下载时才用的。所以如果你用 Cortex-Debug 启动调试它能烧录程序吗实际上 Cortex-Debug 会把 .axf 加载到芯片内存或 Flash 里但它的烧录逻辑和 Keil 的 FLM 不一样某些芯片可能需要额外配置烧录算法。我遇到过的稳妥做法是先用 Keil Assistant 的 Download 按钮烧录一次再用 Cortex-Debug 只做调试这样把烧录和调试分离各自都用最可靠的路径。4.3 用批处理和tasks.json把编译烧录自动化Keil Assistant 的按钮够用了但如果你想更极致一点比如一键编译、编译后自动复制固件到某个目录或者远程跑构建脚本这时候就可以自己配置 tasks.json。在工程目录.vscode/tasks.json里新建一个编译任务{ version: 2.0.0, tasks: [ { label: Keil Build, type: shell, command: D:/Keil_v5/UV4/UV4.exe, args: [ -b, 你的工程名.uvprojx, -o, build_log.txt, -j0 ], group: { kind: build, isDefault: true }, problemMatcher: [ $gcc ] } ] }按 CtrlShiftB 即可触发编译。-o build_log.txt会把编译日志写到文件里配合 problemMatcherVSCode 能把日志中的 error 和 warning 解析到问题面板。$gcc这个 matcher 对 Keil 的 AC5 编译器输出基本有效如果解析不准可以改成$msCompile或自定义正则这里不展开了。批处理脚本也可以做同样的事。我在某项目上用了一个build.batecho off D:\Keil_v5\UV4\UV4.exe -b project.uvprojx -o build_log.txt -j0 if %errorlevel% equ 0 ( echo Build OK ) else ( echo Build FAILED, check build_log.txt type build_log.txt )这样做的价值有两个一是以后可以把编译集成到任何 CI 工具或 nightly build 脚本里二是当 Keil Assistant 插件某天真的不可用时你已经有了一条不依赖插件的编译通道。5. 常见问题与排查技巧实录5.1 编译相关问题一点 Build 没反应或者终端一闪而过。最常见的原因是 UV4.exe 的路径配置错误。Keil Assistant 的路径设置填的是 UV4.exe 的路径不是 Keil 安装目录。另外如果 Keil GUI 已经打开了同一个工程命令行编译会等待或失败关掉 Keil 再试。问题二编译报错但问题面板没有解析出任何内容。查看终端里 UV4.exe 的输出。如果你用了-o build_log.txt直接打开这个文件看。大部分编译错误在这里都能看到明确信息比如缺头文件、宏定义冲突等。问题面板解析不出来通常只是 matcher 的问题不影响实际编译。问题三编译速度明显比在 Keil 里慢。命令行编译和 Keil GUI 编译用的是同一套编译器速度不会有本质差别。如果你觉得慢先检查是不是杀毒软件实时扫描了每个中间文件某些安全软件对 .o 文件频繁扫描会造成明显延迟。把工程目录加入白名单会有不小改善。5.2 下载调试相关问题四Download 失败提示找不到目标设备。先回 Keil 手动下载一次。如果 Keil 里也失败检查调试器接线、芯片供电、调试器驱动。如果 Keil 里成功而 VSCode 里失败多数是 Keil Assistant 插件版本与当前 Keil 版本不兼容尝试更新插件或者暂时回到手动打开 Keil 下载。问题五Cortex-Debug 启动后停在启动配置连接不上调试器。检查 launch.json 里的device字段是否与芯片一致servertype是否为stlink。还有一个很容易忽视的点VSCode 的终端如果开着串口监视器比如你用串口调试助手并占用了串口ST-Link 的虚拟串口可能被占用导致调试器初始化失败。关掉串口工具再试。问题六调试时不能设置断点或者断点触发但位置错乱。这基本是调试符号没有正确加载。确认 .axf 文件路径正确、这个 .axf 是最近一次编译生成的、工程里 Debug Information 没有关闭。如果你用 Keil Assistant 下载之后再启动 Cortex-Debug务必先 Rebuild 一次否则 .axf 可能是旧的。5.3 编辑体验相关问题七打开源文件注释乱码。这是我碰到过最多的问题。Keil 老工程默认 GBK 编码VSCode 默认 UTF-8 打开。解决方案有两个在 settings.json 设置files.autoGuessEncoding: truevscode 会自动猜测编码。手动切换右下角点编码 - 通过编码重新打开 - 选择 GBK。比较推荐第二种因为 autoGuessEncoding 对于纯英文和注释混排的文件有时会猜错。另外千万别做的是把文件另存为 UTF-8Keil 那边再打开会乱。问题八智能提示还是不准结构体成员不出来。检查 c_cpp_properties.json 里的compilerPath是否指向了正确的编译器。指向 armclang.exe 的解析效果比 armcc.exe 更接近实际编译器的语法但 armclang 的 bin 目录里可能没有完整工具链所以更稳妥的做法是同时把编译器指向 Keil 自带的 armclang 路径并将intelliSenseMode设为对应选项实测提示质量比默认 gcc 模式好。问题九函数跳转经常跳错或者跳到头文件声明而不是定义。这个问题通常是因为工程里有多个同名函数或宏定义。C/C 插件的 IntelliSense 会优先选择当前 includePath 下最先找到的定义有时会跳到库文件里。解决办法是把工程源文件的目录放在 includePath 的最前面让工程自己的定义优先于库文件的定义被解析。5.4 几条值得记住的经验根据我自己的实操总结这几条经验虽然不在任何教程里但效果立竿见影第一保持 Keil 和 VSCode 的版本更新节奏同步。特别是 Keil 从 AC5 编译器转到 AC6armclang之后命令行的编译参数有些细微差别。如果你发现以前编译正常的工程突然报错先看是不是默认编译器切换了。第二不要把 .vscode 目录放进工程提交里。这个目录里的配置是跟机器相关的比如编译器路径在每台机器上可能不一样。团队协作时建议每个人各自生成自己的 .vscode 配置不要统一提交到代码仓库否则换一台电脑就报一堆路径错误。这个坑我在团队项目里踩过后来约定 .vscode 目录加入 .gitignore环境问题瞬间减少。第三大工程建议增量编译不要频繁 Rebuild。Keil 的 AC5 编译器对头文件依赖的追踪不算精细你改了某个头文件它可能不会触发所有相关文件的重新编译偶尔会出现改了头文件但编译结果没更新的情况。遇到这种怪问题时Rebuild 一次才能恢复。常规开发节奏是编辑代码 - Build - 下载只在确认工程配置有变动时才 Rebuild。第四用 VSCode 改代码时注意不要动 Keil 工程里由 IDE 自动生成的文件。比如.uvguix窗口布局文件、.bak备份文件VSCode 的搜索和格式化特性可能会不小心碰它们。在 .vscode 的 settings.json 里加一段 exclude 配置会很省心files.exclude: { **/*.uvguix: true, **/*.bak: true, **/Objects/**: true, **/Listings/**: true }这样文件树清爽很多也不会误改生成文件。最后再分享一个技巧如果你经常在多个 Keil 工程之间切换可以在 VSCode 里用“文件 - 将工作区另存为”把这些工程目录都加进来每个工程作为独立文件夹配合 Keil Assistant 一次打开、点每个 .uvprojx 就能快速切换。我在维护某公司的多款产品固件时就是这么干的省掉了反复打开关闭文件夹的操作切换工程的效率高了不少。对我来说VSCode Keil 不只是编辑器替代而是把整个嵌入式开发的日常流程理顺了用顺手之后确实回不去裸 Keil 了。
阅读完成 · 觉得有帮助？
