Career opportunities in embedded software
This article first appeared in Builder AU Magazine.
Writing software designed to be embedded in an appliance, phone, or some other real-world device is a growth area, but has its own set of challenges.
It is getting harder and harder to avoid computers these days. The clock radio that wakes you up in the morning probably contains a computer, along with the microwave that warms your breakfast, the burglar alarm you set as you leave the house, the ticket reading machine at the train station, the lift that takes you into your office and the security card reader at its door.
By the time you get home to pick up the messages on your digital answering machine, flop into your couch to watch a computer-powered DVD through your computer-powered TV, computers will have dominated your day without you ever noticing it.
For many developers this extraordinary prevalence of computers is also beginning to intrude into their conscious thoughts. Static wages, a glut of skilled coders and the often-dull nature of much enterprise development has many wondering if their current skills would let them take on the new challenge of programming the embedded computers that surround us.
| "Patching is hard when the embedded devices you programmed are installed down mines in Siberia and Western Australia" |
The process of software development should also be familiar. “At a really high level the steps involved in a project should be the same,” says Malcolm Groves, Borland’s Regional Product Director for the Asia Pacific. “You gather business requirements, analyze how to translate them into software, run a testing phase and then do it all again.”
Real time considerations
Yet these familiar coding and project management skills must adapt to some new and interesting challenges, foremost among which is the realtime capabilities of many embedded operating systems. “Embedded operating systems need very high reliability,” says Daya Nadamuni, a Principal Analyst with Gartner. “They must always be predictable: the system should guarantee you will get a response in a certain amount of time.”
The qualities are important because embedded systems are often deployed in environments where milliseconds can literally be the difference between life and death. “A real time OS can never fail,” Nadamuni says. “For things like avionics controls the result of failure is catastrophic.”
Borland’s Grove recalls a project for embedded systems to control a freight company’s conveyor belts and package-sorting systems where the stakes were lower, but requirements just as sensitive.
“We had microseconds between when a barcode on a package was scanned and the embedded device issued the instruction about which chute it should go down,” he says. “If you are writing that kind of software you need to know the operating system will send the message to the conveyor belt in time, because if it does not you have a problem.”
Hardware-software meldingProgrammers for embedded systems must come to grips with these issues, and the fact that addressing them requires work to understand how embedded OSes interface with the hardware in an embedded device.
“In embedded systems development there is quite a significant blurring of the line--you could ague there is no line--between hardware and software,” says Daryl Wilding-McBride, Practice Lead for Enterprise Services at Object Consulting, who has coded extensively in the embedded and enterprise worlds. “With embedded systems you are much ‘closer to the metal’. You are dealing with the pins on the chips and clock cycles and interrupts.”
The technical parameters for these factors vary very highly between different embedded devices, which employ a vast range of processors and components that, according to Davyd Norris of IBM Rational, are a very significant barrier to mainstream developers hoping to cross over into the embedded world.
“The interesting thing about embedded development is the huge spread [of devices],” he says. “Embedded programmers tend to have highly developed but narrow skills specialised in specific architectures and microcontrollers.” That need to specialise in different architectures – the venerable Z80 and Intel 6800 CPUs are still popular in embedded devices – has meant that many of today’s embedded developers have a background in hardware design or engineering.
“An embedded developer used to be a low level programmer, often an older person brought up with assembler and C and their knowledge of the OS and the device is very tightly coupled,” says Jason Tolley of Melbourne embedded development specialists ROK Technology.
While this trend often made for very good code, it also made for unwelcome complexity. Different architectures often demanded different development tools, sometimes with unique characteristics. Organisations developing for several different architectures could find themselves employing programmers whose skills were not suited to projects beyond their expertise, while also being asked to maintain expensive single-platform tools.
Those tools and people will remain for real-time projects, as their extreme demands cannot be compromised.
| "A real time OS can never fail. For things like avionics controls the result of failure is catastrophic." |
However, the big move in embedded systems is now towards more generic development tools capable of targeting more types of hardware to simplify development. Borland’s approach has been to create tools that integrate the packages for developing with specific devices under one umbrella IDE. Microsoft’s .NET Compact Framework and Sun’s Java 2 Mobile Edition (J2ME) represent the apex of that effort, as both allow developers to use everyday enterprise-class development environments to target diverse devices well beyond the desktop and promise to shift embedded development out of the hands of silver-haired veterans and into the mainstream.
“The .Net compact framework and the SDK architecture are similar between Windows XP and Windows XP embedded,” Tolley says. “You don’t need to know the intricacies of the hardware. The learning curve is not that great,” with the need to pause and reflect on the kind of code needed to work with the small memories and CPU capacities of embedded devices the prime consideration for those developers that do make the move.
The shift to embedded work will also require extra focus on certain aspects of software development. “The biggest challenge is debugging,” Tolley says, as it needs to be extremely rigorous. “There are emulators but you still need to deploy [on an actual device] and the mindset around the process is different to the desktop environment,” especially when the embedded device is intended for use in a car and a system crash at 100 km/h is likely to cause crashes of a much more serious nature.
A good debugging process is also important because many embedded devices are infrequently connected or operate in remote locations.
“Patching is hard when the embedded devices you programmed are installed down mines in Siberia and West Australia,” says Borland’s Groves. “How often have you asked if the software on the set-top box is up to date? On the desktop Windows Update goes off and does it for you. It is very possible to cross over because the high-level steps are similar, but you have a whole bunch of new things to learn and to be successful you need to do your homework. It is not like going from .NET to J2EE.”
In addition, even though new tools hide much complexity, some of that homework will be on hardware, as many embedded devices interface with obscure peripherals or input devices.
“Even on an embedded PC architecture certain tasks are easier but the fundamental problems are that you still need to interact with the outside world in ways that are foreign to most commercial developers,” says IBM Rational’s Norris. “The fundamental problem is still input/output,” and would-be developers must tackle it to succeed.
Another, more welcome, problem is that few programmers have are willing to understand issues like I/O, creating a shortage of programmers with the skills to embark on embedded projects. This shortage has already seen ROK’s Tolley initiate a relationship with a local tertiary institution to encourage undergraduates to study embedded software development and adopt it as a career.
For developers looking for a technical challenge, a change of career direction or the chance of a fattened pay packet, embedding yourself in embedded computers therefore seems like a very sound idea indeed.
Meet the playersThe embedded development world has some players most enterprise developers may never have encountered on the desktop. Here’s a guide to some of the most important players.
1. Wind River Systems
Wind River Systems is the world’s largest embedded systems software company. The US-based company’s VxWorks operating system is enormously popular and the company offers a vast range of tools to put it to work. NASA’s Pathfinder probe used the company’s wares, which are also available in versions tailored to various vertical industries.
www.windriver.com
2. MontaVista Software
MontaVista Linux is a version of the open source OS tailored to the needs of embedded developers. Available in “Professional,” “Carrier-grade,” and “Consumer Electronics” editions, the OS is accompanied by an IDE and other development tools. Gartner rates MontaVista the embedded Linux leader.
www.mvista.com
3. QNX
QNX’s Neutrino realtime operating system offers a true microkernel POSIX support and even symmetrical multiprocessing. The company aims its OS and accompanying Momentics development tools at automotive, medical, communications, defense, and control markets.
www.qnx.com.au
4. Green Hills Software
The well-regarded INTEGRITY realtime operating system is Green Hills Software’s lead offering, with the royalty-free Velocity microkernel also a more than useful tool. Its MULTI development tool offers coders the choice of C, C++, or FORTRAN.
www.ghs.com
5. Mentor graphics
Mentor’s products include software and hardware development tools, a combination it believes make it possible to develop embedded devices from the ground up faster than is possible when each is developed independently.
www.mentor.com
Choosing embedded software tools, such as assemblers, compilers, and linkers, can be quite daunting. Sometimes the decision is made for you; for instance, when there's only one tool-chain available, the semiconductor manufacturer sells it, and it costs a small fortune. You're forced to pay the big bucks and move on.
But how do you choose embedded tools when there are options?
My first rule is to buy the cheapest tools that work. I don't mean that you should skimp on tools; it's just that the most expensive tools aren't necessarily the best. Actually, it's been my experience that the more you pay for tools, the worse they are.
This surprisingly makes sense: Expensive tools are usually costly because a small user-base or a complacent vendor--or both--sustain them. That's a recipe for unreliability. (And guess who winds up finding the bugs?)
Count the users
I recently made the mistake of following this "cheap is best" advice
too blindly. I was tempted to replace a AUD$10,000+ (US$7,125) software tool-chain
(which wasn't fancy, except for the price) with some new alternative
development tools that cost a few hundred dollars. The new tools
promised to do the same job at a fraction of the price. At that price,
we could afford to have a copy for each developer, instead of having a
single tool tied to one PC.
I placed the order, the software arrived, and I duly put it through its paces. Several days later, I still couldn't persuade it to build a simple real-life project. The tool-chain was bug-ridden. The vendor fixed the bugs promptly but we found more--and so it continued. The low, up-front cost of a few hundred dollars was eclipsed by the cost of downtime we spent trying to get it to work. I gave up and returned to the mega-buck tools.
What happened? Though the tools were cheap, I overlooked (or chose to ignore) that the tools had very few existing users, just like some of the expensive counterparts. I was back to being a beta tester on someone else's project. I should have asked the vendor to supply references, i.e., some real users who could speak about their experiences with the tools.
Don't be afraid to ask for references (and follow up on them) if you find yourself in a similar situation.
Conclusion
Some companies get things right. Microchip is a case in point; it offers good tools at reasonable prices.
However, most semiconductor companies don't get it. I dislike paying a premium for their tools just for the privilege of being able to design their hardware into end products. I also object to paying even more for dongles and sub-standard, glossy-looking text editors, when all I need are reliable command-line tools at a reasonable price.
The logical solution is to use freeware or open source tools when possible. These tools are free, you get the source code, and the tools usually have many users.
Picking the right embedded tools can be a difficult process, so take your time. The wrong choice can hit your project hard where it hurts: in bugs and missed deadlines.
--By David Brenan