How We See Embedded Processing

The constant thread that runs through my days as an embedded-processor-applications manager is finding new, effective ways for our customers to reduce time to market. It's no secret that design cycles continue to shrink (almost as fast as processor ASPs!), and tools that ease system design can be a real differentiator when it comes time to choose a processor family.

Almost all developers will use some tools, often in the form of C/C++ and optimized assembly code libraries, to offload much of the control and signal-processing work. The open-source environment (uClinux, for example), with its huge base of device drivers and processing algorithms, provides another path to reducing programming complexity and speeding time to market.

Recently, graphical-based development environments (e.g., LabVIEW or Simulink) have become a powerful way to jump-start embedded designs. Like the alternatives I just mentioned, these also build on a software driver and signal-analysis code base, but the programming focus is on visual system design. Lower-level functions are abstracted up multiple levels, setting the stage for very effective, rapid prototype development.

Now, these visual environments have been around for a long time, but they were mainly PC-based. The process was to validate algorithms on the PC before trying them out in the embedded realm. But the generated code was generally not efficient enough to run directly on the embedded processor, and usually necessitated a targeted code rewrite. Also, there wasn't much integration with I/O peripherals, so real-time data streaming had to be accomplished separately. What's more, it was often painful to navigate between different tool sets—the graphical environment and the native embedded-processor environment.

Today, these problems have been substantially addressed for embedded designers, and this leads to some pretty interesting outcomes. For instance, now a new class of programmers can develop with embedded systems—those more scientifically inclined, who are used to the intuitive flows of system control diagrams and not steeped in embedded technology. For a wide range of applications, there's no need to become a resident expert on a processor's architecture or peripheral set to produce a practical and well-behaved design.

On the other hand, even experienced programmers should have no trouble adapting to the graphical structure, since it pretty much mirrors (conceptually) how developers design algorithms. When making changes to satisfy a particular application, almost all of the modifications can be made at the graphical object level (e.g. filter lengths, matching pattern characteristics, etc.) These changes propagate automatically to the generated C code running "under the hood."

Also, don't overlook the fact that many of these graphical tools are also very useful for manufacturing test, so integrating this functionality with the ability to program actual silicon can substantially improve backend production flows.

For more information on graphical design tools for embedded systems, check out the LabVIEW Embedded Module. There is also an online training module that you can use to get started.

Good luck!

—David Katz, Analog Devices