Rick Gentile

Faster Development Goes Graphical
May 2006

Finding ways for customers to reduce time to market is a constant theme for silicon providers in the embedded market space. These monthly columns have discussed many different approaches to giving developers a head start, including the open source movement and various third-party offerings. Such offerings also let you take advantage of proven code that is already written. The payback can be remarkable: I have seen as much as six to nine months dropped from the overall schedule, depending on the application.

This month I would like to explore a different sort of enabling technology, graphical system development.

Let's start with some background. In most of today's embedded processing applications, both the control and real-time programming is done through a combination of C/C++ and (to some extent) libraries of optimized assembly. On the open source front, once you build the lower level driver code for a given architecture, you "inherit" all of the other code that exists on top of kernel. When a third party develops a solution, such as a VoIP application, the basics are done before you begin. You then complete the last, smaller subset of work.

Graphical system design also builds on a code base of drivers but the programming model shifts. By programming at the system level, the lower-level functions are abstracted up multiple levels. Working in a graphical editor lets you start by building an application at a block-diagram level.

In the past, graphical system development was great for prototyping on a PC or workstation because you could validate that your algorithm works before transferring it to an embedded processor. Graphical programming was also a natural for controlling industrial flows and instrumentation. Early on, however, graphical editors did not generate code efficient enough to run on an embedded processor out of the box. In addition, the approach did not handle the integration with peripherals that is necessary to support streaming of data in and out of a system in real time.

Recently graphical development has reached important milestones that make it much more valuable for developing embedded applications:

• Generating efficient code that runs on the target processor
• Seamlessly integrating peripheral sets
• Being able to transition between the graphical tool set and the native tool set for the processor

The first two capabilities allow a new set of programmers to develop on an embedded processor. For example, engineers with more of a scientific background can program and debug "data flow programming" in an intuitive manner. Getting started doesn't require becoming an expert on either specific architectural features or how a peripheral works. Of course, seasoned programmers appreciate not having to develop applications from scratch.

The third capability is significant because while abstracting the architecture and peripherals is beneficial, you don't want to block developers from direct access to the embedded processor. Being able to move between tool sets is required for further optimization and system debug and validation.

Analog Devices announced an initiative with National Instruments last year along these lines. The NI LabVIEW Embedded Module for ADI Blackfin Processors provides a comprehensive graphical development approach for embedded designers. The goal was to seamlessly integrate NI LabVIEW and ADI VisualDSP++. Jointly developed by ADI and NI, this development environment really brings together the strengths of both companies.

From the National Instruments perspective, this effort extends LabVIEW graphical system design to embedded development. From the Analog Devices perspective, LabVIEW Embedded provides Blackfin developers with hundreds of mathematics and signal processing functions on top of an integrated I/O library.

Using a common tool for traditional design and manufacturing test, while programming silicon at the same time, invites a substantial reduction in time to market. Drivers for common components, such as ADCs, DACs, and codecs are easily programmed using a common API architecture called System Services. This reduces all the bit-banging often required just to blink LEDs.

The product builds on top of our real-time kernel (VDK) that we provide with VisualDSP++. NI uses a set of Virtual Instruments, or VI's, to create the interface into the Blackfin architecture.

I have three favorite application examples that exist today: a vision-based system connected to a CMOS sensor, an audio example, and the Handy Board (developed by Dr. Fred Martin at UMass Lowell). In each of these applications, the graphical code was developed using LabVIEW Embedded. When customers wanted to make changes to match their applications, almost all of the modifications were made at the VI level (filter lengths, matching pattern characteristics, etc.) These changes get propagated automatically to the generated C code running "under the hood."

Graphical system design is well worth considering when you need to put your development effort on a fast track. You can take a look at training for LabVIEW Embedded, get a test drive, and learn more at National Instruments' website.

Rick Gentile leads the Blackfin DSP Applications Group at Analog Devices. He welcomes ideas for his columns about issues that face embedded processing and DSP applications engineers.