最近不少做嵌入式的朋友来问我同一个问题Keil 官网上的 MDK 6 到底是个啥是不是就是之前的 Keil Studio 桌面版改了个名甚至有人装完 MDK 6 之后一脸茫然——怎么打开是个 VS Code这跟想象中那个蓝色界面的 µVision 完全不是一回事。先把结论扔在前面MDK 6 不是 Keil Studio 桌面版的换皮改名但它的 IDE 底座确实是从 Keil Studio 桌面版那边继承过来的。更准确的说法是Keil MDK 6 是把传统 MDK 的编译、调试、许可证体系和 Keil Studio 这套 VS Code 化的现代 IDE 工作流合二为一的新一代产品。这篇文章就把这个衍生关系、技术架构、迁移踩坑一次性讲清楚适合正在纠结要不要升级、以及想把老工程从 MDK 5 迁到 MDK 6 的开发者参考。1. Keil 家族产品线是怎么长出来的要理解 MDK 6得先知道 Keil 这几年把产品线拆成了几块。很多人一上来就懵是因为官方命名实在有点绕又是 MDK又是 Studio又是 Cloud又是 Desktop还有 µVision 和 VS Code 两条腿走路不梳理一下根本理不清。1.1 老读者熟悉的 µVision 时代µVision 是 Keil 的老牌 IDE从 C51 时代就用后来成了 MDKMicrocontroller Development Kit的标准界面。我们常说的装个 Keil90% 指的就是装 MDK 5装上之后打开 µVision 5在里面写代码、编译、烧录、调试。µVision 的核心优势是全流程闭环编辑、工程管理、编译、下载、调试、逻辑分析窗口全在一个应用里解决开了工程就能干活。配上 Keil 自家的 ULINK 或者 J-Link体验非常稳定。但它的缺点同样突出扩展生态几乎没有跨平台无望命令行和 CI/CD 支持非常弱工程文件虽然也是 XML.uvprojx但在 Git 多人协作时特别容易冲突改一个编译选项就给你整屏 diff。µVision 本身没啥大毛病只是时代变了。现代软件开发讲究编辑器可定制、版本管理友好、跨平台协同µVision 这套老架构越往后越吃力。1.2 Keil StudioARM 的一次重要试探ARM 很早就意识到微软的 VS Code 生态才是未来所以在 2021 年前后推出了 Keil Studio Cloud完全跑在浏览器里打开网页就能写代码、编译、烧录目的是降低新手入门门槛。云端版我试过几次demo 和在线例程做得不错适合临时翻翻例程、给客户演示但对正经开发来说浏览器远程编译的方式还是不够顺手。于是后来 ARM 又补上了 Keil Studio 桌面版。它本质不是一个新的 IDE而是一组 VS Code 扩展当时叫 Keil Studio Pack搭配 CMSIS-Toolbox 这类命令行工具让你在 VS Code 里完成 CMSIS-Packs 管理、编译、烧录、调试。我最初用的时候觉得有点简陋但 VS Code 的手感和扩展机制摆在那儿哪怕只是把工程文件打开、点一下编译都比 µVision 舒服。1.3 MDK 6 的定位到了 2024 年ARM 做了一件很直接的事把 Keil Studio 桌面版这套 VS Code 工作流正式吸收进 MDK 产品线配合 Arm Compiler 6、CMSIS-Toolbox、新一代 Pack 体系打包成 MDK 6。所以可以这样理解Keil Studio 桌面版是 ARM 在前几年做的技术试探MDK 6 则是把这个试探落地的正式产品。两者确实有血缘关系但 MDK 6 是完整的、有官方支持、有许可证体系的商业工具链Keil Studio 桌面版更多是技术预览社区探索性质的产物。产品形态IDE 基础支持平台定位µVision / MDK 5桌面 IDE原生 Windows 应用Windows存量主力传统闭环Keil Studio Cloud浏览器 IDEWeb任意在线学习、演示Keil Studio DesktopVS Code 扩展集合VS CodeWin/macOS/Linux早期技术预览MDK 6IDE 工具链套装VS CodeWin/macOS/Linux新一代 MDK 正式版2. 回答标题MDK 6 和 Keil Studio 桌面版的真正关系现在可以正面回答标题的问题了。我之前在文章开头说了不是同一回事但这里得展开讲清楚否则大家还是容易懵。2.1 MDK 6 从 Studio 桌面版继承了哪些东西第一个是 VS Code 底座。MDK 6 打开之后就是 VS Code 的界面左边是资源管理器下面是输出面板快捷键、多光标、插件体系全是 VS Code 那一套。你在快捷键、代码片段、主题上的所有 VS Code 使用习惯在 MDK 6 里都无缝继承。第二个是扩展化管理。MDK 6 的核心能力以 VS Code 扩展形式提供最常见的是 Keil Studio Pack 和 Cortex-Debug。要加功能就装扩展要移除就禁用扩展这套思维和 µVision 里全塞在一个大界面里完全不同。第三个是跨平台。MDK 5 只能跑在 Windows 上这一点卡了很多用 macOS 的开发者。MDK 6 可以直接在 macOS 和 Linux 上跑对于团队里有 Mac 用户、或者是做 Linux 服务器编译的场景这是质变。2.2 MDK 6 在 Studio 桌面版基础上补了什么Keil Studio 桌面版作为一个技术预览很多东西是不完整的。MDK 6 把它补成了正式商业工具。首先是许可证体系。MDK 6 沿用 MDK 的授权模式标准版、专业版、评估版FlexNet 授权服务器配置和管理方式与 MDK 5 大致类似。Studio 桌面版基本没有这套许可管理的概念更像一个开放工具集。其次是完整的 IDE 联动。MDK 6 不只是能在 VS Code 里编译而是把 Device 数据库、CMSIS-Packs 自动安装、调试配置、烧录流程全部集成进 VS Code 的工作流里。你在工程面板选一块芯片扩展会帮你拉对应的 DFPDevice Family Pack编译之后点击运行就会自动配置 Cortex-Debug 连上调试器。最后是官方保障。MDK 6 作为正式产品有发布周期、补丁更新、官方文档和售后支持。Studio 桌面版更像是大家一起试用反馈的社区项目今天能用明天可能就调整了指望它做产品化开发还是有点悬。2.3 为什么大家总是把两者搞混一方面是名字太像Keil Studio、Studio 桌面版、MDK 6长得确实像一家人。另一方面是界面太像MDK 6 打开之后的界面和 Keil Studio 桌面版几乎一样都是 VS Code 加扩展不仔细看根本分不出来。我最开始也被绕进去了实际对比之后才明白Studio 桌面版是给 VS Code 装一些嵌入式插件MDK 6 是一套完整的嵌入式开发环境只是外壳是 VS Code。装完 MDK 6 之后你的系统里会有完整的 Arm Compiler 6、CMSIS-Toolbox、Device Packs这些是一套真正的工具链而不只是几个插件。3. MDK 6 技术架构里的几个关键角色很多人装上 MDK 6 之后问我的编译按钮呢怎么没有 µVision 里的那些菜单这是因为 MDK 6 把底层架构换掉了。理解下面的几个角色你就明白 MDK 6 是怎么工作的。3.1 VS Code 底座与扩展机制VS Code 本身是编辑器不是 IDE。MDK 6 选择它核心原因有两个一是编辑器体验确实好代码补全、重构、Git 集成、多光标、终端这些都是 µVision 比不了的二是扩展机制成熟ARM 不用维护一套自己的插件市场直接把嵌入式工具做成扩展放到 VS Code 生态里就能用。在 VS Code 里做嵌入式开发核心扩展就几个Keil Studio Pack提供 MDK 6 的工程管理和编译命令、Cortex-Debug提供调试支持。装完之后左侧会出现一个 MDK/Keil 相关的面板用来管理 Packs 和设备编译命令可以绑定到 VS Code 的任务系统也可以直接用终端跑 cbuild。3.2 CMSIS-Toolbox把构建流程重做了CMSIS-Toolbox 是 MDK 6 里最容易被忽略但最核心的东西。它是一组命令行工具负责管理 Packs、描述工程、调用编译器完成构建。关键命令有三个csolution 负责解析工程描述文件cbuild 负责编译cpackget 负责安装和更新 Packs。工程描述文件和 µVision 的 uvprojx 完全不同它是 YAML 格式用 csolution 定义解决方案用 cproject 定义具体工程。大致长这样solution: created-for: STM32F103C8 packs: - pack: Keil::STM32F1xx_DFP compiler: AC6 target-types: - type: STM32F103C8 device: STM32F103C8 projects: - project: ./app.cproject.yml这种描述文件 命令行工具的构建模式天然适合 CI/CD。你想在持续集成服务器上编固件不用装 µVision只需要装好 CMSIS-Toolbox、Arm Compiler 6然后跑一行 cbuild 就行。这也是 MDK 6 相比 MDK 5 最本质的进步。3.3 armclangArm Compiler 6与 AC5 的差别MDK 6 默认使用 Arm Compiler 6也就是 armclang不再支持老旧的 AC5armcc。很多在 MDK 5 时代靠 AC6 编译的老手会比较熟悉但如果你一直用的是 AC5那这个变化需要认真看。armclang 基于 LLVM/Clang 架构对现代 C/C 标准支持更好编译告警信息更全生成的代码质量和编译速度都有提升。问题是它和 AC5 的底层差异很大编译器内置宏不同比如 __CC_ARM 在 armclang 里不存在、内联汇编语法不同、对 GCC 风格的attribute支持更好。老代码直接切过来大概率会有一堆编译报错。注意MDK 5 时代你可以在工程选项里把编译器从 AC5 切到 AC6这在一定程度上为 MDK 6 的迁移打了底。如果老工程在 MDK 5 下已经用 AC6 编译通过迁移到 MDK 6 会轻松很多如果一直是 AC5那就要做好改动代码的准备。3.4 CMSIS-Packs 与调试链路MDK 6 用 CMSIS-Packs 管理设备支持。你在工程里指定芯片型号后扩展会自动从官方库或者你配置的本地目录里安装对应的 DFP。Pack 里包含芯片头文件、系统初始化代码、Flash 算法、调试描述文件等基本把芯片厂商提供的支持包这个概念标准化了。调试方面MDK 6 走的是 VS Code 里的 Cortex-Debug 扩展。配置写在 launch.json 里支持的调试器包括 J-Link、ST-Link、CMSIS-DAP 等常见设备。配置示例如下{ version: 0.2.0, configurations: [ { name: Cortex Debug, cwd: ${workspaceFolder}, executable: ./build/out.axf, request: launch, type: cortex-debug, servertype: jlink, device: STM32F103C8, interface: swd } ] }相比 µVision 里那个点一下就能跑的调试按钮MDK 6 的调试初始配置门槛稍微高一点需要手动确认设备型号、调试器类型和固件路径。但配置完一次之后日常的打断点、看变量、单步执行体验都非常接近主流 IDE而且方便保存到 Git 仓库里共享给团队。4. 上手实操从安装到跑通第一个工程光说不练假把式。我装 MDK 6 的时候走了一些弯路这里直接按如果你现在开始装应该怎么做的流程讲。4.1 安装依赖与核心组件MDK 6 的安装和 MDK 5 不一样它不是下载一个几百兆的安装包一路下一步就完事而是需要几个组件配合。第一步装 VS Code。去官网下载最新版安装这个谁都会。建议在 VS Code 里把 C/C 扩展也装上代码提示会舒服很多。第二步装 MDK 6 本体。到 ARM Keil 官网下载 MDK 6 安装器它会帮你装好 Arm Compiler 6、CMSIS-Toolbox 以及默认的 Packs 目录。安装期间会要求选择许可类型可以先选 Evaluation评估版后续再激活正式 License。评估版有代码大小限制但学习验证完全够用。第三步在 VS Code 里装扩展。打开扩展面板搜索 Keil Studio Pack 和 Cortex-Debug安装即可。装完后 VS Code 会识别到 MDK 6 的安装路径并在命令面板CtrlShiftP里出现 MDK 相关的命令。提示整个安装过程不要选带中文的路径也别把工程放在中文目录下。ARM 工具链对中文路径的支持一直不友好这是从 MDK 5 时代就留下来的老毛病MDK 6 改善了一些但没必要踩坑。4.2 创建一个新的 MDK 6 工程安装完成后创建工程的路径有两条一条是直接用 VS Code 命令面板里的 MDK: New Project 向导跟着界面选芯片另一条是手动写 csolution/cproject 的 YAML 文件。我用向导创建的时候选择芯片型号比如 STM32F103C8扩展会自动下载安装对应 DFP并在当前文件夹生成工程骨架。之后打开 app.cproject.yml可以看到工程文件的组织方式然后就可以在 src 目录下添加 main.c 写代码了。有一点要提醒MDK 6 的工程文件是文本格式不像 uvprojx 那样在 VS Code 里打开是乱糟糟的 XML。YAML 文件结构清晰Git 对比时非常舒心这正是为现代团队协作设计的。我会建议把工程描述文件当成项目的一部分认真写好注释比什么都管用。4.3 编译、烧录与调试编译可以直接在 VS Code 终端里敲 cbuild 命令也可以绑定为 VS Code 的构建任务Task按 CtrlShiftB 触发。我第一次用 cbuild 时它自动检测到 CMSIS-Toolbox 和 armclang编译结束后输出 axf 和 hex 文件速度和 AC5 时代相比提升明显。烧录调试时把开发板通过 J-Link或板载 DAP-Link连到电脑上在 launch.json 里配好 servertype 和 device然后按 F5 启动调试。第一次配置时我因为 device 名称写错吃了亏后来发现直接填芯片型号如 STM32F103C8 就行没必要加厂商前缀。真正跑通之后你会发现这套工作流本质上和开发 PC 软件差不多编辑、编译、看报错、断点调试全部在 VS Code 里完成。对于习惯现代 IDE 的人来说体验是降维打击式的提升。5. 老工程迁移没有想象中顺利MDK 6 的常见使用场景其实是老工程切过来跑而不是新建一个空工程。新建工程你好我好老工程迁移才会暴露出一堆历史遗留问题。我迁移一个 STM32F1 的老工程时前后花了半天时间核心问题集中在下面几个地方。5.1 AC5 到 AC6 的编译器差异最大的坑来自编译器本身。老工程如果一直用 AC5 编译迁移到 MDK 6 后几乎一定会遇到编译失败。最常见的是宏定义问题代码里通过 __CC_ARM 判断编译器环境这个宏在 armclang 里不存在需要用 __ARMCC_VERSION 或clang替代。内联汇编的语法更是重灾区AC5 的 __asm 写法在 AC6 下经常被要求改成asm(...) 的标准格式。我的建议是升级前先在 MDK 5 的工程选项里把编译器从 AC5 切到 AC6把报错修完再迁移到 MDK 6。这样拆成两步走排查问题会效率高很多。5.2 启动文件与分散加载文件启动文件startup_xxx.s通常由芯片厂商提供但不同编译器需要的启动文件版本不一样。AC5 和 AC6 的启动文件在一些芯片型号上有差异GCC 和 IAR 更不一样。迁移时如果直接沿用旧启动汇编文件可能编译通过但在启动阶段就跑飞。分散加载文件.sct也要检查。AC5 时代写的一些 scatter 文件在 armclang 下可能触发警告或错误。如果 Flash 分区比较复杂建议对照 ARM 编译器文档确认 --scatter 的语法。5.3 CMSIS 5 到 CMSIS 6 的头文件变化MDK 6 默认会使用较新版本的 CMSIS而很多老工程的代码是 CMSIS 5 时代写的。CMSIS 6 对头文件路径和部分宏定义做了调整比如 core_cm4.h 的位置变化、部分旧宏被废弃。如果你的代码里直接 include 了旧路径的 CMSIS 头文件编译时会找不到头文件。处理方式很简单用 MDK 6 重新解析一次 DFP把工程的头文件路径改成新包的路径然后逐个解决编译报错。大多数问题都是 include 路径和宏差异真正涉及到 CMSIS API 变化的地方很少。下面是我整理的迁移高频报错速查表报错信息原因处理方式__CC_ARM undeclaredAC5 专有宏替换为__ARMCC_VERSION或__clang__cannot open source file core_cm4.hCMSIS 路径失效改用新 DFP 的 CMSIS 目录undefined symbol: SystemInit启动文件或系统文件未链接检查 startup 文件是否被编译进工程scatter file warning.sct 语法不兼容更新 scatter 文件写法selected processor does not support芯片型号配置不一致检查 csolution 里的 device 描述6. 常见问题与排查技巧实录除了迁移日常使用 MDK 6 也会遇到一些幺蛾子。这里整理几个我实际遇到的典型问题希望对大家有帮助。6.1 Pack 下载失败或卡住MDK 6 首次创建工程时会自动下载 DFP 包国内网络环境有时候会卡在下载环节。解决办法有两个一是用 cpackget 命令手动添加本地包从官网下载 DFP 的 pack 文件后执行 cpackget add xxx.pack二是配置 pack 镜像源指向本地文件目录。不要干等等十分钟下载不动基本就是网络问题。6.2 编译通过但调试器连接不上最常见的坑是 launch.json 里的 device 名称和 DFP 里定义的设备名不完全一致或者调试器接口没选对SWD/JTAG。我建议先到扩展面板里检查设备树确认芯片被正确识别再确认板载调试器驱动装好没有Windows 下 J-Link 需要装 DLLST-Link 需要装驱动。6.3 µVision 项目直接导入支持还是有限MDK 6 提供了从 uvprojx 导入到 csolution 工程的迁移路径但效果因工程复杂度而异。简单工程自动转换基本能用复杂工程大量宏定义、分散加载文件、多级 include 路径转换后往往需要手动调整。我自己的建议是别指望一键导入做好手动重建工程的心理准备反正 YAML 文件写起来也不复杂。6.4 许可证状态导致编译失败MDK 6 的许可证机制如果没激活编译时会弹出 license 相关的错误。解决方式是先在命令面板里打开 MDK 的 License 管理界面输入序列号或者指向 FlexNet 服务器。我用评估版阶段没管这事后来入职新公司激活正式版时才踩了一次坑记得先去官网注册账号。6.5 中文路径和长路径问题前面提过中文路径再补充一个长路径问题。Windows 下如果工程路径太深CMSIS-Toolbox 会报路径过长错误。这不是 MDK 6 独有的问题但 VS Code 的工程目录动不动就嵌套几层很容易触发。处理方法是把工程挪到盘符根目录下或者开启 Windows 的 long path 支持。7. 我的选型建议现在是升 MDK 6 的好时机吗这个问题没有标准答案但根据我这段时间的使用情况可以给出比较明确的建议。7.1 这几种情况建议直接上如果你做的是全新项目尤其是团队里面有人用 macOS 或者 Linux那 MDK 6 几乎是必然选择。跨平台协同开发的好处太大了团队成员不需要统一用 Windows 才能干活。如果你对 CI/CD 有需求希望固件编译自动化MDK 6 的 csolution/cbuild 工作流是极大的利好µVision 时代想做持续集成简直痛苦。如果你是 VS Code 的重度用户平时写代码都离不开 VS Code 的快捷键和插件那么 MDK 6 的上手成本几乎为零。工程管理、多光标、Git 冲突解决这些体验都会比 µVision 舒服很多。我个人现在更愿意在新项目里直接开 MDK 6哪怕只是写一个点灯程序至少界面和流程看着就舒服。7.2 这几种情况建议再等等如果你手里的存量工程非常多而且都在 µVision 里稳定运行团队又没有人愿意折腾工具链那就先别动。工具升级从来不是纯技术问题涉及团队习惯、培训成本、供应链验证稳妥比激进重要。如果你的老工程重度依赖 AC5代码里有大量内联汇编、私有编译宏、或者第三方库对 AC5 有强依赖贸然迁移到 MDK 6 会产生很大的兼容性工作。这时候可以继续用 MDK 5 维护存量或者单独开一个分支做技术验证不要一刀切。7.3 暂时留在 MDK 5 也完全没问题MDK 5 并没有因为 MDK 6 发布就突然不能用了ARM 官方对老版本也有维护周期。很多芯片厂商的 SDK 和示例工程仍然以 µVision 为主短期内不存在不升级就活不下去的情况。如果你的开发节奏不快完全可以等到周边生态调试器、SDK、中间件、芯片厂商支持都对齐了再切换。我自己的状态是新项目优先在 MDK 6 上落地老项目保持 µVision 不动两边并行。毕竟工具是为人服务的没必要为了追新而给自己找麻烦。但长期来看VS Code 化的 IDE 一定是嵌入式开发的方向越早适应越主动。最后再分享一个小技巧在 MDK 6 里写工程描述 YAML 文件时尽量把包的版本号写明确不要完全依赖通配符。一旦哪天本地 Pack 升级隐藏的不兼容问题就会冒出来。我个人在实际操作中体会最深的一点是任何工具链升级都要先在版本管理里打好标签转换永远比想象中费时留好退路总没错。