Talking about how to be "ravaged" by MDK, IAR, GCC and manufacturer's SDK version compatibility over the years, one version after another

Original article, reprint please indicate the source: https://www.armbbs.cn/forum.php?mod=viewthread&tid=119562


Version iteration is a permanent pain in embedded development. I don't know how much time was wasted on version iteration for so many years.

Some system components are better, there is an LTS long-term support version, but the manufacturer's SDK and IDE environment can be described as horrible, one version after another.


Video version:

https://www.bilibili.com/video/BV1qu4y1d7wV

Talking about how the compatibility of MDK, IAR, GCC and chip manufacturers' SDK versions has been "ravaged" over the years, one version after another


【MDK】

This IDE was used when I first came into contact with M-core chips. There were MDK2 (mainly used by 51) and MDK3 at the earliest. After entering MDK4, MDK4.

After iterating to MDK4.74, the MDK5 era started. The MDK5.0X and MDK5.1X at the beginning were just filling holes, so there are not many people who use MDK4 to reprint to MDK5.


1. After entering MDK5.2X, start the first watershed.

The new products released by chip manufacturers can no longer use MDK4, and must switch to MDK5. In order to alleviate the user's dependence on MDK4, KEIL launched MDK5, and then only made a compatibility package between MDK5 and MDK4. During the initial promotion, many people did not know about this compatibility package.

 

After forcibly opening MDK4 with MDK5, all kinds of problems have been messed up. It is a bit unrealistic to recreate all the examples with MDK5, there are too many examples. Later, I kept exploring and made a show operation, directly modifying the MDK4 project suffix uvproj to the MDK5 suffix uvprojx. Most of the examples can be opened with MDK5 so conveniently.
 

2. The second watershed, MDK5 compiles the HAL library

MDK5 AC5 compiling HAL library with brower info can be called an epic disaster, compiling for 10 minutes is trivial. Even if the compilation is slow, the CPU of the computer has soared to 100%, and the computer can't do anything, so it can only wait.

 In order to alleviate the anxiety of users, I started to promote MDK AC6. I was quite happy at the beginning, and the compilation speed was much faster with browser info. After the compilation was completed, I found that go to def could not be used. After research, it turned out that the generation of browser info was moved to the background. The actual total time is not much different from AC5.

 


3. The third watershed, AC5 to AC6

It is estimated that this pain point cannot be solved in recent years, because a large number of open source projects on the market are still created by MDK AC5, and more importantly, some open source components in the project do not support MDK AC6, which brings great difficulty to MDK AC6. Although KEIL later released the AC5 to AC6 document, it was too much to pay for, and the modification of complex projects was too difficult.

 Since it is so troublesome, why switch to AC6, because AC5 has been officially launched on the stage of history since MDK5.

Most of the current projects still need to use the AC5 LINK warning type

 


4. The fourth watershed, MDK RTE creation project

The early chips also supported the MDK RTE classic creation method, which is very easy to use and powerful, which is worthy of recognition.

Later, the new chips also showed disaster-level performance. Taking STM32H7 as an example, the classic method is no longer supported. RTE must be used together with STM32CubeMX, and the corresponding project must use the specified MDK version, CMSIS version and STM32H7 software package version.

 


5. The fifth watershed, MDK software package download problem

Originally, downloading from the official website was extremely difficult, but recently, a show operation was carried out, which made the already difficult downloading problem even worse, and the downloading of software packages became extremely difficult to use

 


6. MDK6 will be released by the end of this year

This is bound to be another crazy operation.

 


【AND】

IAR first used IAR6.3, and then used 7.x, 8.x and 9.x successively

The biggest disadvantage of the early versions of IAR is that there is no compatibility at all. Your project is created with a version, and you must use that version to open it. Later, IAR8.X and 9.X were much better, and programs created in previous versions can be forcibly converted.

 In addition to compatibility issues, the new IAR9.X has brought a pitfall. The previous fputc and fgetc redirection serial ports cannot be used, and their official redirection methods must be used to solve it.

IAR9.X printf serial port underlying redirection method, otherwise it will prompt Linker Error: "no definition for __write" - Development Environment- Tough Guy Embedded Forum- Powered by Discuz!

 


【GCC】

The IDE environment created based on GCC also has various compatibility issues. Taking Embedded Studio as an example, the project created with V5.X before can not be compiled normally when using V7.X, and an error is reported directly.

Who is to blame for this? Netizens cannot compile normally when they open it. This user experience is not very comfortable.

 Based on the gameplay of eclipse/vscode/clion + gcc + openocd, I rarely use it and have not studied version compatibility issues.

 

 


【Chip manufacturer SDK】

The SDK of the chip manufacturer is also a variety of pits, all kinds of tossing users.

Take STM32 as an example to illustrate

(1) Standard library to HAL and LL library

In the early days of F1, F2, F3, F4 and other series, the standard library gameplay is already very mature, and when the time is critical, the register method is used to speed up the implementation, and most projects are enough. But later, in order to cooperate with the STM32CubeMX graphical development tool, the HAL and LL libraries had to be launched.

It is better for users to make products, but it is a disaster for us to make development boards, and we have to make two versions of HAL library and standard library. Even if necessary, all projects created using STM32CubeMX must be provided.

(2) Version iteration of the HAL library

Sometimes version iteration does not consider compatibility, which is also a headache. Taking the serial port code as an example, the subsequent upgrade will directly perform a coquettish operation of deleting structure members:

 For various compatibility issues, do you have any good ideas to solve these problems? Welcome to share. Personal use is fine, but compatibility has to be considered when sharing between teams or online.

Guess you like

Origin blog.csdn.net/Simon223/article/details/131128294