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; 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 easier. The author is very responsive and timely in replies, 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.

It is highly recommended 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 Garden (cnblogs.com)

Additional Preparation#

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

You will need the classic tool Cortex-debug plugin.

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 am using 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, you may need to use Openocd for debugging, so you will 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 recommended to use 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, you will still need to separate projects for different development environments. If you lack the ability to separate configurations for different environments, you have already strayed far.

Pitfalls of the Development Environment#

Simple yet complex pitfalls are related to whether the development environment can be set up, and this only involves 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 /**/, // comment statements, and tags like .syntax, .section, .global, etc.
ARM format, characterized by using ; to start comments and not using tags that start with .xxx.

Therefore, it is necessary to automatically select the assembler type, but if the assembler type is configured as auto, the preprocessor definitions will not be allowed. You need to select the assembler as "arm-clang" and add the assembly additional option "-masm=auto" to automatically select the assembler while using predefined options.

Step-by-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 debug page and add a workspace debug configuration. Since our project and source code are in different directories, it is better to use the workspace as the criterion for the debug configuration.

It will automatically generate a small amount of code under the workspace json, which can be completed through auto-completion or manually written as follows:

The key configurations include:

"cwd": current working directory, usually others configure this as ${workspaceRoot}. Since our workspace has more than one folder, we will have at least two folders: the EIDE project folder and the 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, found in the EIDE project's compilation output directory.
"name": the name of the debug task, which will appear in the dropdown box on the debug page for selection.
"type": the type of debugger, we connect to the chip for debugging, fill in cortex-debug, and use the cortex-debug plugin for debugging.
"device": the complete model of the chip, which needs to be supported by the debugger. We usually use the JLink debugger executable file, so it should be the name supported by JLink that we are using. (If the configuration is wrong here, it can be a big problem, just ask someone for help.)
"servertype": select according to what you are using, I am using jlink, if it is openocd, just change it to openocd.
"interface": debugging connection 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 (the keil pack can be extracted).
"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.