CrossCore Embedded Studio: Analog Devices Gives Eclipse a Go

Analog Devices becomes the latest semiconductor manufacturer to standardize on the increasingly pervasive Eclipse open-source IDE (integrated development environment) and extensible plug-in system with the CrossCore Embedded Studio software suite for C++ and assembly language-based software development, which the company officially unveiled last month at the DESIGN East conference. Particularly attentive readers may recall that this isn't the first time we've heard about CCES (CrossCore Embedded Studio); Analog Devices "teased" news about it in conjunction with the BF60x dual-core Blackfin announcement back in March. And in fact, BDTI's software engineering team beta-tested multiple versions of CCES when developing the BF60x "dice counting" demo. But, as the IDE's name implies, it's now been revealed as supporting the majority of both ADI's existing SHARC and Blackfin DSPs, as well as all future products (Figure 1).

Figure 1. With CrossCore Embedded Studio, Analog Devices joins many of its competitors in transitioning from a fully in-house developed IDE to one based on the open-source Eclipse framework. CCES encompasses the core IDE, along with a debugger, compilers, assemblers, a linker, loader, system services and device drivers.

CCES is the heir apparent to ADI's VisualDSP++, which is more than a dozen years old. Analog Devices spokesperson Jack Buckley, Product Manager for Software and Tools Engineering in the company's Processor and DSP Group, was careful to point out that VisualDSP++ will continue to be sold, supported and updated for existing chips. VDSP++ (VisualDSP++) v3.5, for example, is recommended for ADSP-21xx-based designs, while VisualDSP++ 5.0 services TigerSHARC-based designs. However, all new and upcoming ADI devices, beginning with the BF60x Blackfin family, will be supported only by CCES.

In related news, Analog Devices is partnering with Micrium as the lead (but not necessarily the only long-term) CCES middleware plug-in provider. Per the agreement between the two companies, VDK, the ADI-developed VisualDSP++ Kernel, will be replaced by Micrium's µC/OS-III RTOS. Similarly, as part of the VDSP-to-CCES transition, ADI will migrate customers from in-house-developed USB and file system software stacks to Micrium's µC/USB and µC/FileSystem, as well as towards Micrium's LwIP TCP/IP stack.

Figure 2. Analog Devices is also phasing out internal development of its own operating system kernel, USB, TCP/IP, file system and other software stacks, transitioning to Eclipse plug-in-cognizant software products from partner Micrium.

The migration from VDSP++ to CCES delivers a number of benefits to both Analog Devices and its customers, according to the company. CCES's Eclipse foundation allows ADI to leverage work done by the open-source Eclipse community and focus its own efforts in areas where it can differentiate (specifically, on silicon design, along with the toolset's underlying compiler and debugger). The transition to Eclipse also allows the company to deliver many features that have long been requested by customers, such as a language-aware editor, and multi-core debugging support. And those customers also can now easily tap into a comprehensive ecosystem of Eclipse-cognizant third-party tool providers.

CCES dispenses with the VDSP++ floating license option, simplifying the model to two alternatives. A node-locked license is "tied" to a single computer. The corporate license, on the other hand, is germane to any computer on a particular corporate network, and is controlled by a common system-wide license file "seen" by all CCES installations on the LAN. "One-click" licensing directly from the IDE dispenses with the prior "clumsy" VDSP++ process of filling out Internet forms, waiting for email responses and entering validation codes.

One other advantage of an Eclipse-based IDE, according to Analog Devices, is that it provides "a familiar environment for users transitioning from competing products." Toolset commonality among silicon providers was specifically cited as a key benefit by Eric Gregori, senior software engineer at BDTI, who was one of the key developers of the "dice counting" demo code. Prior to joining BDTI, Eric worked for a number of years at Freescale Semiconductor and was closely involved in that company's earlier development tool migration from CodeWarrior to an Eclipse foundation.

"I am a big fan of Eclipse and Eclipse based tools," said Gregori after being briefed on CCES. To date, he has used Eclipse-based tools with Java and Android, when targeting ADI, Freescale, and TI ICs, and for C/C++ development on Linux. "What I like most about Eclipse-based tools is consistency," Gregori continues. "Once you become an expert with Eclipse, the ramp-up time for other flavors of Eclipse is very fast. For example, another processor supplier just moved to Eclipse for its tools. I was able to get up and running using the tool immediately. When I had to import files, or debug, or read registers, I knew exactly where to find this functionality in the IDE."

Shehrzad Qureshi, the other key BDTI engineer involved in beta-testing CCES in the process of developing the "dice counting" demo, is somewhat less enthusiastic about Eclipse-based toolsets. He notes as upsides that CCES and Texas Instruments' Eclipse-based CCS (Code Composer Studio) now look quite similar, and that CCS is now fully supported on Linux workstations. But he's struggled with numerous (albeit diminishing over time) bugs with multiple vendors' Eclipse-based IDEs.

Qureshi's biggest "beef" involves Eclipse's perceived slow performance, both in an absolute sense and relative to each vendor's prior-generation, non-Eclipse toolsets. Eclipse is "extremely sluggish, takes forever to connect to the target, and so on," he says. "For examples of a zippy IDE," Qureshi offers up for consideration Apple Xcode and Microsoft's Visual Studio 2008. And regarding the increasing commonality of various vendors' toolsets, Qureshi notes, "if the software development flow is identical, then "group-think" permeates the entire industry. Who's to say the way Eclipse does things is the correct or best way?"

Gregori addresses Qureshi's performance concerns in additional comments. "The Eclipse IDE is actually written in Java and requires a JRE (Java run-time environment to work). The better (i.e. least buggy, whether that be due to Eclipse or its Java foundation) implementations install a JRE that has been thoroughly tested with a specific version of Eclipse. Unfortunately, Java is a memory hog, so Eclipse-based IDE's are not very memory-efficient. This can result in slow operation for systems with a small amount of RAM."

Gregori also offers some advice for engineers preparing to migrate to an Eclipse-based IDE. "One of the things people find most confusing about Eclipse is the workspace, which works differently with Eclipse than with most IDEs. The workspace contains multiple projects that are not related; this can be a little confusing for people who are used to tools that work on a individual project basis (i.e. Visual Studio). An even more confusing aspect of the workspace is the separation of source code, metadata, and output data. Eclipse does not require that the source be in the workspace or the project. This is actually a very powerful aspect of Eclipse but it's also very unfamiliar to a lot of people."

Regarding workflow, Gregori opines, "Eclipse is a Java development tool that has been shoehorned into a C/C++ IDE. For people without Java programming experience, the Eclipse flow would make no sense. For example,  Eclipse does syntax testing in real-time while you are editing. This works very well with a language like Java, it's incredibly confusing with a language like C or C++. The better Eclipse-based tool implementations disable this feature by default to avoid confusion. Also, due to its Java roots, Eclipse defaults to auto-build. This makes no sense in a C/C++ IDE. Again, the better Eclipse implementations disable this by default."

The base CCES configuration costs $995, encompasses a single node-locked license, comprehends both Blackfin and SHARC architectures, and includes lifetime technical support and a year's worth of upgrades (followed by an unspecified-cost annual maintenance fee). Also left unspecified is the cost of the license upgrade path from VDSP++ to CCES, although ADI's documentation promises that it will be "reasonable." Analog Devices touts CCES' pricing flexibility in comparison to the VDSP++ precursor, noting that users can now choose only the components that they need. However, the company is reticent to quote pricing of the various Micrium plug-ins, instead encouraging customers to directly contact its partner for software cost specifics.

When asked about Micrium pricing, the company's founder, President and CEO Jean Labrosse provided the following comments:

I can provide list prices for our products, but I can't provide Analog Devices-specific pricing. Our products are licensed on a per-end product basis. For example, if an end product requires our uC/OS-III kernel, the license cost is $7500, and this is a fixed fee irrespective of the number of units manufactured for the end product. We have other models based on whether the end-product manufacturer produces multiple products in the same family of products, whether they always use a specific CPU brand, etc.

Here are some ballpark prices for our other products:

To download a free 90-day trial copy of CCES, visit the product page on Analog Devices' website. There, you'll also find a suite of self-paced, online video tutorials on topics such as:

• Tools and training overview
• Navigating through the IDE
• Creating, configuring, and building projects
• Debugging on a hardware target
• System services differences, and
• Real-time kernel differences

And for direct interaction with other CCES users, ADI encourages you to join the CCES design community on the EngineerZone area of the companys website.

While Analog Devices' eventual migration to Eclipse was largely a foregone conclusion, considering the precursor actions of many of its competitors and the overall industry trends compelling such a move, the newness of (and so-far incomplete specifics of) the company's plan raise many questions. Will Micrium do at least as good a job as ADI, if not better, of developing and maintaining various SHARC- and BlackFin-targeted software packages? How consistently will ADI end up maintaining VDSP++ for existing customers on existing devices? How difficult will the transition from VDSP++ to CCES be for those customers, in the context of new designs and migrations to new DSPs? And given the variability and uncertainty of Micrium's pricing, will the CCES migration result in a cost savings or incremental expense? Only time will tell.