Embedded IDE for VS Code: One Extension for 8051, STM8, Cortex-M, MIPS and RISC-V

The gap Embedded IDE fills between vendor IDEs and a plain editor

MCU work has a split personality. The compiler, linker script and flash algorithm usually live in a vendor IDE, while the editing experience engineers actually want lives in VS Code. Moving between the two means either keeping a vendor IDE open for builds and a separate editor for reading code, or hand-assembling a Makefile, a c_cpp_properties.json and a debug launch configuration per chip family. Embedded IDE targets that second option. It is a VS Code extension that provides project creation, compilation and program flashing for 8051, STM8, Cortex-M, MIPS and RISC-V targets, per the README summary. The audience is embedded engineers who already use VS Code and want the build and flash loop to stay there. It is less relevant to someone who only writes firmware for a single STM32 part and is happy with STM32CubeIDE, and it is not aimed at application developers who never touch a linker script.

Project model, toolchain selection and the import path from Keil, IAR and Eclipse

The extension is organized around a project plus a selected toolchain rather than around a fixed compiler. The README lists armcc, gcc-arm-none-eabi, llvm-for-arm, riscv-gcc, generic xxx-gcc, keil_c51 and sdcc among the build toolchains, and jlink, stlink, openocd and pyocd among the flash backends. That separation matters: the same project tree can be pointed at a different compiler or a different probe without restructuring the source layout. The import feature is the part that changes migration cost. According to the README, the extension can import KEIL5, IAR and Eclipse projects, and can import the source file resource tree from IAR-STM8, IAR-ARM and Segger Embedded Studio projects. For Cortex-M projects it can also install standard KEIL chip support packs. So the data flow is: existing project metadata in, a VS Code project tree out, then a toolchain path you set yourself. The extension also registers a C/C++ IntelliSense provider for ms-vscode.cpptools, which the README says removes the need to configure c_cpp_properties.json by hand. That is a concrete reduction in per-project setup, and it is one of the more practical features here because include-path drift is a common source of red squiggles in imported projects.

Getting a project to build and flash: the Operations bar and the Node 18 constraint

The quick start in the README is three steps. Install one of the supported compilers. Open the Operations bar of the extension and set the compiler installation path. Then click New or Import in the Operations bar to start a project. There is no separate CLI to learn for the basic loop; the Operations bar is the control surface. If you build the extension from source instead of installing it from the marketplace, the README is explicit that NodeJS 18 is required, recommending v18.18.2, and that this is a historical constraint rather than a preference. The build steps are npm install, then ctrl+shift+b to open the VS Code task list, where npm: webpack builds the extension for F5 debugging and build vsix produces a package. The README also warns that opening the source in VS Code may show syntax errors because the project uses an older TypeScript version, and instructs you to run TypeScript: Select TypeScript Version... and pick v5.8.2. That is an unusual amount of friction for contributors, and it suggests the extension's own toolchain has not been modernized alongside its feature set.

Debugging, disassembly and the utilities that ship inside the extension

Beyond build and flash, the README describes a set of built-in utilities: a CMSIS Config Wizard UI, a disassembly view, a program resource view, and a callgraph GUI tool for gcc toolchains. It also states that default debug configurations are generated automatically for the cortex-debug and STM8-Debug debugger extensions. The pattern is consistent: Embedded IDE does not implement its own debugger, it produces the launch configuration that an existing debug extension consumes. That is a reasonable division of labor and keeps the extension from competing with mature debug front ends. Static checking is handled through Cppcheck. The README also notes that the built-in serial port monitor was removed and recommends the separate Serial Monitor plugin instead, which is a candid admission that some peripheral functionality belongs in other extensions. The MCP support is worth flagging separately: the README says basic functions of the built-in plugins can be called through MCP Tools, that this must be enabled in settings, and that the MCP server is disabled by default. Anyone evaluating the extension for scripted or agent-driven workflows should treat MCP as opt-in and verify what the exposed surface actually covers.

Where Embedded IDE is the wrong tool

The README's supported platform list is narrower than the feature list suggests. Windows x64 requires Windows 10 or later, Linux is x64 only, and macOS is described as only tested on macOS 10.15 x64. There is no statement about Apple Silicon, and no statement about 32-bit hosts. If your team is standardized on arm64 Macs, that is an open question you would need to resolve before planning a rollout. The second limitation is architectural: because project management, toolchain paths and flash settings live in the extension's own configuration, a headless CI runner does not get the same experience. Nothing in the README describes a documented command-line build entry point, so a pipeline would either drive the extension's internals or maintain a parallel build script, at which point the extension's project model is no longer the single source of truth. Third, the KEIL chip pack installation is explicitly limited to Cortex-M projects, so 8051 and STM8 users do not get that convenience. Finally, the extension is a large surface area maintained by a single author with community contributions gated through an issue discussion first, per the contribution guidelines. That is a governance fact, not a quality judgement, but it affects how quickly a broken toolchain integration gets fixed.

How this differs from PlatformIO

PlatformIO is the obvious comparison, and the difference is in where the toolchain definitions come from. PlatformIO ships a package manager: you name a board or platform in platformio.ini, and it downloads and versions the toolchain, the framework and the upload tool for you. Embedded IDE takes the opposite approach. You install the compiler yourself, then point the extension at the installation path through the Operations bar. There is no package registry mediating versions. The trade-off is direct. PlatformIO gives you reproducible toolchain versions and a command-line interface that works headlessly, which is why it fits CI well. Embedded IDE gives you the ability to use the exact compiler you already have, including vendor toolchains like armcc and keil_c51 that PlatformIO does not manage, and it can absorb existing Keil5, IAR and Eclipse project trees rather than requiring a fresh project definition. If your firmware is built with a licensed vendor compiler, or your team has years of Keil project settings to preserve, that import path is the reason to look here. If you want a board list and a lockfile, PlatformIO is the more direct fit.

Licence, versioning and what maintenance actually costs

The repository is MIT licensed, which permits commercial and closed-source use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive arrangement and it removes the licensing question that vendor IDEs sometimes raise. It is not legal advice; check the LICENSE file and your organization's policy. On maintenance, the release cadence visible in the repository is frequent: v3.26.9 in May 2026, v3.27.0 later that month, and v3.27.2 in June 2026, with the last push to the default branch in August 2026. Frequent point releases on a single-author project can mean fast fixes, and they can also mean churn in project configuration formats. The practical cost to budget for is the Node 18 and TypeScript 5.8.2 pinning if you build from source, plus the ongoing need to re-verify toolchain paths after upgrades. The extension is distributed through the VS Code Marketplace under the identifier CL.eide, so most users will upgrade through the normal extension update flow rather than building a vsix.

Editorial conclusion

Adopt Embedded IDE if you work across several MCU families and want one VS Code workflow for building and flashing, especially if you have Keil5, IAR or Eclipse projects to bring over. Skip it if you depend on a vendor IDE's simulator, its exact debug views, or a fully hands-off CI pipeline, since the extension's value is concentrated in interactive project management. Before committing, verify that your specific compiler is listed among the supported toolchains, that the installation path you set in the Operations bar is detected, that the import of your existing project reproduces the same source tree, and that your debugger (jlink, stlink, openocd or pyocd) connects from the generated configuration.

Official sources

1. github0null/eide on GitHub
2. License: MIT
3. Project website
4. README
5. Releases