如何快速、简单地迁移Keil MDK工程项目到其他开发工具
2023-09-20
作者:火星
来源:与非网
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/
以上内容基于自己的经验和知识总结,希望对各位考虑项目迁移的朋友们有帮助,如果有错误,欢迎指正!
更多精彩内容欢迎点击==>>电子技术应用-AET<<