如何快速、简单地迁移Keil MDK工程项目到其他开发工具

作者：火星

Keil MDK作为嵌入式行业常用的开发工具，嵌入式工程师们都很熟悉。但是最近听说Arm公司要把Keil MDK合并到Arm Development Studio里，所以Keil MDK的版本更新已经基本停止了，大家都还在使用很老版本的Keil MDK，功能上并不是很方便，希望找到更好的替代工具。此外，从近期举办的包括RISC-V中国峰会在内的多个行业活动来看，RISC-V在中国的发展如火如荼并且势头很猛，因此还要考虑开发工具是否会长期支持RISC-V并可以通过移植重用相关设计。

但是替代Keil MDK需要考虑项目工程如何迁移到其他工具，由于工程文件格式不同、以及底层编译技术的差异， Keil MDK的工程文件与其他工具平台并不完全兼容，需要一定量的迁移工作。本文就根据笔者的经验，分享一下如何快速把Keil MDK的代码迁移到其他平台，并且解决不同平台之间项目文件不兼容的问题。

目前迁移Keil MDK代码常见的目标平台有两个，分别是GCC和IAR。下面就给大家分别介绍并比较一下两者的区别：

概览：
•        GCC也很常见但是它只是一种编译器，需要配合IDE使用，常见的选择有VSCODE，或者Eclipse这些IDE，由于都是免费的组件，需要自己动手搭建，要有一定的IDE搭建知识才能使用起来，当然最大的好处是免费。有些朋友因为一些众所周知的特殊原因，不得不放弃使用Keil MDK，如果又苦于没有预算购买其他工具的话，就基本上只有GCC可选了；

•        如果有预算买商用工具，另一个选择是IAR，IAR是Keil同级别的商用工具，性能与用户体验都不错，且自带IDE，不需要配置，直接安装即用。同时，除了支持基于Arm的项目，IAR的Embedded Workbench工具还有支持RISC-V的版本，这对项目和应用比较多或者希望进一步扩展RISC-V架构项目的工程师具有很重要的意义。这是因为从IAR Embedded Workbench  for Arm移植到IAR  Embedded Workbench for RISC-V的过程非方便，因为很多文件夹内容已经统一了。

项目迁移流程对比：

首先要声明，迁移项目分为两大部分工作，第一是项目文件格式的适配，第二是项目代码的适配。

1.        项目文件的适配是一定要做的，而且方法和途经比较确定。

2.        正常情况下，如果项目里使用的都是标准C/C++，那么应该编译是没问题的。但是项目代码的适配可能涉及到一些不是标准C/C++的迁移，例如某些特殊要求下，标准的C/C++代码难以实现某些功能，而使用编译器的内联函数（Intrinsic）可以更高效的实现这些功能。如果涉及非标准C/C++，那么就需要用户针对性的对这些非标准C/C++进行跨编译平台的迁移。

关于非标指令的迁移，这里不做介绍，因为涉及的指令太多，不可能在一篇里介绍完，大家碰到了可以单独处理。

下面为大家介绍下通用的项目工程迁移指导：

从Keil迁移到GCC

一般需要修改以下内容：
1.        工程目录配置：从.uvproj文件里查看Keil MDK的文件目录，把相同的文件配置到GCC的Makefile文件目录里；
2.        连接（Linker）文件：Keil MDK的连接器文件是.sct, 根据对应的描述，可以手写一个GCC对应支持格式的连接文件；
3.        启动代码：一般服务好的芯片厂商会制作不同编译器平台的启动代码，在例程文档里可以找找看，如果有看到支持GCC的格式，就可以直接拿来用。如果没有的话，就需要手写了。不同的芯片都要单独写启动文件，纯自己手写的难度比较大，需要对芯片非常了解，一般需要芯片厂商的人支持才行，这里不多做赘述。
4.        制作Makefile工程文件，包括
a.        源文件的工程目录配置，
b.        GCC格式的连接文件替换，
c.        把Keil MDK的编译参数和连接参数复制到Makefile的对应参数中；
d.        添加设备信息和调试配置（GDB）

迁移之后还要进行验证，包含编译结果的验证，编译后可执行文件代码尺寸、运行速度的验证和调整。如果代码尺寸或者运行速度不达标，还需要调整编译器优化选项。调整优化选项后，记得也要重新测试代码执行结果是否符合预期，因为不同的优化选项可能造成代码运行结果的变化。

从Keil迁移到IAR

如果是迁移到IAR，推荐使用IAR官方的项目转换工具IAR Project Converter，迁移过程就会非常方便。在IAR的Embedded Workbench for Arm工具的菜单栏里，点击Tools  IAR Project Converter, 就可以自动把Keil的工程文件和代码转换成IAR格式，最后再把.s启动文件换成IAR格式的就可以，一般在芯片公司提供的代码示例里都有不同格式的.s文件，直接找到IAR版本的替换原有的就可以。当然迁移之后还是要校验一下编译是否正常，测试下代码是否运行正常。如果用IAR，基本不用担心代码体积变大，或者运行速度拖慢，IAR拥有非常好的编译优化，一般情况下编译结果会更优，只需要找到合适的编译选项就OK了。

总结：

Keil项目迁移到其他平台技术上可行，尤其是代码中不涉及非标的C/C++代码时，具备项目迁移经验的情况下是完全可实施的，需要担心的只是工作量的问题。

至于选择迁移到IAR还是GCC，主要考虑以下几点：
•        是否有充足的预算。相信大家最常见的迁移原因就是众所周知的合规问题，如果必须迁移，又没有预算，只有硬着头皮转GCC了。如果能有预算，可以考虑购买IAR正版，选IAR的话迁移也都是比较方便的，并没什么风险，付钱的工具还是比免费的要靠谱得多，而且还能得到相应的支持。当然，如果同一家厂商能够同时支持Arm和RISC-V的工程开发，则可能有更高的投资回报（ROI）。

•        对不同工具的熟悉程度。跨平台迁移需要对工具有一定的熟悉度，尤其是迁移到GCC，由于GCC版本众多，又没有成熟的IDE，又没有技术支持的情况下，如果工程师对开发工具并不精通，还是很难顺利迁移成功。如果没有相关经验，还是建议选择IAR，毕竟IAR官方自带的自动化转换工具还是很方便的，如果有正版IAR License，还可以有IAR官方人员回复你迁移过程中碰到的问题，IAR官方的技术支持申请链接是https://www.iar.com/cn/knowledge/support/request-technical-support/。

•        迁移风险是否能够接受。即使是项目的代码本身迁移成功，也不代表项目整体的迁移成功了，有可能迁移到GCC之后由于编译性能的降低，生成的可执行代码在现有的硬件平台上性能不满足！最常见的就是代码体积变大，FLASH不够用了，或者RAM不够了，前期努力白费T_T 。为了避免这种风险，稳妥的路径还是采用商用级别的编译器，IAR还是比较稳的。IAR支持14天免费试用，可以直接去申请个试用版试试能否迁移成功，试用链接https://www.iar.com/cn/product/architectures/arm/iar-embedded-workbench-for-arm/iar-embedded-workbench-for-arm---free-trial-version/

以上内容基于自己的经验和知识总结，希望对各位考虑项目迁移的朋友们有帮助，如果有错误，欢迎指正！