Embedded Developers Prefer Linux, Love Android

DeviceGuru writes "In a recent EE Times 2013 Embedded Market study, Android was the OS of choice for future embedded projects among 16 percent of the survey's participants, second only to 'in-house/custom' (at 28 percent). But if a spectrum of disparate approaches can be lumped together as a single option, why not aggregate the various shades of Linux to see how they compare? Parsing the EE Times data that way makes it abundantly clear that Linux truly dominates the embedded market."

Comments

Wrong conclusions from the data

[livingboy]

If you look original EE Times link and read the article, you will see that the love for Android is dropping:

However, despite pulling ahead of FreeRTOS and Ubuntu Linux, the news is not all good for Android in embedded applications. Whereas a year before 34 percent of users thought they would be using Android during the following 12 months that percentage dropped to 28 percent in the latest survey.

After all, used OS is mostly hardware dependent, is it a low end or high end embedded platform.

Low end you do in the house, middle range applications you use some RTOS, in the high end you use those Linuxes and Android.

Disclaimer: I am currently evaluating OS that did leap from 0 to 4% in its first year of use.

Re:Wrong conclusions from the data

[bfandreas]

Android is very unpredictable during runtime.

This of course is purely anecdotal and based on my consumer grade experiences. But given how eagerly Dalvik disposes of anything connected to a process that'S not in the foreground I wouldn't consider using it to do anything important. As an abstraction layer for vastly different hardware running the same crap it works quite nicely. But you shouldn't attach hydraulics, engines, valves or anything else important to it.

Also let's not forget how long it took to get Linux anywhere near equipment that needs an RT OS. And it possibly still isn't the first choice in such environments. I've been out of that loop for a long time and have been known to be wrong. So this is no engineering advice.

Re:Wrong conclusions from the data

[Anonymous Coward]

People are mixing up two different concepts: embedded != realtime.
Of course no one confronted with critical realtime requirements will choose Android java application as a solution.

Re:Wrong conclusions from the data

[AmiMoJo]

When they say "embedded" they probably don't mean headless boxes as you appear to be thinking of. At work we recently developed such a device, a tablet PC running Windows Embedded Compact 7 with one auto-starting app.

We looked at Android. You can either disable the home button in software or just omit it from the hardware so that your app is always in the foreground. Not that you would necessarily want to; eventually we would write a custom launcher that could start other apps we provided.

Windows Embedded Compact 7 is a turd. Parts of it just don't work. We raised a support ticket with Microsoft because Portuguese language settings didn't work and their response was "it's broken, we know about it and there is no business case to fix it, and BTW a bunch of other random languages don't work either". We were planning to use Silverlight to do our UI but performance was terrible, seemingly not using hardware acceleration at all (despite OpenGL ES working perfectly well). When you start playing stereo sound the left and right channels are sometimes randomly swapped. The whole thing is a giant cluster-fuck.

Re:Wrong conclusions from the data

[jrumney]

Your anecdotal consumer grade experiences are spot on, perhaps we are witnessing another example of marketing win over engineering.

Engineering's job is to make what marketing want work, not argue about whether the market wants the right thing. Underneath Android is still Linux, anything that needs to avoid garbage collection can easily run outside of the dalvik VM.

Re:Wrong conclusions from the data

[EETech1]

Lets say that your valve is from a 1987 Ford and it is for idle speed control. those valves run at 10 Hz so your best case 1 Msec response time will give you 1% increments from 0% - 100%. If you had a requirement to have better than 1% resolution, you couldn't get it. If your response time varied by 1 Msec as well, you couldn't hold better than 3% on the valve position giving your engine a roughly + - 2% window on the the idle speed. This in itself would be an objectionable level of idle stability on the slowest valve ever used for idle speed control.

But you might have a hardware PWM to help you gain accurate control of the valve by just loading a value to a register and calling it a day because the hardware timer will take care of giving you an accurate frequency and duty cycle, what could go wrong then?

The same issue would still manifest itself perhaps even to a greater extent because the PID calculations that you would be using for the speed control loop on your idle speed need to be taken at very exact intervals to get a good cause and effect relationship out of those calculations. At a 600 RPM idle on your 5.0L V-8 you will have 40 combustion events per second, and the PID would likely be calculated at the most every 50 mSec to get any kind of stability out of it. If your scheduling and task swapping caused that calculation time to vary + - 1 mSec that would also create a ~4% error in the PID output because it might have really measured the change over 49 - 51 mSec and now you not only have an invisible (to the software) amount of jitter to deal with you run the real risk of having 1 or 2 or 3 of the 25 mSec combustion events being used in your current idle speed calculation. If you got unlucky and just missed the 2nd combustion event in your calculation, you only have half of the "power in" you expected when you calculate what effect your valve position is having on your engine speed, your PID may say "hey, we need the valve open more!" so that calculation will drive the valve too far open. The next time the PID calculates it is likely to see the effects of 3 combustion events which will be driven by a valve that is now too far open and overcompensate again by closing the valve too much. The resulting engine speed will become very unstable.

You can see where you might want to be able to run that calculation faster say on a 10 mSec schedule. Now your 1 mSec jitter will result in a 20% variability in the time used in the PID calculation sometimes, so while you can run the calculation more often, and filter the output to the valve to keep your PID loop from essentially aliasing your combustion events, your increased time variance will somewhat negate any gains you had from running the calculation 5X faster increasing your CPU load (which will increase your 1 mSec response time jitter) and might make your system even harder to tune for a smooth idle.

Another Example:

If you were trying to monitor a 1 khz frequency by accumulating the pulses in a hardware counter and and were reading the result every 100 mSec, and you had 1 mSec jitter on the time you read your 1 mSec pulses. You would have a sample period of 99 - 101 mSec, this would automatically limit you to 10 hz resolution on your pulses (99 to 101 of them * 10) so your measured speed would best case read out 990 - 1010 hz and your control system would have to live with never knowing if it was really at 990 hz and read the frequency too soon, or it was at 1010 hz and read it a little too late. It would severely limit the control you would have on the process that was generating the pulses.

Hope this helps!
Cheers

Re:Wrong conclusions from the data

[Jane Q. Public]

"Engineering's job is to make what marketing want work, not argue about whether the market wants the right thing."

Complete nonsense. Granted, that's how some companies are run, but generally it is not a very successful formula.

If you want your company to be successful, it is the job of Engineering to tell Marketing what works well and what doesn't. Marketing may want something specific, but if it doesn't work well, it won't sell well either.

Apple is a good example. Engineering drives marketing as much as the other way around.

50% is domination?

[Kjella]

Now this is domination. And this is starting to look like domination. Looks like embedded still has a way to go, though Linux overall looks healthier than ever.