标签: 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/ 以上内容基于自己的经验和知识总结，希望对各位考虑项目迁移的朋友们有帮助，如果有错误，欢迎指正！ 作者：火星