Eclipse Embedded CDT: an Arm and RISC-V C toolchain inside the Eclipse IDE

It is the GNU MCU plug-ins renamed and moved under the Foundation

The project describes itself as the Eclipse Embedded CDT plug-ins for Arm and RISC-V C and C++ developers, formerly known as the GNU MCU Eclipse plug-ins. The rename and the move are both in the README, and they explain a lot about where the project sits today. It is now part of the Eclipse Foundation and is hosted on GitHub under the eclipse-embed-cdt organisation, with the project home at eclipse-embed-cdt.github.io. The description also notes that the repository includes the archive of previous plug-in versions as Releases, which matters for anyone who pinned an older update site and now finds it gone. Copyright runs to Liviu Ionescu and others from 2012, so this is a long-lived codebase with a stable identity rather than a new project.

Three install routes, and the packaged IDE is the easy one

The How to install section lays out three options, and the order tells you which one the project prefers. For new installs, the preferred method is the Eclipse IDE for Embedded C/C++ Developers from the Eclipse downloads packages page, which packs the official Eclipse IDE for C/C++ Developers release with all the Embedded CDT plug-ins already installed. Older packages are available from the GitHub Releases of the packaging repository. For existing Eclipse instances, the recommended method is the Eclipse Marketplace, where you search for Embedded CDT. That division is sensible. A packaged IDE avoids a class of setup problems for someone starting fresh, and a Marketplace install avoids disturbing an existing workspace for someone who already has Eclipse configured the way they like. The repository also has a `README-EPP.md` for the packaging side, which is where the details of the bundle live.

The update sites are the real configuration surface

For anyone integrating the plug-ins into an existing Eclipse, the update sites are what you actually point at, and there are three of them with different risk profiles. The stable site is the official release, and the same content is what the Marketplace and the packaged IDE carry:

- Stable: `https://download.eclipse.org/embed-cdt/updates/v6/`
- Pre-release versions: `https://download.eclipse.org/embed-cdt/updates/v6-test/`
- Development versions: `https://download.eclipse.org/embed-cdt/builds/develop/p2`

The README's guidance on each is specific. The pre-release site should usually be safe but should be used with caution. The development site lets you test features that are not completely implemented, or that might change before a final version is released, and it comes with a note that the site is not always functional, that you should use it carefully, back up your workspace, and not use it for production projects. That warning is unusual to see stated this plainly, and it is the single most useful sentence in the README for a team deciding how to roll this out.

Runtime requirements are a Java version and a CDT version

Starting with v6.x, the minimum requirements for running the plug-ins are JavaSE-11 or later and CDT 9.2.1 (Neon.3), and the recommended set is JavaSE-11 or later with Eclipse 2020-09 or later. The distinction between minimum and recommended is worth keeping, because the minimum is what the code compiles and runs against, and the recommended is what the project believes you should use. The CDT dependency is the more important constraint in practice, since CDT 9.2.1 is the version that shipped as Neon.3, and an Eclipse installation older than that cannot simply update its CDT in isolation. The licence is EPL 2.0, with the SPDX identifier recorded in the README, which is the standard Eclipse Foundation licence and a reasonable one for plug-ins that extend a host application.

The repository layout shows a full p2 build, not a source drop

Based on the repository listing, this is a proper Eclipse plug-in build rather than a loose set of jars. There is a `pom.xml` and a `.mvn/` directory, which points at a Maven Tycho build, and the standard p2 repository layout with `features/`, `plugins/`, `repositories/`, `target-platform/`, and `parent/`. There is also a `scripts/` directory and a `branding/` directory, plus `info/`, a `debug.options` file, `.settings/`, and `.vscode/` for editing the sources in VS Code. The `target-platform/` directory is the piece that matters most to a maintainer, because the p2 target platform is what pins which CDT and platform versions the plug-ins build against, and it is the first thing that has to move when a new Eclipse release lands. The presence of `CONTRIBUTING.md`, a `NOTICE.md`, and a separate `README-MAINTAINER.md` for maintainers is a good sign about the project's process.

Where Embedded CDT is the wrong tool

The boundary here is vendor coverage, and it is a hard one. The plug-ins are for Arm and RISC-V C and C++ developers, which means the debug and flash support is oriented at those toolchains. A team working on a different architecture, or on a vendor toolchain that only ships its own IDE integration, gets nothing from this and would be back to command line flashing and debugging. The second limit is the Eclipse dependency itself. The plug-ins run inside Eclipse, so your build has to work inside Eclipse's project model, with the CDT headless build, and that is a constraint on how you organise a project if you already use something else. The third is the version cadence. The releases move in 6.x lines, and each new line needs a CDT version to match, so an organisation that pins its Eclipse platform cannot simply take the newest plug-ins whenever they appear.

Editorial conclusion

Embedded CDT fits a team that develops embedded firmware in Arm or RISC-V C and wants to keep its IDE, its build integration, and its debug workflow inside Eclipse rather than juggling separate vendor IDEs and command line tools. It is the wrong choice for a group split across vendors, since the whole value is one toolchain inside one IDE, and it is the wrong choice if you need the newest features immediately, because the development update site is described as not always functional and explicitly not for production. Before you install, confirm you have JavaSE-11 or later and CDT 9.2.1, and start from the stable update site rather than the development one, backing up your workspace as the README advises.

Frequently asked questions

Official sources

1. eclipse-embed-cdt/eclipse-plugins on GitHub
2. License: EPL-2.0
3. Project website
4. README
5. Releases