Break Points
What makes embedded different?
Jack Ganssle
7/26/2009 12:00 AM EDT
Pediatricians treat children. Gerontologists work with the aging. Both practice medicine, but their skills are very different.
The mechanic at the Toyota dealership is probably clueless little about GM's cars, while a motorcycle repairman knows every nuance of BMW's bikes, but no doubt can't grok a 745i.
The Verizon FiOS dude can splice fiber, but knows nothing of Comcast's cable distribution system.
It's easy to draw pretty clear lines between the skills and duties of many seemingly close occupations. But it's increasingly hard to narrow what constitutes embedded work from other forms of programming.
Why do you read Embedded Systems Design? Presumably you build, or are interested in, embedded systems. But what characteristic defines this field? How are our skills different from those used by, say, a developer at Microsoft creating the next generation of spreadsheets?
In reading "Building Embedded Linux Systems" (2008, O'Reilly, Sebastopol, CA, by Karim Yaghmour, Jon Masters, Gilad Ben-Yossef and Phillipe Gerum – what a wonderful-sounding mash of international names!) I was struck by how much of the book has nothing to do with embedded systems. It's a nice work, to be sure, but most of the "embedded" content is in the final three chapters on real-time aspects of Linux. And there's little about actual timing one can expect when tossing Linux into a real-time system.
According to "Snapshot of the embedded Linux market -- May, 2006" By LinuxDevices.com, which is 2006 data, 47% of respondents have used Linux in their embedded systems. That number is probably overstated due to the self-selecting nature of those responding to linuxdevices.com, but a survey I conducted the same year showed that 35% of the systems readers built included either Linux or some flavor of Windows. Surely those numbers have increased in the last three years. They do paint a picture that suggests an awful lot of "embedded" applications are running desktop OSes.
Many engineers scoff at the use of a desktop OS in embedded applications. Yet this sort of operating system makes sense in a lot of circumstances. Managers tell me they like the rich APIs these provide, and really appreciate the deep pool of programmers who are familiar with them. The Windows development environment has a much wider following than, say, that of VxWorks. In flush times bosses can hire plenty of Windows people, at more attractive rates, than deeply embedded folks. Processors are cheap; people aren't, so it's common to see systems structured around a hefty 32 bitter running a desktop OS, with one or more smaller CPUs doing the fast stuff and the deep bit twiddling.
|
|
|
|
|
robert.berger
7/27/2009 2:43 AM EDT
Hi Jack,
Sometimes you don't have another choice but to use Linux or Windows, since nothing else is supported by chip-set manufacturers like with set-top boxes. I had to make a switch from VxWorks to Linux, which was rather painful years ago. In the meantime I train people in Embedded Linux and am surprised by the things they don't know or don't even care to know about like bootloader, profiling, real-time and interprocess communication. (After the training they do have some basic understanding of those things, I hope).
Regards,
Robert
--
Robert Berger
Embedded Software Specialist
Reliable Embedded Systems
Consulting Training Engineering
Tel.: (+30) 697 593 3428
Fax.:(+30) 210 684 7881
URL: http://www.reliableembeddedsystems.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sign in to Reply
gby
7/27/2009 3:11 AM EDT
Hi Jack,
I am Gilad Ben-Yossef, one of those "mash of international names" :-) Thank you for your kind words about the book.
Reading your article brought a smile to my face, because you seemed to have stumbled upon a dirty little secret - there is no such thing as "Embedded Linux".
Indeed, use of Linux in embedded systems often requires attention to power consumption, meddling with low level hardware details such as interrupt handlers and operating within rigid real time constraints.
None of these however, is in any way unique to the embedded field however: power draw is an issue when building large computer clusters, engineers write device drivers for server and desktop peripheral devices, finance and trading systems have as rigid as real time constraints as any encountered in the embedded field.
So you see, it is no accident that "Building Embedded Linux Systems" is not really about embedded systems but rather more about how to attain those design goals that happen to be common in embedded systems with Linux.
What is special about Linux is that it is the first OS (OK, maybe second if you count BSD :-) that spans all the way from cell phone to super clusters. Linux is NOT an embeded operating system, it is one of the few truly general purpose OS, where general purpose is not limited to desktop.
The book, of course, reflects this.
Gilad Ben-Yossef
Codefidence Ltd.
http://codefidence.com
Sign in to Reply
krwada
7/27/2009 12:59 PM EDT
Hello Jack
I can say this with certainty ... All computing systems are embedded The real time constraints lie primarily within the application. As I have stated before; if you include all those stand-alone desktop PC's that are supervising some test, or other 'shop floor' application, then the Microsoft Windows is still the King. However, I still see Linux as rising in pre-eminence in the not-to-distant future.
Sign in to Reply
B Kockoth
7/29/2009 3:57 AM EDT
Hope is not futile, Jack.
Given the lack of work in computer-related industries in the high cost countries of Europe there is a trend towards embedded software engineering. But since the telecom bubble burst a lot of the programming "has to be done in low cost countries" so we are told.
After a year or two and many costly experiences later even Java jocks (mostly male, still) in low cost countries can handle the is and odds of "true" embedded or have left for other pastures.
Meanwhile, here in Europe we see arriving of younger CS-minded colleagues who are very well aware of the challenges that ever shrinking hardware poses to ever more complex software in systems where lowering cost is everything.
May the numbers of newcomers be low compared to generation of US or European baby boomers - if the industry supports home-grown talent they will come!
Sign in to Reply
ChrisGammell
7/29/2009 8:20 AM EDT
I think you hit the nail on the head about the Java programmers coming out of CS programs; there just isn't any connection to hardware until abstraction habits have developed. Even in EE programs (I was taught on C++ myself), I never truly grasped certain concepts until I had hardware in my hand that wasn't working. You learn a lot about pointers when you don't even know where your memory is...
Sign in to Reply
jaranguren
7/30/2009 4:09 AM EDT
Hi,
Interesting enough. I am reading this article from EmbeddedEurope.com, and although we _all_ know what "Embedded" is, none can give a satisfactory definition to "Embedded", be it embedded system, embedded programmer, etc... As Jack Ganssle said:
"If we define an embedded system as a computer-based device that performs one type of action, does that mean a blade server is embedded? I think not, but have no real basis for that opinion."
Sign in to Reply
LarryM99
7/30/2009 12:27 PM EDT
Jack:
The real division is between system-level programming and applications programming. Writing device drivers involves direct hardware manipulation, deep OS knowledge, and most other attributes that we would normally assign to embedded systems. The difference in classical embedded work is that it also included a vertically integrated application. This worked (and still does) for simple applications, but most current apps don't meet that requirement. Hence we are seeing much more of application programmers in traditionally embedded applications. There will still be a need for system-level programming, though.
By the way, when you asked about clock rate were you referring to the internal CPU timing, memory interface, or one of the (potentially multiple) cache interfaces? :-)
Larry M.
Sign in to Reply
talulah
7/31/2009 5:22 AM EDT
I'm not sure Gilad is corrcet above when he says "finance and trading systems have as rigid as real time constraints as any encountered in the embedded field".
As an example, I love the preface to Hatley & Pirbhai's "Strategies for real time system specification". Tom DeMarco relates a story young engineering manager at a real-time software convention. She related her problem to him:
"We build systems that reside in a small telemetry computer, equipped with all kinds of sensors to measure electromagnetic fields and changes in temperature, sound, and physical disturbance. We analyze these signals and transmit the results back to a remote computer over a wide-band channel. Our computer is at one end of a one-meter long bar and at the other end is a nuclear device. We drop them together down a big hole in the ground and when the device detonates, our computer collects data on the leading edge of the blast. The first two-and-a-quarter milliseconds after detonation are the most interesting. Of course, long before millisecond three, things have gone down hill badly for our little computer. We think of that as a real-time constraint."
Would you rely on embedded linux for that application? It would barely have started its boot-up sequence!
Sign in to Reply
Luis Sanchez
4/29/2011 5:25 PM EDT
Want to hear my embedded systems definition?
I'll say it anyway :)
"Small computers for specific purposes"
doesn't this scopes all?
Sign in to Reply
EREBUS
9/1/2011 8:28 PM EDT
Hi Jack,
In my view, embedded computers will always be needed as people will want smarter and smaller devices. The requirements will demand the skills of that special group of people who can handle the detail required to make these systems work in either incredibly demanding conditions or where efficiency and speed are the key drivers. While the Universities have abandoned the skills needed to do this work, a lot of the Technical schools still see the need to develop those special skills.
I see a lot of eager young tinkers who are willing to follow in our footsteps. The challenge is too irresistable and the need will always be there.
Sign in to Reply