The dumbing down of embedded design

11/21/2011 3:09 PM EST

Hi,

"chip companies are providing complete Linux/Android ports, so “embedded design” is more about writing a bunch of Java code to run on top of these operating systems."

This is just the dream of some non-engineers;)

Most of the times the code written by chip companies is just good enough to make some 5 minute demo and I would certainly not use it in any real product.

With some chip companies you even need to sign NDAs to get there Linux/Android ports (remember this is supposed to be Open Source).

There are even board manufacturers paying software people for mainline Linux porting because chip manufacturers don't have enough incentive to get their stuff into mainline and rather prefer to write code for the next demo.

After some failed non-mainline Linux/Android projects companies will hopefully realize that mainline is the way to go and more and more chip manufacturers will hopefully be forced to wake up and start working with the community.

We need to put pressure on the chip manufacturers so they push their code towards mainline and if the result is to have a stable foundation to work on I'll even learn Java.

Regards,

Robert

--
Robert Berger
Embedded Software Specialist

Reliable Embedded Systems
Consulting Training Engineering
URL: http://www.reliableembeddedsystems.com

11/21/2011 3:38 PM EST

I think chip manufacturers are one thing and OS developers are another. Of course, a sample app provided by the chip manufacturer is nothing more than that... a sample.
Product developers must consider the sample app as a seed for their project and debug.
Interesting article.

11/21/2011 4:30 PM EST

Why use Linux/Android in embedded ?
Because you can benefit from ETH,USB,graphical libraries, GCC and so on.
However, most of embedded application don't need/use all of that.
Instead they may need features hardly achievable by embedded Linux:
- determinism(controlling ISR or develop time triggered behavior)
- possibility to control scheduling
- low cost
- robustness
...

11/21/2011 5:08 PM EST

Back in the 1990s CPU resources were much more limited and the argument was whether or not to use an RTOS or base silicon.

Now resources tend to be more freely available and the argument tends to be whether to use Linux or an RTOS, though there are still a heap of tiny parts that still can't cope with an RTOS.

There is no one-size-fits-all and there certainly never will be.

The people I speak with in the RTOS industry see that their ability to sell high end functionality has been greatly eroded. More and more RTOSs are being beaten back to their core competence (ie. scheduling and resource handling on smaller and real-time systems). That means the RTOS vensors are losing value and having a harder time to differentiate.

11/21/2011 6:30 PM EST

Many years ago ... maybe it is not so many; this very publication predicted the pre-eminence of Wind River's VX WORKS operating system taking over the world! I see folks doing it again with another OS. While in fact, from what I can see, it is the stubborn entrenchment of while(1){} that has carried the day! Let us hear it for:

while(1){}

11/21/2011 7:15 PM EST

I would have to concur on the complexity and challenge of programing the newer, "bigger/better" chips now available. I spent 2 plus weeks trying to program the MANY configuration registers for this particular 32bit micro (wanted to do something simple like: sample 8 analog channels repeatedly). After many attempts, re-read of the datasheet/programming reference and looking at example code if finally got the secret sauce mix right. The example code was quite useless, including the web page server (which seems to timeout a lot?). I would hope that either the companies get better at documentation OR fix the nightmare of conflicting registers...

11/23/2011 1:41 PM EST

I don't think LINUX or Android are gonna take over the automotive space anytime soon. Can you imagine an engine controller running Android? Airbag system? ABS? Traction control?

11/23/2011 3:04 PM EST

"But under the hood that instrument has an enormous amount of code devoted to sampling analog inputs, triggering, measurements and more, much of which has to run at insane speeds."

Yes. And that code is written in VHDL.

11/23/2011 3:14 PM EST

Nuts!

Give me a PDP-8 with 4K of core, a teletype, and my own mini-kernel (successfully ported to more than a half-dozen different machines, by the way) any day!

11/23/2011 3:26 PM EST

I agree with e2718 (well, Verilog). My current project is a synchronized motion control system (Real Time Module - RTM) for a new generation flow cytometer. A very small linux board gets commands over the ethernet and then appropriately programs an FPGA to implement those commands. Then the linux board just hits the FPGA "go" button and waits for the action to finish. It's very powerful and very simple to create. As soon as you need ethernet (and who doesn't these days) then you need linux, etc.

11/23/2011 3:40 PM EST

As has been said before, Android is not a real-time system platform. Perhaps there are things that can be done to the underlying Linux kernel to make it more so, but it truly is not that way out of the box. Also, in addition to the kernel work to enable these potential real-time capabilities, one would need to use the Android NDK which by-the-way utilizes 'C' to create those applications.

As for cost per unit, the memory and processor bandwidth required by Android significantly increases BOM costs. In some applications, that is not a big deal, but the bulk of processors sold are still going into dedicated simple low-cost circuits. (Power consumption is another point where Android does not do as well as a basic or no OS simple application on say an M3 ARM core.)

There is a reason why company's like TI continue to release both Android and non Android capable processors for their customers. There is plenty of room for both deeply embedded platforms and the more GUI rich Android type platforms. In the company I work for we are developing some products using Linux/Android but many will continue to use deeply embedded 8, 16 or 32 processors.

11/23/2011 4:52 PM EST

Great article Jack!
I agree, we can't generalize about embedded systems. But at the same time some perspective is required on the industry. Linux/Android get most of the media coverage. But according to ARM, in 2015 25% of the world processors will be Application processors, able to run Linux/Android.
This is why it is sometimes frustrating for all the folks who will be working with the 75% of all the work processors that will be Embedded Processors that can't run Linux/Android but that will be everywhere in our lives, to not receive the media coverage its market share deserves!

11/23/2011 5:26 PM EST

In 20 years of embedded design I have only once used a "proper" OS, and that was XP Embedded (essentially a specialized XP Pro).

The common usage of "Embedded Software" is far too narrow, consisting mostly of COTS hardware + OS with only application code being developed. How does one describe firmware lower down the food chain? "Deeply Embedded" used to be the phrase, but why the need to qualify?

I suspect the real problem is that journos are so fine-tuned to trends that their writing needs to be integrated to make sense.

11/23/2011 6:25 PM EST

I say "Game, set and match" to eembedded_janitor: "A Porsche is good sports car but it is useless if you try use it as a truck." There will always be the right "thing" for the job, be it at the hardware or software level.
Doesn't this "Linux/Android everywhere" sound just like the "8- and 16-bit processors are dead" talk? It seems that people think it's cool and avant-garde to make these sweeping generalizations, and do so in the hopes of being crowned the next "visionary". All they do is expose how little they know about what goes on under the hood in that particular field. As usual, Mr. Ganssle shows he's definitely in a different league!

Another aspect of this is that the "thing" in question can be "right" for a variety of reasons:
- it might not be the cheapest but it gets your product to the market before the others'
- it might not be the most appropriate but you know it like the back of your hand, have the right tools for it and don't have to wade through 4000 pages of literature to get up and running with it
- if your company buys 100K 8-bit MCUs per month for other products and you decide to use a 32-bit part on a low-volume device "because you're in tune with the market and know that 8- and 16-bit MCUs are a thing of the past", the only thing of the past will be you!

And I agree with Crous: Linux and android may be the "new kid in town" but let's not forget that the "real embedded" world continues to exist (and is what brought most of us to this page). In the words of the Alan Parsons tune, "Let's talk about me for a minute!"

11/23/2011 9:28 PM EST

In my 40+ years (before the 4040) of embedded systems, I have yet to use an "off the shelf" OS. A RTOS is a time and resource waster in situations where real time response is critical. No RTOS makes a system much more difficult to hack. However, I do find fault with chip manufacturers who do not do an adequate job of documentation,

11/24/2011 4:38 AM EST

"...stuff Android into your next electronic toothbrush..."

Hey - why not? And WLAN too!
Just imagine the wonderful possibilities this opens:
- check battery status from everywhere on the planet
- get new apps for vibration schemes and brush movement
- get new tunes for the "finished" bell
- check whether and when your children actually used their brush
- play nice melodies on the piezo as brushing timer

and many others...

;-))

11/24/2011 6:18 AM EST

Lovely article, Jack. Thankyou.

As usual, the headlines forget the enormous proportion of the embedded world which is exactly that - very deeply embedded and just not in the realm of Android/Linux etc. In my days as a software developer, I learned the hard way never to trust example code and incorporate it into products without either complete and comprehensive testing, total understanding and agreement with what it did and how it did it, and if necessary a complete rewrite. In the long run, it turned out almost always to be easier, cheaper, quicker and much more reliable to write this code myself.

Once bitten by untested, unworking, incomplete code, very definitely twice shy!

11/24/2011 6:38 AM EST

I am just wondering , in all this jungle of powerful micro controllers and the OS and RTOS where do those DSPs stand - Has anybody tried to have an OS working on a DSP?

11/25/2011 2:53 PM EST

Trying not to over generalize, there is a function spectrum ranging from the "application" as perceived at the human interface to the "deeply embedded"/"real-time" function at the I/O interface. An OS environment manages I/O operations and provides an API for the human interface. The function in between the API and I/O where the DSP and real-time needs a programmable function that can be replicated at least for each I/O interface type where computation and responses can be handled without putting the whole load on a single CPU.

11/30/2011 11:35 AM EST

An 'embedded system' can be:

a tiny chip programmed in assembly (any 4 bitters still around?)
an 8-bit part programmed in C
a larger part with state machine code in C
an RTOS based design in C or C++
a Linux/Android design using Java
a COTS Atom processor board running Linux and/or Windows embedded
an appliance type box running a full server OS

There are many shades I didn't hit above. And in all cases someone has to design the system and code.

12/1/2011 8:28 AM EST

Perhaps we should redefine "embedded" from the user's perspective. If the system runs a fixed application (no matter how complex), then it is embedded. If the system lets the user load and run various software applications then its NOT embedded - its a computer! A "plain" cell phone is embedded while a "smart phone" is not. I thought "embedded" was short for "embedded computer system" - that is, a computer used in a product that wasn't a "computer". A computer is a system that lets the user load and run various software "applications". The nature of the "app" isn't really important - it can talk to a line printer of a cellular radio chip. When the user has to care about what OS is in the product, then its likely a computer! (In this context, something like a scope with "upgadeable" software is still embedded - the user sees the product as having a single "fixed" application.) This definition for "embedded" carries a real distinction back to the designer as well. For a truly embedded system, the designer concentrates on a tightly defined functional definition of the product. For a computer, the designer concentrates on computing resources provided, allowed I/O functions (built-in or attachable) and all the associated resource limits and interactions within the system. A very complex task. The more systems migrate from "embedded" to "computer" status, the more we will see frustrated users, failed products and dangerous faults. Its time to wake up to over complexity in product design.

2/11/2012 2:15 PM EST

Register at www.ftdautomation.com

Free Seminar on Technology Trends in High Speed PCB Design and Introduction to Cadence New OrCAD 16.5 Version - Friday 24th Feb 2012.
The Pride Hotel, 5 University Road, Shivajinagar, Pune, India
Time: 09:00am to 1:00pm – followed by lunch

Who should Attend?
• Electrical /Electronics Engineers
• PCB Designers
• Engineering/PCB design managers
• Electronics System designers
• Engineers from electronic product company
• Design service engineers
• Electronics manufacturing Engineers