企业官网建设流程全解析

做STM32开发，有个工具你基本绕不开，那就是Keil MDK。哪怕是现在各种新IDE层出不穷，ST官方也推出了自己的CubeIDE，但你去翻任何一套开发板例程、任何一本教材、任何一个开源项目的源码，十有八九还是基于Keil的。所以我一直觉得，对刚入坑STM32的同学来说，先把Keil摸透，比纠结“用哪个工具才是政治正确”要实在得多。

这篇文章我打算把Keil MDK从安装、配置、工程创建，到下载、调试的完整流程讲透，不是那种“跟着点下一步”的截图教程，而是把我这几年实际使用中总结出来的关键点、踩过的坑、习惯性的配置方式一起写进去。文章里涉及的内容基本都是围绕STM32最常见的使用场景，包括F1系列、F4系列这些主流芯片，也覆盖了刚才热搜里大家常搜的那些词：芯片包安装、下载失败、调试图里看结构体变量、SWJ引脚复用、驱动缺失，等等。

1. 安装前后一步都不能少的准备流程

我见过太多人栽在第一步：软件装好了，芯片包没装；或者装了个Keil C51，拿着STM32工程打不开；又或者下载器驱动不对，连目标板都找不到。这节把安装相关的坑统一捋一遍。

1.1 MDK和C51不是同一个东西，选错版本等于零

首先要分清楚两个概念。Keil旗下有好几条产品线，最常见的是两套环境：一套是Keil C51，专门用来开发51单片机，芯片列表里只有Intel 8051、STC89C52这类8位机；另一套是Keil MDK（Microcontroller Development Kit），也叫MDK-ARM，这才是用来开发STM32、NXP、GD32这些ARM Cortex-M内核芯片的。

很多新手在网盘里随便下了个“Keil5”，装上之后发现工程列表里找不到STM32，甚至打开同事发来的工程提示“Device not found”，多半就是装了C51版本。还有人是先装了C51再装MDK，结果两个版本的IDE共存，桌面快捷方式只有其中一个，点开发现芯片列表不对，又不知道去哪里切换。我个人的建议是：如果你主力是STM32，那就只装MDK，不要为了贪多把C51和MDK都塞进同一个目录。两个版本的默认安装路径不一样，通常能共存，但没必要给自己增加判断成本。

下载的话直接去ARM官网的MDK页面，填一下基础信息就能下到最新版本安装包。国内网络环境下官网下载速度可以接受，缺点是版本更新频繁，如果你下载到的安装包太新，可能默认带的CMSIS版本比较超前，配合老工程会出一些奇怪的编译警告，这个后面再讲。下载的时候注意一下版本号，常见的有MDK 5.36、5.37、5.38、5.39这些，数字高低不是越大越好，稳定才是关键。

1.2 芯片支持包（DFP）——新手最容易漏的一步

Keil MDK和旧版Keil 4最大的不同，就是把芯片支持抽成了独立的“设备支持包”（Device Family Pack，简称DFP）。安装完MDK主程序之后，默认只带了少量ARM自家IP的器件支持，里面并没有STM32全系列的支持包。也就是说，如果你不额外安装STM32F1系列的DFP包，打开Keil新建工程时，Device列表里根本找不到STM32F103C8T6。

安装芯片包有两条路。一条是联网自动装：菜单栏的Pack Installer会列出所有可用的芯片厂商和型号，找到STMicroelectronics下面的STM32F1系列，点Install即可。缺点是Pack Installer在国内网络环境下经常加载很慢，动不动就转圈，而且安装包体积动辄几百MB，等得人烦躁。另一条是离线安装：去ST官网或者Keil的Pack下载页面，下载对应系列的.pack文件（比如Keil.STM32F1xx_DFP.2.4.1.pack），下载完成后直接双击文件，Keil会自动识别并安装。

从实际体验来说，离线包我强烈推荐。因为在线安装一旦中途断网，Pack Installer可能会出现半安装状态，之后再装就容易报“Pack already installed”或者反反复装卸不掉的问题。离线包双击安装的方式最干脆。安装完成后，新建工程时Device列表里会展开STMicroelectronics目录，里面有STM32F0、F1、F3、F4、F7、H7、L0、L1、L4等各个系列。这里啰嗦一句：你做什么芯片就装哪个系列的包，不用全装，全装除了占硬盘空间没别的意义。

1.3 关于许可证与“注册机”的实话

Keil MDK是商业软件，不激活的情况下只能编译不超过32KB的代码，芯片包功能也受限，所以很多人搜“keil注册机”。说实话，网上流传的那些破解工具我是不推荐的，原因很实在：一是这种工具来源不可控，多数杀毒软件会报毒，鬼知道里面除了补丁还塞了什么；二是License授权本来就是分层的，用破解去模拟授权很容易把电脑系统搞出各种莫名其妙的问题。

如果你只是学习、做课程设计或者开源项目，官方认可的方式是用社区版（Keil MDK Community/评估版），功能上对个人学习和非商业用途足够用。如果是公司项目，那就让公司买正版授权，花的是公司的钱，自己犯不着去冒这个风险。从我自己这十来年的经验看，开发工具稳定是第一位的，别为了省那点授权费折腾环境，最后项目勘误的精力成本反而高得多。

2. 从零创建一个可编译的STM32工程

装好环境之后，下一步就是建工程。Keil建工程本身不难，但很多细节会影响后续开发的体验。我按自己的习惯一步一步拆开讲。

2.1 新建工程时千万别选错型号

打开Keil MDK后，菜单栏Project -> New uVision Project，选一个工程保存路径，然后会弹出来Device选择窗口。这里要注意，窗口有一个搜索框，可以直接输入芯片型号，比如STM32F103C8，然后从搜索结果里选STMicroelectronics -> STM32F1 Series -> STM32F103 -> STM32F103C8，确认后缀是Tx，别选成STM32F103C8的“C8”和“CB”封装引脚还能对得上，型号选错轻则编译报芯核错误，重则烧录后外设行为异常，排查起来非常折磨。

选完型号之后弹窗问你要不要添加CMSIS相关的启动文件到工程，这个弹窗在不同版本里提示不一样。我个人的推荐是：新手阶段可以选“Yes”，让系统把CMSIS核心和Device Startup文件自动带上；老手一般直接选“No”，然后自己管理整个工程目录结构，这样生成的工程更干净，也不容易被自动添加的目录结构带偏。

还要强调一点：创建工程时选的芯片型号，决定了编译器链接时使用的是哪个启动文件（startup_stm32f103xb.s）、哪个链接脚本（.sct文件），以及编译宏里默认定义了哪些东西。所以选错型号不只是显示问题，而是真的会影响代码编译出来的行为。比如同样是F103系列，C8T6（64KB Flash）和ZET6（512KB Flash）的启动文件不是同一个，混用会导致中断向量表错乱，程序跑起来完全不是那么回事。

2.2 工程目录结构和文件组织

Keil默认的工程组织形式比较“裸”，所有源文件堆在一起也能编译，但随着项目变大会非常痛苦。我的习惯是目录结构从一开始就分成几层：

• Project/：存放.uvprojx工程文件和配置文件
• Core/：存放CMSIS核心文件、启动文件（startup_xxx.s）和系统初始化文件（system_stm32f1xx.c）
• HAL/或Libraries/：存放HAL库或者标准外设库的源码，按inc、src分开
• User/：存放main.c、中断处理文件以及你自写的应用代码
• Doc/：放数据手册、设计笔记、协议说明，不进编译
• MDK-ARM/：工程生成时的中间文件，不要手工去动

这样的好处是，当你在Git里管理项目时，可以设置忽略掉那些中间生成的对象文件和调试临时文件，只保留源码和工程配置文件，仓库大小会从几十MB缩到几MB，协同开发体验完全不同。Keil的.uvprojx用的是XML格式，Git管理比较友好，冲突大多还能手动合并。

在添加文件到工程时，可以在分组（Group）上右键选择Add Existing Files，把对应的.c文件添加进去。这里有个细节：在Keil的工程窗口里添加.h头文件只是为了让文件列表好看，并不是编译必需，真正的头文件路径要在“魔术棒”的C/C++选项卡里配置Include Paths。很多人加了.h但忘了加Include Paths，然后编译报“file not found”，还以为是文件没加进去，其实根本不是一回事。

2.3 魔术棒里的关键配置逐项说

双击工程名旁边的“Options for Target”图标，这就是传说中的魔术棒。配置项很多，但我实际开发中每次都要动的手指头数得过来。

Target选项卡：根据你的板载晶振设置Xtal（MHz），比如常用的8MHz晶振就填8。这里影响的是编译器内部对时间和延时函数的估算参考，不是烧录时的实际主频。代码里SysTick、定时器这些时钟树配置，运行起来之后是看寄存器配置的，工程设置里的Xtal不会自动帮你把主频搞对。

Output选项卡：勾选Create HEX File，这样编译完会在输出目录生成.hex文件，方便你用串口下载工具烧录，或者直接交给工厂烧录，也可以配合Bootloader使用。再做一步：勾选Browse Information，这样调试时才能用鼠标查看变量定义，并支持函数跳转。

C/C++选项卡：这是所有新手最容易迷糊的地方。这里要配置三个东西：Define宏定义、Include Paths头文件路径、优化等级。以HAL库工程为例，宏定义这一栏通常要写USE_HAL_DRIVER, STM32F103xE这种，前者告诉编译器启用HAL库的外设头文件，后者指定具体芯片系列，对应的是stm32f1xx_hal_conf.h里的芯片型号条件编译；如果用标准外设库，宏定义写STM32F10X_MD、USE_STDPERIPH_DRIVER之类。头文件路径一栏点右边的省略号，把你在工程里用到的所有包含.h的目录全部加进去，注意“.”代表当前路径，你写“.\User\Inc”这种相对路径也行，但用绝对路径在项目迁移到别的电脑时容易爆红。

Debug选项卡：这里选择调试器。用ST-Link就选ST-Link Debugger，用J-Link就选J-Link/J-Trace Cortex，用DAP-Link就选CMSIS-DAP Debugger。选完之后点旁边的Settings，确认一下电脑能识别到调试器，并且Target框里能读到芯片ID，比如STM32F1常见读取到0x1BA01477。读不到ID的话就要往回排查驱动和接线了，这个我后面专门讲。

Utilities选项卡：这一块负责烧录行为。勾选Use Debug Driver，并在Settings里设置Flash Download。这里最关键的是Flash Download页面下的Programming Algorithm列表，列表里必须有对应芯片的烧录算法，STM32F103系列通常是STM32F10x Med-density Flash（64KB）或STM32F10x High-density Flash（128KK以上容量），如果你发现列表是空的，要点击Add按钮手动添加。这个列表选错了，下载时会报“No Algorithm found”或者“Erase Failed”，很多人卡在这里。

3. 下载烧录：搞定连接，解决最常见的失败

工程能编译出固件，只是万里长征走了一半，接下来要把固件烧到芯片里跑起来。这一节讲下载连接怎么做、常见失败怎么排查。

3.1 三种常见调试器怎么选、怎么接线

STM32下载和调试最常用的调试器有三个：ST-Link、J-Link、CMSIS-DAP。ST-Link是ST官方出的，性价比高，最常见，V2版本的ST-Link才二十来块钱，网上卖的开发板很多直接板载，插上USB就能用。J-Link是SEGGER家的，功能强大，调试速度、附加特性都更好，但正版价格贵，淘宝上几十块的基本是高仿，驱动方面J-Link官方驱动对高仿版本做了封禁，会提示“The connected probe appears to be a counterfeit”，虽然也能凑合用，但体验会打折扣。CMSIS-DAP是ARM开源的调试方案，很多国产开发板（比如合宙、树莓派Pico调试）都用它，开源协议友好，性能也不错。

接线方式最省事的就是SWD四线制：SWDIO接PA13，SWCLK接PA14，GND接GND，3.3V接VCC，注意方向别接反。SWD比JTAG少两根线，且占用引脚少，绝大多数时候用SWD就够了。还有一个容易被忽略的问题：复位引脚对下载的影响。目标板的NRST引脚如果被外部电路拉死，SWD协议仍然有可能连不上芯片，遇到诡异下载失败时，可以顺手把调试器的RST引脚接到板子的NRST上试试，有时候就是这一根线的事情。

3.2 下载器配置与烧录流程

在Debug选项卡里选定调试器后，点Settings进入详细配置界面。Debug页里Transport一般会自动识别，ST-Link可以选择SWD或者JTAG模式，通常选SWD；Max Clock部分，新手用默认的4MHz或者1MHz都行，如果连线太长或者飞线干扰大，把时钟降到几百kHz反而更容易连上。这一点我踩过坑：用杜邦线飞了几个板子，在8MHz的调试时钟下死活连不上，后来降到1MHz就好了。

配置完成后点编译，然后点Load按钮或者快捷键F8。Keil会先全量编译，如果没有错误，再调用调试器执行擦除、编程、校验等流程。烧录过程中，最下面信息栏会提示“Programming Done”和“Verify OK”。如果只是改了代码想重新烧录，其实可以不点编译，直接点Load，Keil会自动判断是否需要重编译。日常开发流程就是：改代码 -> F7编译 -> F8下载，这两个按键是使用频率最高的。

3.3 芯片锁死和“No Target”的处理

下载失败是新手遇到最多的噩梦，我这里整理一下最常见的几种报错和对应的处理思路。

“No Target Connected”或者“Cannot access target”：最常见的三个原因，一是SWD接线接反或者没接稳，二是目标板没有独立供电，三是调试器驱动没有装好。排查顺序是：先打开电脑的设备管理器，确认调试器枚举出来的设备存在且没有黄色感叹号，然后用万用表量一下目标板的VCC和GND之间是不是真的有3.3V。很多板子在只用调试器供电的情况下，电流不够带不起来，就会出现连接上又立即断开的情况。

“Flash Download failed - Cortex-M3”：这个报错后面通常会跟一个Flash算法相关的提示。先把Utilities里的Flash Download打开，看看Programming Algorithm列表，如果空着或者型号不符，手动添加正确的Flash算法。如果Flash算法是对的，但擦除还是失败，多半是芯片的读保护（RDP）被打开过，也就是俗称的“芯片被锁”。这个时候ST-Link可以用ST官方工具STM32CubeProgrammer来解锁：连接后选择Connect Under Reset，然后执行全芯片擦除。J-Link的话，在J-Flash里也有Unsecure Chip的选项。

芯片锁定这个话题多说一句：很多学生板卡会出现“板子焊好了，第一次能烧，第二次就烧不进去”，深入排查会发现是代码里不小心使能了Flash写保护，或者开启了RDP。遇到这种情况别慌，先用CubeProgrammer的Connect Under Reset模式连一下，实在连不上就把BOOT0拉高，复位后再连，成功率会高很多。

4. 调试实战：从断点看到结构体变量的完整方法

能烧录只是第一步，真正的调折磨难才刚刚开始。Keil的调试器其实挺强大的，只是很多人只用了个皮毛。

4.1 调试界面到底有多“能打”

点击Start Debug Session按钮（或者快捷键Ctrl+F5），进入调试界面后，左侧是寄存器窗口（Registers），下方是Watch窗口和Memory窗口，还有Call Stack、Disassembly等。Keil调试的强大点是它和编译器的AST信息是打通的，也就是说你可以在工程里直接看到变量名、结构体成员，甚至局部变量的值，而不需要像调试生产环境里那种只能看寄存器地址的反汇编调试。

调试的核心操作是打断点：在你认为可能出现问题的代码行按F9，Run到断点处，程序就会停下来。单步执行时，F10是越过本行但不进入函数内部，F11是步入函数内部。这个区别我提一句：在调试一个“值突然不对”的变量时，用F10步过会丢失函数内部的细节，应该用F11跟进，看它是在哪个操作被改写的。对于没有硬件调试器的人而言，很多人习惯用串口打印，但Keil调试器的Watch窗口能做到实时查看变量，不用插线不用加printf，这也是它效率高的原因。

4.2 在Keil调试模式下查看结构体变量

很多人搜“keil调试助手里面debug模式如何显示结构体变量”，其实就是Watch窗口的用法。进入调试模式后，在Watch窗口的输入框里直接输入结构体变量的名字，比如我的代码里有一个结构体变量叫motor_status，那我在Watch窗口输入motor_status，回车，它就会自动展开，显示它所有的成员，包括每个成员的名字、类型、当前值。如果是数组，也直接输入数组名，然后在显示的数组名旁边有个扩展箭头，点开就能看到每个元素的值。

这里有一个容易踩的坑：如果代码里设置了优化等级，比如-O2或者-O3，编译器可能会把某些变量优化掉，导致Watch窗口显示“not in scope”或者找不到符号。遇到这种情况，最简单的办法是把优化等级临时降到-O0或者-O1，调试完再改回去。还有一个办法是把变量声明为volatile，告诉编译器不要优化它，但这个加多了会影响性能，只建议在调试阶段临时加。

另外一个实用技能是Quick Watch窗口：鼠标右键点一个变量，在右键菜单里选Add to Watch，或者直接用快捷键，这样不用打开完整的Watch窗口，也能快速看到当前值。对于结构体嵌套结构体的场景，Watch窗口的树形展开结构非常直观，每层成员都可以展开细化，不用自己去推算偏移地址。

4.3 别忽略的寄存器窗口和逻辑分析仪

Watch窗口看的是变量的逻辑值，寄存器窗口看的才是CPU和外设的真实状态。发生Hard Fault或者程序卡死时，第一件事不是看printf，而是打开Peripherals菜单，找到对应的外设（比如GPIOA、USART1、TIM2），逐个核对寄存器值。Keil库函数封装再漂亮，底层寄存器永远是真相。

Keil还内置了一个逻辑分析仪（Logic Analyzer），位置在View菜单下，它能以波形方式展示变量数值的变化，特别适合分析PWM输出、ADC采样值、电机转速等随时间变化的信号，而且不需要额外接线。使用方法是在Logic Analyzer窗口里点Setup，把你想看的变量加进去，然后在显示配置里选择bit或者analog类型，运行程序时波形就会实时绘制出来。由于逻辑分析仪的工作是基于跟踪数据，它要求调试器是在线的，但这已经比拿示波器怼引脚方便太多了。

4.4 关于SWJ复用引脚的调试陷阱

这个经典问题就是热搜里的“stm32禁用jtag”。STM32默认把PA13/PA14/PA15/PB3/PB4这组引脚分配给SWJ调试接口，其中PA13和PA14是SWD的SWDIO和SWCLK，PA15是JTDI，PB3是JTDO，PB4是NJTRST。正常使用中，SWD只需要PA13和PA14，所以很多人想把PA15、PB3、PB4当作普通GPIO来用，甚至有人把PA13、PA14也想省出来，结果一配置就出问题。

这里必须明确：PA13和PA14用作SWDIO/SWCLK时，几乎不能完整地释放为普通GPIO，因为一旦释放，ST-Link就再也连不上芯片了。如果你只是想把PA15、PB3、PB4当普通IO用，可以在初始化代码里加上GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE); 这条配置会把JTAG功能关掉，但保留SWD。操作方式是把GPIO_Remap_SWJ_JTAGDisable这个参数传到GPIO_PinRemapConfig函数里，启用重映射；前提是把GPIO的AFIO时钟打开，也就是__HAL_RCC_AFIO_CLK_ENABLE()（HAL库）或者RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE)（标准库）。如果不加这条配置，直接去操作PA15和PB3这类引脚，你会发现引脚电平死活不生效，那就是因为默认的JTAG功能把引脚占住了。

这个“禁用JTAG”的操作要格外小心：一旦在代码里执行了禁用JTAG的语句，而你下载器用的偏偏是JTAG模式（不是SWD），下一次下载就会直接失败。解决办法是用SWD模式连接，然后通过芯片擦除方式把代码清掉。所以我调试带这类代码的板子时，下载器永远选择SWD模式，这已经成了肌肉记忆。

5. 常见问题速查与个人习惯中的避坑技巧

最后这节我打算把高频问题打包处理，再分享一些平时很少有人细说、但实战中极其有用的小习惯。

5.1 编译报错：先看头和尾，再看行号

Keil编译报错信息一多，新手容易慌，信息栏刷屏刷得人头皮发麻。我的处理经验是：滚动到第一条错误，看它的文件名和行号，大部分时候真正的错误就在第一条，后面的错误往往是第一条错误的连坐反应。典型的比如头文件路径不对，导致几百个函数声明都找不到，报错刷了满屏，但你修好Include Paths之后，后面的错误一夜之间全消失。

再有就是中文注释导致的编码问题。Keil默认代码页和Windows本地编码之间切换时，中文注释偶尔会乱码，甚至是半个中文字符被编译器当成非法字符，报出一个指不到位置的语法错误。我现在的习惯是全程英文注释，或者用“拼音/英文+关键字”的方式，省心。如果非要中文注释，就统一用UTF-8，但同时要到Edit -> Configuration -> Editor里勾选对应的Encoding选项，不然Keil编辑器和编译器之间会出现奇怪的“笑脸字符”乱码。

5.2 驱动缺失与串口识别

很多同学用CH340或者CP2102这颗USB转串口芯片的板子，在烧录前就把下载器连上了，结果板子连电脑后设备管理器里永远是一个“Unknown Device”或者是带感叹号的“USB Serial”。这不是Keil的问题，是驱动没装。CH340去官网下载对应版本的驱动，CP210x同理。装好之后，设备管理器里多出一个COM口，这时候串口调试助手才能正常打开它。没有串口驱动，你后面哪怕用printf重定向输出的调试信息也全都白搭。

如果驱动装了依然识别不到COM口，排查方向是USB线。很多便宜的USB线只能充电不能传数据，或者接触不良，这类问题我已经不知道碰到多少次了，先换线再折腾软件，这个顺序能省下大把时间。

5.3 让代码排版更专业：Astyle一键格式化

可能有同学搜过“astyle (keil代码自动对齐工具)”。Astyle是一个代码格式化工具，支持C/C++/Java等语言，能根据你指定的风格自动调整缩进、大括号换行、空格等。我用的是AStyle结合Keil外部工具的方式：在Keil的Tools菜单里配置一个自定义命令，指向Astyle的exe，选中代码后一键格式化。

在Keil里配置外部工具的路径是Tools -> Customize Tools Menu，添加一个新条目，Command指向你的astyle.exe路径，Arguments填格式参数和当前文件名，比如“--style=allman --indent=spaces=4 %E”，其中%E是Keil内置的当前文件名占位符。这样配置好之后，写完代码按一下快捷键，整个文件的缩进风格就统一了，提交到Git再也不会出现那种一改代码就整个文件缩进全部变掉的闹心情况。这个工具用好之后，代码可读性提升一个档次，多看你一眼代码的同事心里都会感谢你。

5.4 干净卸载Keil的正确姿势

做嵌入式有个折磨事：公司环境里Keil被人改坏了或者装失败了，想彻底重装。直接拖进回收站是卸不干净的，Keil的注册信息、芯片包目录、许可证信息散落在系统各处。如果只是重装主程序，老的芯片包还在倒也无所谓，但如果之前装坏了，残留的Pack信息会让新装上的Pack一直处于“半安装”状态。

我的建议是先用Windows的“应用和功能”卸载Keil主程序，然后把安装目录里的残留文件删掉，再把“C:\Users\你的用户名\AppData\Roaming\ARM”和“AppData\Local\ARM”相关目录也清理掉，最后打开注册表编辑器，删除HKEY_CURRENT_USER下ARM相关的软件键值（如果不熟注册表，别乱删别的，只删和ARM、Keil相关的）。这样基本能回到干净状态。这套方法同样适用于版本回退时出现的各种“Pack状态损坏”。

5.5 换个思路：Keil之外的工程协作

Keil的.uvprojx本质是XML文件，但不同版本之间互相兼容的时候偶尔也会出现工程打不开的提示。我自己见过最多的场景是：同事用了高版本MDK建的工程，我电脑上装的版本低，打开直接报“Project file is created by a more recent version”。解决办法要么是升级MDK版本，要么让同事把工程导出一个低版本格式。ARM在新版本里提供了一个Backup Project功能能另存为旧版本格式，大家如果在团队里协作，建议先约定一个固定的MDK版本号，避免这种无谓的折腾。

另外，如果你的项目涉及更多人的开源协作，可以考虑把源码托管到Git仓库，并加上.gitignore规则忽略那些中间文件和临时文件（比如Listings、Objects目录里的所有内容，还有*.uvguix文件）。Keil的.uvguix是用户界面布局文件，每个人机器上都不同，不需要提交。工程文件只提交.uvprojx、.uvoptx和源码，这样后面任何人拉下来都clean build成功，环境冲突概率会小很多。

一点点个人心得

做嵌入式这些年，我用过IAR、尝试过CLion配合CMake、也被CubeIDE拖住过一个项目，但最后手里接到的别人代码，十有八九还是Keil MDK的工程。这不是习惯的问题，而是生态决定的：芯片厂商的SDK、开发板的例程、论坛里的答疑，默认几乎都是Keil工程格式。真正把Keil用稳了，后面参加比赛、接手工作项目，省下的时间足够再去啃几座更硬的技术大山。

如果这篇文章对你有帮助，不妨从今天开始，花五分钟重新检查一下自己的Keil环境：芯片包全不全、调试器配置对不对、工程目录是不是一个Git仓库该有的样子。磨刀不误砍柴工，这个道理在嵌入式开发里，永远成立。