Keil MDK作為嵌入式行業(yè)常用的開發(fā)工具,，嵌入式工程師們都很熟悉。但是最近聽說Arm公司要把Keil MDK合并到Arm Development Studio里,，所以Keil MDK的版本更新已經基本停止了，大家都還在使用很老版本的Keil MDK,，功能上并不是很方便,，希望找到更好的替代工具。此外,，從近期舉辦的包括RISC-V中國峰會在內的多個行業(yè)活動來看，RISC-V在中國的發(fā)展如火如荼并且勢頭很猛,，因此還要考慮開發(fā)工具是否會長期支持RISC-V并可以通過移植重用相關設計,。
但是替代Keil MDK需要考慮項目工程如何遷移到其他工具，由于工程文件格式不同,、以及底層編譯技術的差異,， Keil MDK的工程文件與其他工具平臺并不完全兼容，需要一定量的遷移工作,。本文就根據筆者的經驗,，分享一下如何快速把Keil MDK的代碼遷移到其他平臺，并且解決不同平臺之間項目文件不兼容的問題,。
目前遷移Keil MDK代碼常見的目標平臺有兩個,，分別是GCC和IAR。下面就給大家分別介紹并比較一下兩者的區(qū)別：
概覽：
·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的過程非方便,，因為很多文件夾內容已經統(tǒng)一了。
項目遷移流程對比：
首先要聲明,，遷移項目分為兩大部分工作,，第一是項目文件格式的適配，第二是項目代碼的適配,。
1.項目文件的適配是一定要做的,，而且方法和途經比較確定。
2.正常情況下,，如果項目里使用的都是標準C/C++,，那么應該編譯是沒問題的。但是項目代碼的適配可能涉及到一些不是標準C/C++的遷移,，例如某些特殊要求下,，標準的C/C++代碼難以實現(xiàn)某些功能，而使用編譯器的內聯(lián)函數(shù)（Intrinsic）可以更高效的實現(xiàn)這些功能,。如果涉及非標準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的編譯參數(shù)和連接參數(shù)復制到Makefile的對應參數(shù)中,；
d.添加設備信息和調試配置（GDB）
遷移之后還要進行驗證,，包含編譯結果的驗證，編譯后可執(zhí)行文件代碼尺寸,、運行速度的驗證和調整,。如果代碼尺寸或者運行速度不達標，還需要調整編譯器優(yōu)化選項,。調整優(yōu)化選項后，記得也要重新測試代碼執(zhí)行結果是否符合預期,，因為不同的優(yōu)化選項可能造成代碼運行結果的變化,。
從Keil遷移到IAR
如果是遷移到IAR，推薦使用IAR官方的項目轉換工具IAR Project Converter,，遷移過程就會非常方便,。在IAR的Embedded Workbench for Arm工具的菜單欄里，點擊Tools à IAR Project Converter, 就可以自動把Keil的工程文件和代碼轉換成IAR格式,，最后再把,。s啟動文件換成IAR格式的就可以，一般在芯片公司提供的代碼示例里都有不同格式的,。s文件,，直接找到IAR版本的替換原有的就可以,。當然遷移之后還是要校驗一下編譯是否正常，測試下代碼是否運行正常,。如果用IAR,，基本不用擔心代碼體積變大，或者運行速度拖慢,，IAR擁有非常好的編譯優(yōu)化,，一般情況下編譯結果會更優(yōu)，只需要找到合適的編譯選項就OK了,。
總結：
Keil項目遷移到其他平臺技術上可行,，尤其是代碼中不涉及非標的C/C++代碼時，具備項目遷移經驗的情況下是完全可實施的,，需要擔心的只是工作量的問題,。
至于選擇遷移到IAR還是GCC，主要考慮以下幾點：
·是否有充足的預算,。相信大家最常見的遷移原因就是眾所周知的合規(guī)問題,，如果必須遷移，又沒有預算,，只有硬著頭皮轉GCC了,。如果能有預算，可以考慮購買IAR正版,，選IAR的話遷移也都是比較方便的,，并沒什么風險，付錢的工具還是比免費的要靠譜得多,，而且還能得到相應的支持,。當然，如果同一家廠商能夠同時支持Arm和RISC-V的工程開發(fā),，則可能有更高的投資回報（ROI）,。
·對不同工具的熟悉程度?？缙脚_遷移需要對工具有一定的熟悉度,，尤其是遷移到GCC，由于GCC版本眾多,，又沒有成熟的IDE,，又沒有技術支持的情況下，如果工程師對開發(fā)工具并不精通,，還是很難順利遷移成功,。如果沒有相關經驗，還是建議選擇IAR,，畢竟IAR官方自帶的自動化轉換工具還是很方便的,，如果有正版IAR License,，還可以有IAR官方人員回復你遷移過程中碰到的問題，IAR官方的技術支持申請鏈接是https://www.iar.com/cn/knowledge/support/request-technical-support/,。
·遷移風險是否能夠接受,。即使是項目的代碼本身遷移成功，也不代表項目整體的遷移成功了,，有可能遷移到GCC之后由于編譯性能的降低,，生成的可執(zhí)行代碼在現(xiàn)有的硬件平臺上性能不滿足！最常見的就是代碼體積變大,，F(xiàn)LASH不夠用了,，或者RAM不夠了，前期努力白費T_T ,。為了避免這種風險,，穩(wěn)妥的路徑還是采用商用級別的編譯器，IAR還是比較穩(wěn)的,。IAR支持14天免費試用,，可以直接去申請個試用版試試能否遷移成功，試用鏈接https://www.iar.com/cn/product/architectures/arm/iar-embedded-workbench-for-arm/iar-embedded-workbench-for-arm---free-trial-version/
以上內容基于自己的經驗和知識總結,，希望對各位考慮項目遷移的朋友們有幫助,，如果有錯誤，歡迎指正,！
更多精彩內容歡迎點擊==>>電子技術應用-AET<<
