Support for C and C++ is officially supported in Eclipse by the C/C++ Development Tools (CDT) project. It offers a plethora of features for the language, including a C/C++ editor, a debugging environment, content assist, makefile generator, and parser. If you are building an Eclipse-based IDE for an embedded processor, is it the right choice? Or are you better off starting from scratch with the base platform? That’s the question that I’ll be examining in this post.
With all the features that the CDT offers, already designed, implemented and tested, you might wonder why anybody would choose not to base an IDE for their embedded processor on it. It’s a no-brainer, right? Especially when you consider how much effort you’d have to spend to replicate even the most basic features it provides out of the box.
This is a deceptively tough decision, though, and a lot of it depends on what you want out of the IDE.
Do you want your IDE to be different?
The CDT offers a full-featured standard platform on which to build a C/C++ development environment. The key idea here is standard. When you choose to use the CDT, you are accepting all of the design choices that went into it, and limiting the range of possibilities for customization.
To be sure, there are ways that you can customize a CDT-based C/C++ environment. But the possibilities are much narrower when you base your environment on the CDT rather than the base platform.
When do you need it?
While choosing the CDT reduces the range of design choices, it also reduces the length of the todo list.
If you need to get a C/C++ development environment out the door quickly, the CDT can get you there. Most of the hard work has already been done by the CDT developers.
The time-to-market benefit is especially noticable if the processor you are targeting is already supported by the GNU tools, in which case there is very little work to do. I’ve heard of IDEs built in a couple weeks this this way.
The CDT is a huge piece of software. It solves problems that I never even knew existed. Out-of-the box, it sports its own disassembly view, code completion, and an extensive build system, among other things. However, in the course of building all these features, the CDT developers committed to a host of decisions about how it would work.
These decisions, though, might not coincide with what your end user expects or wants. It could be as superficial as their being more familiar with the look and behaviour of another development environment or as fundamental as the CDT not supporting some essential debugging feature.
At AMI Semiconductor, our digital signal processors are so resource-constrained that it only makes sense to program them in assembly (we don’t even offer a C compiler). A highly-tuned assembly programming environment, then, was essential for our customers, and something we found lacking in the CDT when we first considered it.
The do-it-yourself option is an expensive one. And in more ways than one. When you choose against the CDT, you end up devoting considerable resources to recreating features that already exist in the CDT, and in many cases falling short of their mark. What’s more, all that effort spend on re-inventing the wheel could have been spent tayloring the CDT to your processor.