Like many of you who have been in embedded systems development for a while, I grew up professionally with the microprocessor and microcontroller. In the beginnings, we were in what the psychologist B.F. Skinner would call a “behavioral box,” an environment in which we were forced initially to be multilingual programmers in spite of ourselves.
For at least two decades after the invention of the microprocessor in the 1970s, there was no common language for programming them and we learned implicitly to consider programming languages as tools, just like hammers, saws, and screwdrivers each appropriate to the task at hand. It was easy to pick the appropriate tool because there was no common cross platform language.
With each new processor, there was always a new machine language to learn, a new register architecture to understand, and different ways of doing the same operations, dictated by the constraints of the hardware.
But working in that multilingual environment, there were enough similarities – and differences – such that what you learned about a previous machine language and architecture was of some help in the new task on the new processor.
But that did not make it THAT much easier. And it did not prevent those of us trapped in the environment of complex instruction set (CISC) architecture-based MCUs from looking with envy at the cross platform capabilities of mainframe, minicomputer and then still fledgling servers.
They were all based on essentially the same reduced instruction set architecture. This allowed the development of a set of common high level programming languages – C language and its C++ object oriented extension – that allowed the writing of cross platform code that only needed to be compiled into an optimized form to operate on each RISC implementation.
Since the shift from CISC to RISC-based architectures in single chip MCUs and MPUs in the late 1980s and early 90s, most of embedded software development has been in C or C++ (and very carefully, with Java), with only occasional departures, dictated by safety and security, into other languages.
Even then, rather than look at alternative programming languages, the effort has been to make C and C++ do what they are not naturally designed to do. At one extreme there are developers such as Thomas Honold who simply made his own ad hoc modifications to how he wrote C to make it safer and more secure. At the other extreme are the developers of the MISRA C/C++ standards that specifically exclude those operations that make it risky to use.
But – as Jack Ganssle’s continually reminds us in such blogs as “Expectations”, “Software for dependable systems”, and “Languages” – maybe the ubiquity of microcontrollers and microprocessors into all aspects of our lives makes literally every embedded application one in which safety and security must be at the top of the agenda.
This is more so, given the ubiquitous connectivity of every embedded application and the avenues that opens up to hacking and even un-anticipated operational environments that the programmer did not consider in the original design.
Maybe it is time to go back to the multilingual mind set in which embedded programmers think about computer languages as tools to accomplish tasks rather than religions to remain faithful to no matter what the situation. Greg Gicca in “Students need to learn multiple programming languages.” perhaps captured this mindset best.
“Understanding just a single language promotes solutions that only approach a problem from a single perspective,” he writes. “Knowing multiple languages allows the problem to be looked at from a variety of perspectives so that multiple solutions can be compared and the most natural solution for the problem can be selected.”
With the introduction recently of Ada 2012, I have been determined to bring programming multilingualism back into my life and have been working on educating myself about the new capabilities and enhancements that have been incorporated into the language to make embedded development easier.
But it is Stuart Matthews recent blog included in this week’s Tech Focus Newsletter that did a lot to convince me that Ada’s SPARK embedded programming subset might be the best way to go. Also included in the newsletter are several of Jack Ganssle’s blogs on both Ada and SPARK, as well as a two part series on the language.
There are also a variety of web locations to go to learn more about SPARK, including videos and webinars and technical papers. Also helpful are such sites as ADA Europe, the ACM’s SIG/Ada site and the SPARK User Group.
And with the soon to be introduction of SPARK 2014, there is likely to be more resources available. I would like to hear from you, pro and con about SPARK/Ada versus other programming approaches, what resources you have found and how useful you think languages like SPARK will be – or not – in embedded software development.
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.