[Technology Report]
Tools Matter In Mixed-Processor Software Development
CPU/DSP application software is complex, but the right development tools make the problem manageable.
Mixed-processor systems are growing more common as standard system-on-a-chip (SoC) architectures, like the Texas Instruments (TI) OMAP, become available. OMAP combines a conventional ARM processor with a TI DSP.
Unfortunately, programming a DSP is much different from developing software for most general-purpose embedded processors, such as Arm's ARM, MIPS Technologies' MIPS, and the IBM/Motorola PowerPC. Developing applications for a mixed environment becomes difficult for programmers familiar with one computing platform or the other.
It's very common, though, notes Marc Brown, Rational Software's developer tech marketing manager. Developers now implement DSPs from TI and Motorola with conventional CPUs in a variety of areas, including portable devices, automotive, and communications environments.
Joseph Dubin, TI's OMAP tools product marketing manager, indicates that customers are using the standard OMAP chips (see "Standardized CPU/DSP Devices," p. 80) to add communication support to existing DSP applications, or adding more sophisticated signal processing to an existing controller application. Of course, new applications are being developed to take advantage of both parts of the OMAP chip.
Regardless of the particular CPU or DSPs involved in a project, there are a number of ways to develop software for these platforms (see the table). The first employs conventional tools, such as integrated development environments (IDEs), compilers, and operating systems that most developers are familiar with. This often means that different tool chains, languages, and OSs will be used for the CPU side and DSP side. But some products, like OSE's namesake OS, span processor architectures.
An alternative is to use an integrated solution designed for a specific CPU/DSP combination. TI's Code Composer Studio (CCS) is a notable example. These integrated solutions can take advantage of features and quirks of a specific platform, but they tend to target a limited number of platforms. For instance, CCS doesn't work with Motorola's StarCore and DSP line of processors.
The last methodology uses modeling tools, which can be divided into two categories. MatLab from Mathworks dominates the first group, while the second bunch are Universal Modeling Language (UML) tools, like I-Logix's Rhapsody, Rational's Rose, and Telelogic's Tau. Modeling tools allow problems and solutions to be abstracted, making development more independent from the target platform. This also simplifies migration to other platforms.
Normally, the modeling tools are used in conjunction with conventional or integrated tools. UML tools are often employed with MatLab because MatLab is better at modeling programmatic algorithms.
Conventional Development Tools: Give designers a challenge and they will bring all their expertise to bear. This typically includes programming expertise in a language like C or C++, OSs, and development tools. When attacking a CPU/DSP system, the language (regularly C or C++) may be the same for the two processors, while the OS and development tools usually change. These additional systems could take a significant amount of time to learn, dragging out the project.
OSE Systems and Quadros Systems offer the same OS kernel on DSP and general CPUs. Quadros Systems' RTXC Quadros actually comes in multiple configurations. Therefore, a developer can choose the level of OS complexity and functionality with the same interprocess communication features. This lets a developer pick a single-stack implementation that might be suitable for the DSP and support multiple CPUs. RTXC supports the Motorola StarCore and DSP56xxx, ARM, PowerPC, and ColdFire processors. RTXC works with many third-party tools, like Motorola/Metroworks' CodeWarrior, Green Hills Software's Multi, and Altium's Tasking EDE.
OSE has special versions of its OSE real-time OS for CPUs and DSPs. The OSE Soft Kernel for DSPs is a full-OSE kernel, significantly easing migration of some applications from one processor to another. The OSE Link Handler for DSPs matches a similar link handler for general CPUs.
Links can traverse multiple CPUs and even networks, so OSE's solution is very powerful in large systems, such as telephone switches. But this type of application can be complex to debug, making OSE Illuminator for DSPs a handy diagnostic tool. It's a set of plug-ins for debugging and monitoring, containing extensive third-party support that works with other OSE Illuminator tools.
One problem with rolling your own system is that the developer must contend with CPU/DSP interaction. Debugging environments for the two processors may be different, and there may not be any interaction between debuggers supporting each processor. That complicates the tracking down of synchronization-oriented problems.
It's great to choose your own platform and tools. Still, trading choices for a more integrated approach has advantages.
Reprints
