In a recent blog on Embedded.com titled “What is more important than a processor?” Jim Turley, former editor-in-chief of Embedded Systems Design Magazine and now chief consultant at Silicon Insider, raised the issue of what the most important building block is in any embedded design. He reported the results of a survey of developers he conducted. He writes that his assumption going in was that it was, of course, going to be the processor. He was surprised that it turned out instead to be development tools. Programmers are like carpenters, he writes:
“Change their tools and you've abandoned the hard-fought experience that makes them so valuable. Good managers know this and don't try to force different development toolchains on their staff. Let the developers use what they want to use, and they'll be happier, more productive, and commit fewer mistakes. “
As he notes, most major – and many of the minor – processor vendors have done a good job making sure that they offer a wide range of development tools, both open source or proprietary, to give their hardware the best chance of being used. So you should not be having any more development tool problems, right?
Not so fast.
Things are changing rapidly in embedded systems design and picking the right development tools can be a can of worms. (For some guidelines on what route to take, be sure to check out the resources gathered in this week’s Tech Focus Newsletter on “Making the right choices in embedded software development.“ ) The issues involved break down into four key areas.
First of all, you have to decide which is the appropriate parallel and concurrent programming language environment for doing code development on next generation multiprocessor-based designs. In the middle of the last decade, it was assumed that developers would have to shift from the well-understood sequential procedural programming languages such as C and C++ to some programming environment that was concurrent in nature and used alternative declarative programming languages.
But embedded developers have decided for now to stick with sequential C programing and choose tools that allow them to do development in the highly parallel multicore environment. Embedded.com's Archive of multicore development articles , white papers, and blogs are valuable if you need help in this area. A good place to start are the guidelines from the MCA, which are covered in “Introduction to the Multicore Programming Practices Guide,” by Rob Oshana, David Stewart, and Max Domeika, Working Group Chairs, Multicore Association.
Second, what tool framework do you use that also allows you to develop across a range of application environments, each of which have their own software performance metrics, for low power, performance, reliability, security, and safety? The best guidelines by which to sort through your options is “Software performance engineering for embedded systems ,” a three part series by Rob Oshana.
Third, as embedded systems become more connected, security will be of primary concern in almost any design, no matter what the target market. So what development tool environment do you use? Do you depend the security requirements developed by specific market segments or do you try to define one that is flexible enough for all of them? I recommend reading “Think ahead about coding standards,” by Chris Tapp of LDRA. In addition, there are a range of design articles gathered in our online collection of security articles that you might find useful.
Fourth, complicating the development tool question is the mess that the computer industry has created for itself with its enthusiasm for the “Internet of Thing s. ” Still rather undefined and amorphous, the only commonality in all discussions of this topic is the assumption of complete TCP/IP connectivity of devices, with little consideration given either to the degree of IP-connectivity or its appropriate use.
Many of the basic software building blocks and protocols are the same as have been used by embedded developers in application environments such as wireless Zigbee, Bluetooth, Wireless Hart, and a number of device connectivity options, both IP-enabled and not. Most use protocols embedded developers have been using since the introduction of IPv6 more than ten years ago and its 6LoWPAN wireless sensors protocol extension five years ago.
The problem here will come down to what development tool environment you will need. There are a flood of such tool frameworks being proposed: from hardware vendors such as Freescale, Intel, Qualcomm, and TI; from backbone Internet router providers such as Cisco Systems; major software developers such as IBM; and some end user giants in specific industries, such as General Electric in industrial computing.
So far, most of these development tools environments make assumptions more appropriate to their target customer and user bases and to design needs other than hardcore embedded apps. To date, the only company that has done a good job in defining the development tool needs of different segments of the IoT space is Echelon, a mainstay in industrial networking since the early 1990s. Read “Building an IoT framework for Industrial control , ” a two part series by Echelon’s Robert Dolan. Another useful resource is “Finding the right Internet of Things development framework.”
Beyond these broad development tool issues, engineering managers have another set of sometimes intractable issues relating to their developers’ varying levels of tool expertise, experience, and education.: how you mesh them altogether in a common development environment that gets the best out of them, working individually or as a team.
These topics have been of ongoing interest on Embedded.com for most of its 20 plus years of existence and that's not likely to change soon. I look forward to your contributions, either here on line as a comment or as a blog or design article you write. Give me a call or email and we can work together to create something you will be proud to share with the embedded design community.
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.