24_7_12_Recommended Plugin! EIDE as an Alternative to Keil

General Introduction#

EIDE is a VSCode plugin for developing microcontroller projects, such as: 8051, stm8, stm32, other cortex-m mcus...

It is recommended to use EIDE for subsequent application development of keil projects, while the board and peripheral setup should still be done in keil, as it is official and reliable. At the same time, generating keil projects with stm32cubemx is also very convenient, and it is better to explore peripherals in keil initially.

Why Choose EIDE Instead of PlatformIO IDE?#

The most important reason is that EIDE can seamlessly import keil projects! This means that stable projects do not need to be re-validated, and EIDE supports the only valuable component of keil—the AC6 compiler.

Additionally, EIDE is a plugin developed by Chinese developers, making community communication stress-free. The author is very active and replies promptly, and you can also try to reach out to the author for some non-plugin technical issues.

Here is the community address

Embedded IDE Forum (em-ide.com)

Preliminary Preparation#

Clarify our preliminary preparation goals: vscode+EIDE installation is complete, and the EIDE plugin can detect the existence of the ARM-GCC and AC6 toolchains.

This article will not provide step-by-step installation instructions.

The primary recommendation is to read the official documentation, at least complete the "Getting Started" section in the official documentation.

Installation | Embedded IDE For VSCode (em-ide.com)

Additionally, there is a good community blog post, but it is still most recommended to follow the official documentation for environment configuration.

[VSCODE] Building STM32 Microcontroller Development Environment Based on EIDE Plugin - Foriver - Blog (cnblogs.com)

Additional Preparation#

Additional preparation is for debugging purposes. It is well known that if the on-chip program cannot be step-debugged, it is basically impossible to develop complex programs.

The classic tool Cortex-debug plugin is needed.

Again, refer to the official community documentation.

cortex-debug Usage - Blog - Embedded IDE Forum (em-ide.com)

In simple terms, there are two points that need to be configured:

Configure the ARM-GCC toolchain path, in my environment, the path is C:\\111_APPS\\arm-gnu-toolchain-13.2.Rel1-mingw-w64-i686-arm-none-eabi\\bin, which contains tools like arm-none-eabi-gcc.exe, arm-none-eabi-ld.exe, etc.
Configure the GDB application path you need, for example, if I use JLink for debugging, I need to configure the JLink GDBServer Path, in my environment, the path is C:\111_APPS\SEGGER\JLink_V794f, which contains the JLinkGDBServer.exe application. If you are not using JLink and may need to use Openocd for debugging, then you need to configure the Openocd Path.

The two items I set are as follows:

Getting Started#

For users using the EIDE plugin for the first time, it is first recommended to create a backed-up KEIL project for testing, and ensure that this project can compile normally and light up the board in KEIL.

Import this project according to the official documentation.

Import Project | Embedded IDE For VSCode (em-ide.com)

During the import, a prompt will pop up asking where to place the vscode workspace project. For first-time users, it is recommended to place it directly with the original keil project files to avoid extra operations. However, after familiarizing yourself with the new development environment using the test project, it is still necessary to separate projects for different development environments. If you cannot separate the configurations for different environments, you have already gone too far.

Pitfalls of the Development Environment#

Simple yet not simple pitfalls related to whether the development environment can be set up, here we only involve the AC6 compiler, as the gcc compiler is still too weak.

Major Pitfall of Assembly Compilation#

The assembler configuration is as follows, and there is a major pitfall here!

The assembly code we receive will be written in different assembly formats.

GNU format, characterized by using /**/, // for comments, and using .syntax, .section, .global, and similar labels.
ARM format, characterized by using ; to start comments and not using labels that begin with .xxx.

So, it is necessary to automatically select the assembler type, but if the assembler type is configured as auto, then the preprocessor definitions will not be allowed. Therefore, the assembler should be selected as "arm-clang," and then add the assembly additional option "-masm=auto," which allows for automatic selection of the assembler while using predefined options.

Step Debugging Configuration#

It is well known that the vast majority of MCU engineers are hardware engineers pretending to be software engineers. These configurations are still too difficult for MCU engineers, which is why KEIL remains the mainstream IDE to this day.

First, observe the debugging page and add a workspace debugging configuration. Since our project and source code are in different directories, it is better to use the workspace as the debugging configuration criterion.

It will automatically generate a small amount of code under the workspace json, which can be completed through auto-completion or written to look like the following.

The key configurations that need to be focused on are:

"cwd": current working directory, usually others configure this as ${workspaceRoot}. Since our workspace has more than one folder, we will have at least an EIDE project folder and a SRC source code folder, so we need to add the suffix of EIDE here to point to the EIDE project folder as the base.
"executable": the generated executable file, look for it in the compilation output directory of the EIDE project.
"name": the name of the debugging task, which will appear in the dropdown box on the debugging page for selection.
"type": debugger type, since we are connecting to the chip for debugging, fill in cortex-debug, and use the cortex-debug plugin for debugging.
"device": the full model of the chip, which needs to be supported by the debugger. We usually use the executable file of the JLink debugger, so it should be the name supported by the JLink we are using. (If the configuration is wrong in the burning configuration, it will be a big trouble, just call someone for help.)
"servertype": select according to what you are using, here I use jlink, if it is openocd, just change it to openocd.
"interface": debugging wiring method.
"svdFile": system view description, which is optional for application engineers. It is used to view register values during debugging. If you want it, you can find it on the ST official website, but other microcontrollers may not publicly provide the svd file (it can be extracted from the keil pack).
"liveWatch": an option to view the real-time values of variables and the answers to calculations, which is actually enabled by default and does not need to be configured.