 |
|
Extending Eclipse CDT for Embedded Development "Will the real CDT please stand up? " Embedded developers unfamiliar with the Eclipse C/C++ Development Tools (CDT) may feel tempted to ask that question. On the one hand, the CDT is the development platform for many embedded projects, from mobile handset applications to massive Internet routers. It also forms the basis of integrated development environments (IDEs) from several RTOS vendors. Nevertheless, anyone who downloads the "vanilla" CDT from www.eclipse.org will soon discover that it doesn?t support remote target debugging, boot file creation, or other features needed for embedded development. It doesn?t even include a compiler. Why then has the CDT become so popular in embedded design? In the past, most development environments for embedded developers were proprietary affairs, with little or no integration between tools and little support for third-party tools. The CDT, by comparison, uses open, well-documented extension points and application programming interfaces (APIs) that make it far easier to integrate both new and legacy tools into a single, extensible development environment. Meanwhile, the Eclipse platform has become a de facto standard for tool integration, giving embedded developers unprecedented access to tools for UML modeling, source code static analysis, requirements management, and configuration management. Still, support for such tools is only part of the story. Most embedded developers work in a cross-development environment, where code is developed on a workstation, but then downloaded, debugged, and tested on a remote embedded target. By default, the CDT lacks support for such an environment; rather, it provides a comprehensive toolset for self-hosted development, in which host and target are virtually the same (for example, using a Linux workstation to create applications for Linux desktops). So the question remains about the CDT’s popularity. In fact, it is primarily the result of the efforts of RTOS companies and tools vendors, who have extended the CDT with an arsenal of value-added, cross-development tools. For instance, QNX Software Systems has developed the QNX Momentics IDE, a CDT-based environment that provides a system profiler for high-performance kernel-event tracing, an application profiler for process-level performance analysis, a memory analysis tool for pinpointing memory errors and leaks, a code coverage tool for objective measurement of test success, a debugger for remote target debugging, and a system builder for creating embedded boot images. These target-focused tools work with the CDT’s standard toolset, which includes a code editor, debugger, project navigator, search engine, build system, and GNU C/C++ support. To answer the opening question, the real CDT is most of all an engine for innovation. Until its arrival, there was surprisingly little innovation in C/C++ tooling, for the simple reason that tools and RTOS vendors were all reinventing and maintaining the same wheel. Everyone had his or her own IDE, editor, debugger, and so on. Eclipse and the CDT, by providing a comprehensive and extensible tooling infrastructure, free companies of this burden and allow them to focus higher up the food chain, on innovative, value-added tools. The real beneficiaries are embedded developers, who now have a richer supply of tools for debugging, testing, and optimizing their target systems. Bill Graham is a senior tools product line manager at QNX Software Systems. |