Keil MDK is a commonly used development tool in the embedded industry and is familiar to embedded engineers. But recently I heard that Arm company is going to merge Keil MDK into Arm Development Studio, so the version update of Keil MDK has basically stopped. Everyone is still using a very old version of Keil MDK, which is not very convenient in terms of functions. I hope to find more Good alternative tool. In addition, judging from the recent industry events including the RISC-V China Summit, the development of RISC-V in China is in full swing and has a strong momentum. Therefore, it is also necessary to consider whether development tools will support RISC-V in the long term and can Reuse related designs through migration.
However, replacing Keil MDK requires consideration of how to migrate project projects to other tools. Due to different project file formats and differences in underlying compilation technologies, Keil MDK's project files are not fully compatible with other tool platforms and require a certain amount of migration work. Based on the author's experience, this article will share how to quickly migrate Keil MDK code to other platforms and solve the problem of incompatibility of project files between different platforms.
Currently, there are two common target platforms for migrating Keil MDK code, namely GCC and IAR. Let me introduce and compare the differences between the two:
Overview:
- GCC is also very common, but it is just a compiler and needs to be used with an IDE. Common choices include IDEs such as VSCODE or Eclipse. Since they are free components, you need to build them yourself. You must have a certain knowledge of IDE construction to use them. , of course the biggest advantage is that it is free. Some friends have to give up using Keil MDK due to some well-known special reasons. If they have no budget to buy other tools, GCC is basically the only option;
- If you have the budget to buy commercial tools, another option is IAR. IAR is a commercial tool of the same level as Keil. It has good performance and user experience. It comes with an IDE and does not require configuration. It can be installed and used directly. At the same time, in addition to supporting Arm-based projects, IAR's Embedded Workbench tool also has a version that supports RISC-V, which is of great significance to engineers who have many projects and applications or who want to further expand RISC-V architecture projects. This is because the process of porting from IAR Embedded Workbench for Arm to IAR Embedded Workbench for RISC-V is inconvenient because many folder contents have been unified.
Project migration process comparison:
First of all, it should be stated that the migration project is divided into two parts. The first is the adaptation of the project file format, and the second is the adaptation of the project code.
- Adaptation of project files must be done, and the method and route are relatively certain.
- Under normal circumstances, if standard C/C++ is used in the project, there should be no problem in compiling. However, the adaptation of project code may involve some migrations that are not standard C/C++. For example, under certain special requirements, it is difficult for standard C/C++ code to implement certain functions, and using the compiler's inline functions (Intrinsic) can make it easier. Implement these functions efficiently. If non-standard C/C++ is involved, users need to specifically migrate these non-standard C/C++ across compilation platforms.
Regarding the migration of non-standard instructions, I will not introduce it here because there are too many instructions involved and it is impossible to introduce them all in one article. If you encounter them, you can deal with them individually.
The following is a general introduction to project migration guidance:
Migrate from Keil to GCC
Generally the following content needs to be modified:
- Project directory configuration: View the Keil MDK file directory from the .uvproj file, and configure the same files into the GCC Makefile file directory;
- Linker file: The linker file of Keil MDK is .sct. According to the corresponding description, you can handwrite a link file in the format supported by GCC;
- Startup code: Generally, chip manufacturers with good services will produce startup codes for different compiler platforms. You can look for them in the routine documents. If you see a format that supports GCC, you can use it directly. If not, you will need to write it by hand. Different chips have to write startup files separately. It is difficult to write it by hand. It requires a good understanding of the chip and generally requires the support of people from the chip manufacturer. I won’t go into details here.
- Make Makefile project files, including
- Project directory configuration of source files,
- GCC format connection file replacement,
- Copy the compilation parameters and connection parameters of Keil MDK to the corresponding parameters of the Makefile;
- Add device information and debug configuration (GDB)
After migration, verification must be carried out, including verification of compilation results, verification and adjustment of code size and running speed of the compiled executable file. If the code size or running speed is not up to standard, the compiler optimization options need to be adjusted. After adjusting the optimization options, remember to retest whether the code execution results are as expected, because different optimization options may cause changes in the code execution results.
Migrate from Keil to IAR
If you are migrating to IAR, it is recommended to use IAR's official project conversion tool IAR Project Converter, which will make the migration process very convenient. In the menu bar of IAR's Embedded Workbench for Arm tool, click Tools à IAR Project Converter to automatically convert Keil's project files and codes into IAR format, and finally replace the .s startup file with IAR format. Generally, there are .s files in different formats in the code examples provided by chip companies. Just find the IAR version and replace the original one. Of course, after migration, you still need to verify whether the compilation is normal and test whether the code is running normally. If you use IAR, you basically don't have to worry about the code size becoming larger or the running speed slowing down. IAR has very good compilation optimization. Under normal circumstances, the compilation results will be better. You only need to find the appropriate compilation options.
Summarize:
It is technically feasible to migrate the Keil project to other platforms, especially when the code does not involve non-standard C/C++ code. It is completely implementable if you have experience in project migration. All you need to worry about is the workload.
As for choosing to migrate to IAR or GCC, the main considerations are the following:
- Do you have sufficient budget? I believe that the most common reason for migration is the well-known compliance issue. If migration is necessary and there is no budget, the only choice is to switch to GCC. If you have the budget, you can consider purchasing genuine IAR. If you choose IAR, migration is more convenient and there is no risk. Paid tools are still much more reliable than free ones, and you can also get corresponding support. Of course, if the same manufacturer can support the engineering development of both Arm and RISC-V, there may be a higher return on investment (ROI).
- Familiarity with different tools. Cross-platform migration requires a certain familiarity with tools, especially migration to GCC. Since there are many GCC versions, there is no mature IDE, and there is no technical support, if the engineer is not proficient in development tools, it will still be difficult to go smoothly. Migration successful. If you have no relevant experience, it is still recommended to choose IAR. After all, IAR’s official automatic conversion tool is very convenient. If you have a genuine IAR License, you can also have IAR official staff to answer questions you encounter during the migration process. IAR’s official technology The support application link is https://www.iar.com/cn/knowledge/support/request-technical-support/ .
- Whether the migration risk is acceptable. Even if the project code itself is successfully migrated, it does not mean that the overall project migration is successful. It is possible that due to the reduction in compilation performance after migrating to GCC, the performance of the generated executable code on the existing hardware platform is not satisfactory! The most common thing is that the code size becomes larger, FLASH is not enough, or RAM is not enough, and the early efforts are in vain T_T. In order to avoid this risk, the safe path is to use a commercial-level compiler, and IAR is relatively stable. IAR supports a 14-day free trial. You can directly apply for a trial version to see if the migration is successful. Trial link IAR Embedded Workbench for Arm - Free Trial Version | IAR
The above content is based on my own experience and knowledge summary. I hope it will be helpful to friends who are considering project migration. If there are any mistakes, please correct me!
Author: Mars