嵌入式开发的一大特点就是开发中要使用交叉编译器，所谓交叉编译器就是虽然编译器运行在个人电脑上（可能是linux或者windows系统），但是编译出来的代码却运行在目标嵌入式系统，这个系统可能是传统的8051内核MCU及其在此基础魔改的各种MCU，也可能是现在的版本之子ARM旗下 Cortex-M 系列各种单片机。
大部分处理器供应商其实没有提供专用的交叉编译器，一般情况下我们开发者都是要使用一些通用的交叉编译器。其实这是一个好事，如果说每一家芯片厂商都推出自己的编译器，我都不敢想我的电脑将会混乱成什么样。
keil
个人主要是开发工作在各种产品上的MCU的，嵌入式linux我只是略懂，所以我这里只说一说我经常使用的开发MCU的环境。首先没有什么疑问的就是keil了（包括C51和MDK），可以说即使你自己不使用这个IDE，有时候需要看一下别人的工程，这个IDE也是不得不安装的。
一般来说都是推荐使用某一个老版本，具体说法是稳定新出的可能有各种问题，我和别人不一样，虽然不会一直关注官网更新进行软件更新，但基本上每次换新电脑或者因为其他原因重新安装软件的时候我都会去官网下载最新的。
在我看来，‘老版本更稳定’的说法有些站不住脚。所有版本在发布时都是官方的‘稳定版’。老版本的优势在于经过了更长时间的市场检验，遇到问题时，更容易找到已有的解决方案。我个人对此持开放态度，自信能解决版本带来的问题。事实上，在嵌入式开发中，这远非最大的挑战。
不过如果你是新手我就建议你自己去网上搜一搜最容易搜到的，说不定就是现在使用人数最多的，遇到问题有解决方案的可能性也更大，或者有人带你入坑那别人让你用什么就用什么好了。
可惜keil最大问题就是界面看着太不舒服了，毕竟是有些年代的软件了，遇到现在的显示器尤其是高分辨率小屏幕，画面图标永远是糊糊的感觉。即使进行一些高分辨率兼容性设置，字体清晰了也改变不了图标的模糊，甚至导致一些画面出现错误，要不然就是图标全部变得非常小。
VS Code + 各种工具链
为了眼睛和心情的愉悦，一般是使用其他编辑器写代码，再调用外部工具链进行编译。这套玩法花样繁多，但其中最突出的 IDE，毫无疑问是 VS Code。我毫不掩饰自己是 VS Code 的信徒。使用VS Code最初是源于开发 Python 的习惯，但它的高度可定制性（通过插件搭建任何开发环境）让我彻底被征服。而VS Code中开发MCU最得力的插件当属 EIDE，它极大地降低了在 VS Code 中开发嵌入式项目的门槛，甚至可以说是当前最省事的方案之一。
EIDE 的强大之处在于，它为你打理好了一切。如果你主要开发 Cortex-M 内核的单片机，那么利用 EIDE 及其依赖插件，你完全可以在 VS Code 中实现代码编写、编译、调试、下载的一站式开发，彻底告别 Keil。
它可以轻松导入和导出 Keil 工程，让你能平滑地从传统环境过渡过来。提供了一键安装工具链和环境的功能，将以往复杂的配置过程变得傻瓜化，上手成本极低。插件可以调用多种主流工具链，包括 Keil 自家的 ARMCC (AC5，已停止更新)、ARMCLANG (AC6，当前主力)，以及开源的 Arm GNU Toolchain。
我本来不太想谈 51 单片机，毕竟毕业后就很少接触了。但工作中总会遇到——或是老项目传承，或是成本极致考量——让你不得不再次面对它。用 EIDE 开发 51 内核单片机，情况就有些不同了：代码编写和编译基本可行，但烧录程序可能需要自己编写脚本，不够方便。在线仿真调试基本是“不可能完成的任务”。有些芯片即便有 JTAG，其调试功能也通常被锁定在 Keil 中，想强行在 VS Code 中实现，绝对是件得不偿失的事。
因此，我的策略是一种混合工作流：在 VS Code 中享受舒适的编码体验和智能提示完成代码编写与初步编译，确认基本无误后，再回到 Keil 中进行下载和调试（如果芯片支持的话）。对于很多 51 项目，直接下载看硬件反馈的“硬调试”也足以满足需求。
提到 51 开发，还有一个开源选择不得不提：SDCC。它是一个完全支持 C99 标准的交叉编译器，拥有各种现代 C 语言特性，并且跨平台支持做得更好，能很好地结合 Makefile、CMake 等现代构建工具。但很可惜，据我观察它的用户群体并不大，而且一个常被提及的缺点是：其编译出的代码体积通常比 Keil C51 要大一些。
构建工具
我把Makefile和CMAKE单独放在最后一部分不和VS Code放在一块说，是因为使用这两个构建工具可以脱离特定IDE的束缚，不像EIDE一样和VS Code结合的特别紧密。但实际上使用构建工具，编辑器负责编辑，构建工具负责构建，其实是更贴合VS Code这个IDE的设计理念的，VS Code里面也有专门为这两个构建工具服务的插件。
其中CMAKE相比Makefile属于更高一级的构建工具，可以生成常见平台的构建文件，比如windows平台上Makefile文件或者ninja文件。一般来说大的工程都会使用这些构建工具，以实现跨平台与可移植性，也可以更好地集成现代的工具链进行项目管理。对于我们个人来说，有些嵌入式软件开发岗位是有要求使用这些构建工具的，掌握这些工具也有利于求职。
另一方面阅读编写Makefile或者CMAKE文件本身也是理解计算机系统如何构建一个工程的途径，至少我在学习Makefile的过程中，对于工具链各部分干了什么，为什么这么干能在最后生成一个可以运行的程序是有了很深的理解的。
总的来说，从不可或缺的Keil，到高度可定制的VS Code及其生态（如EIDE），再到结合底层的构建工具，嵌入式MCU的开发环境正变得越来越多样化和现代化。选择哪种方案，取决于你的项目需求、个人偏好和职业规划。
在接下来的文章中，我将带你一步步上手这些环境，敬请期待！
评论已关闭