For most of my life I have used graphics as a way to model a problem facing me and working through, if not to a solution, to an organized structure that allows me to see a pattern that in turn leads me to an answer. It is something I used in elementary and high school to solve algebra and trigonometry problems and in college in virtually every subject: statistics, physics, biology, mathematics and engineering. As a writer I often create tree structures to sort through ideas and topics as I work on finding the best way to write an article. And on the World Wide Web – which at best is like a book with an index but no table of contents – I use such techniques to bring order out of chaos.
In most of my life as a technical journalist – and sometimes programmer and hardware DIYer – I have been surrounded by embedded hardware and software engineers I worked with who developed – as I did – their own personal ways of modeling the design problem facing them: component placement on a printed circuit board, gate-level blocks on an FPGA, software code structure on a microprocessor, or transistor level logic on an ASIC or system on chip.
Many of these techniques have become formalized, first in the form of simple state machine diagrams, and now with model-based development tools such as Simulink and Labview, and model-driven frameworks such as the unified modeling language (UML), the open source Quantum Platform and a variety of proprietary and domain-specific tools. .
Surprisingly, while most engineers have their own personal and often idiosyncratic ways of modeling problems, they’ve resisted these more sophisticated and standardized approaches and stuck to hands-on C programming. This has been possible in a world of world of 8-, 16-, and even some 32-bit dedicated, limited resource designs where code sizes and the complexity of the designs were modest in size and where interactions with external devices were limited.
But that is no more, according to Michael Barr, who will be the keynote speaker at the 2014 ESC/EELive! March 31 to April 4. He points out in “Trends in Embedded Software, ” that the trend is away from hands-on programming and toward more model-driven auto-generated code.
“C is simply not up to the task of building systems requiring over a million lines of code,” he writes. “Nonetheless, million-plus line-of-code systems is where the demanded complexity of embedded software has been driving our programs for some time. Something has to give on complexity. Thus I predict that tools that are able to reliably generate those millions of lines of C code automatically for us, based on system specifications, will ultimately take over.”
This is an idea many embedded developers still do not like. But as Barr points out, “I guarantee that once you program for a state machine framework, you'll see the benefits of the overall structure and be ready to move up a level in programming efficiency.”
If you would like to get up to speed on some of the various model-driven development languages and their auto-code generation tools, register to attend 2014 ESC/EELive! There, Stephen Mellor and Bruce Douglass, two of the pioneers in the application of modeling languages and tools to embedded design, will be part of two wide-ranging conference tracks: “Software Architecture, Development and Design,” and “Embedded Systems Engineering.” Classes that I can recommend and which I plan to attend include:
Both Mellor and Douglass have been contributors to Embedded.com, where we regularly cover the evolution and use of such modeling tools. To read more on this topic, check out theUML article archive on Embedded.com, as well as this week's Tech Focus newsletter on “ Taking on nextgen design challenges with modeling . ” Among the many contributions, several that are my Editor's Top Picks i nclude:
State machine shortcuts
From UML to embedded system: Is it possible?
Effective UML mapping for modeling state machines
Using model-driven development for agile embedded apps
Model-based testing of a state-machine-based PLC design
I would like to hear from you and see your ideas about contributing on this topic to Embedded.com. Do you totally reject the use of such tools in your work? Why? What tools are you using, not using and why? What is needed to improve their capabilities? Are the days of hands-on embedded C programming dead? Or do you agree with Michael Barr who expects “…there to be continued demand for those of us with the skills and interest to fine tune the performance of the generated code or write device drivers to integrate it more closely to the hardware.”:
Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to , or call 928-525-9087.