For hints, tricks and ideas about better ways to build embedded systems, subscribe to The Embedded Muse, a free biweekly e-newsletter. No hype, just down to earth embedded talk. 23,000 other engineers subscribe. It takes just a few seconds (all we need is your email address, which is shared with absolutely no one) to subscribe to the Embedded Muse.

Data Management

Published 1/08/2007

When I heard that Encirq Corporation (http://www.encirq.com/) was peddling data management software for embedded systems I rolled my eyes. "Just what I need," I reflected, "SQL for 8051s."

Recently, though, Encirq's Eugene Buechele gave me a different perspective.

"Data management" does not necessarily mean "database." It includes all sorts of data manipulation issues, from managing lists, arrays, indexes, buffers and all the stuff we struggle with every day. Eugene claims that 55% of most embedded apps are concerned with these sorts of activities.

Though I don't know how accurate that statement is, we sure do write a lot of lines of code for sucking data in from networks and peripherals, and for storing and manipulating it. Consider the non-embedded space: the bane of security seems to be buffer overflows, and the nuisance of Windows stems in no small part from memory leaks. Would that PC folks used a tool to manage their allocations! Or at least to flag a forgotten free().

He also claims the 89% of "serious" bugs are in the data-handling part of our programs. So it would seem logical that developers would seek out some canned solution to data woes; a product that makes it easier to write this 55% of our code, reliably.

Encirq's product compiles data-manipulation commands written in a tuned version of PL/SQL into C. A small runtime library provides support services. Many operations look like database manipulation, but as the product is designed for the embedded world implementation is based on streams. and is much, much faster than standard database accesses. But is there an actual database? Where is the data stored?

The answer seems to be: who cares? Let the tool take care of these implementation details, just as we rely on malloc() to find chunks of heap.

If you're building an MP3 player, to insert a song into a playlist the PL/SQL might look like "INSERT INTO playlist("Rocky Racoon", "The White Album", "The Beatles")" instead of a few hundred lines of complicated C code. It's a very high level of abstraction that delegates all the data tedium to the tools.

Which sounds pretty good to me.

I'm still trying to get my hands around the technology and applications, but am fascinated by the different approach to thinking about the way we build firmware. What do you think? How much effort goes into dealing with all the various forms of data in your systems?