Don’t worry: despite all the things going on with VS Code, Eclipse is here to stay probably for many more years. The Eclipse foundation is pumping out releases, and so does NXP with their latest MCUXpresso IDE 11.8.0. Lets have a look…
Outline
The release comes with updated Eclipse, ARM tool chain and newer debugger software. If you are using a Mac with Apple silicon, you definitely should check out this new release.
The release comes with new SDK v2.14 support and many bug fixes. Below some new features ore capabilities I noticed….
CMSIS-Packs
The release includes updated CMSIS-Pack support and plugins. It manages now component dependencies too.
You have to be patient if it connects the first time to the repository. After that, you has to enable the project first for CMSIS-Packs:
With that, I can use packs and a new view shows up:
LinkServer and MCU-Link
The version 11.7.x introduced a change in the USB protocol used for the CMSIS-DAP LinkServer/MCU-Link debug probes. In case of an older firmware you get a direct link to the latest version for download:
Another thing I noticed: launching a LinkServer debug session is much faster now. This affects the time from pressing ‘debug’ until the I’m debugging on the target.
TAD Console
In 11.7.x it was already possible to disable the logs for the Thread Aware Debug plugins. The logs and console views were annoying, because they were created even if not using any of the RTOS supported. Finally there is a setting to have both the logs and console disabled (what I recommend):
GNU ARM Embedded v12.2
The IDE comes with the 12.2.R1 release of the GNU ARM Tools. I really like that by default this new toolchain is somewhat picky and puts out warnings for legacy code: I used that to improve the quality of code. It comes with gcc 12.2 which implements C++20 plus several C++23 features, including new and updated standard libraries. The IDE misses a drop-down option for the new compiler options, but I can add it manually. For example for switching to C++20, I can use the option
-std=c++20
CDT
The IDE comes with an updated CDT 11.0, and I’m using it fine in combination with CDT 11.2 features (like remote debugging over SSH). Notable is better support for dynamic printf. Additionally the issue with recompiling projects after opening a workspace has been fixed, which was very annoying in IDE v11.7.x. That’s definitely a big reason to move from 11.7 to 11.8.
Summary
The Version 11.8.0 is a solid new release, in a row of releases. If you are a C++ or Apple Silicon lover, be sure to check out this new release. I will gradually migrating my NXP Eclipse based projects to the new version. Especially because of the faster LinkServer enumeration plus the fix for the CDT project-rebuild, I will leave the version 11.7.x behind, except for projects where the version has been frozen.
Happy eclipsing:-)
Links
- Community: https://community.nxp.com/t5/MCUXpresso-IDE-Knowledge-Base/MCUXpresso-IDE-v11-8-0-Now-Available/ta-p/1696945
- NXP download site: https://www.nxp.com/mcuxpresso/ide/download
- GNU ARM Toolchain: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads/12-2-rel1
- GCC 12 release: https://gcc.gnu.org/gcc-12/
MCU on Eclipse 
So do you think long term VS code + NXP plugin will supplant their Eclipse solution?
I really like the thought of VS Code + NXP SDK development. In the early days I tried several alternative methods of developing with VS Code but none were satisfactory for one reason or another which is why I settled for the SEGGER IDE (SES) toolchain.
But lately I have found Segger as a company less than ideal to work with (long story). I no longer like being tied to Segger debuggers as a result (one cant use non Segger debuggers with SES). Hence, if I can make use of VS Code to develop and debug my IMX-RT projects, I see this as very attractive.
Your thoughts?
LikeLiked by 1 person
So here are my thoughts: As I said earlier: I don’t see Eclipse going away, at least not in the next coming years. To me, Eclipse is still the industry standard as it comes to embedded development and debugging. Microsoft and VS Code to me will make an impact, especially attracting more of the non-embedded developers to the embedded world. This brings in many modern software development technologies to the tool set: not something which cannot be done with Eclipse, but something which looks easier to be done in the world of VS Code. Beside of Eclipse based tools, I’m using Visual Studio (non-Code) and VS Code for many years now: it just has not been up to the level for embedded development. Now with recent additions and extensions, things are moving into that direction. It still will be a long journey, but it is a start. I think silicon vendors will offer VS Code in addition to their existing offers, simply because the competition is providing VS Code as well, because they realize that software and tools are the becoming the key factor for selling their silicon. So I see both ‘worlds’ to coexist for some time.
LikeLike
My experience over many years was with IAR and Keil. It worked well until their UI’s got dated… Even Eclipse is better! I don’t like being tied to the Silicon Vendors tools as I find them less than satisfactory. The landscape has changed and tool vendors policies e.g: support, are not very good anymore.
So my hope is that VS Code with Supplier plugins and the ability to use any debugger is the way of the future. I can only hope! 🙂
LikeLike
Hi John,
there is hope, but risks with VS Code too. One is Microsoft itself, the other are that the extensions are causing conflicts or any other kind of problems. These problems are kind of unavoidable, because there are so many actors ‘in the wild’, and everything pretty much gets updated and changed every day. Tools like IAR and Keil are dated, but they were solid and stayed unchanged for years, exactly what you need in the embedded space. The user interface and UI is important, because it is a productivity factor. But the UI tends to be subject of ‘holy wars’ too. At the end, it is probably a personal choice, which contradicts my mantra that an engineer has to choose the best tool to do the job, not the one he likes most.
As for tied to be to a vendor: this is indeed an issue, and probably soon someone will comment here about platformIO, but ultimately even platformIO is a tie-in into a different vendor. My advice would be: always use different things, so you don’t have to ‘switch’, as already having multiple solutions and tools in place.
LikeLike