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

[Pinky's Brain]

I imagine they just want Android for UI design, internet and non RT peripheral interfacing ... mostly the same reasons for wanting Linux.

No need to handle things monolithically, you can always run a more predictable RTOS alongside.

Re:Wrong conclusions from the data

[muon-catalyzed]

Your anecdotal consumer grade experiences are spot on, perhaps we are witnessing another example of marketing win over engineering. Berkeley GEOS and IBM OS/2 vs MS Windows spring to mind also.

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

[knarf]

You would not use Android to directly control the hardware, that is handled by native code running on Linux. Android does make it possible to create good-looking user interfaces with minimum effort and - like you said - good portability. Since Android runs on top of Linux you can have both at the same time.

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

[Mr Thinly Sliced]

No production JVM is real time.

I'd agree that the standard JVM / JDK is anything but realtime, but Sun (Oracle now of course) created a JSR specifically tackling the shortcomings w.r.t. real time:

• Sun's real time VM implementation
• JamaicaVM
• IBM's real time VM
• Atego's real time VM

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

[Johnny Loves Linux]

I would think the hardware response time would dwarf the software response time by at least an order of magnitude, i.e. it takes a solenoid to be activated longer than for the operating system to make the request that the solenoid be activated. At the speeds at which vehicles move I don't see how a software response time in the millisecond range could possibly be considered bad. Maybe I just need to see some examples to understand the issues better.

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

[drinkypoo]

Android is too much embedded linux for anything headless.

For anything with a display, however, it's just fine. And you can control a lesser microcontroller with it to get your realtime hardware interface. There's tons of things many don't think of as embedded OS which aren't even realtime, like automotive interfaces as the sibling comment says, or slot machines, or in-store coupon dispensers with attract displays. A lot of these sorts of things have traditionally run wince because it was pretty much the only game in town that let them reuse code and waste cycles to get short development time. Now they can run Android, which is great both because wince sucks and because Microsoft is an angry, sweaty, chair-throwing gorilla.

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.

Re:Wrong conclusions from the data

[Anonymous Coward]

What do you mean?

All I see is that often the engineering types have no idea what the market wants. When marketing comes and says the market want product X, it's not the job of engineering to say product Y is superior, and instruct marketing to force it on the market.

Of course, if in fact product X is infeasible due to engineering problems, then that's another problem.

Re:Wrong conclusions from the data

[sjames]

Perhaps clearer. Marketing tells engineering what the market wants. In a good organization, engineering then tells marketing what they can do to satisfy that and marketing gets to work teaching the market why that is the best solution to what they want.

In a bad organization, marketing tells engineering what to do to satisfy the market and when engineering says that can't actually be done, marketing demands it anyway.

In a terrible organization, marketing decides what they want the market to want, tells engineering to build it, and then gets to work cramming it down everyone's throat.

In an even more terrible company, the CEO buys whatever his buddies are selling, instructs marketing to make the market want it, instructs engineering to duck tape it all together, and then gives the shareholders the finger while deploying his golden parachute.

Re:Wrong conclusions from the data

[Jane Q. Public]

Hahaha. Yes, that's probably closer to the truth.

Re:Wrong conclusions from the data

[sjames]

Of course, you can use a 1HZ signal to latch your frequency counter into a register for the software to read if you can't get the scheduling jitter down.

It's all a trade-off. If you can get the software's jitter small enough, you save on hardware.

Re:Wrong conclusions from the data

[EETech1]

That is one of the nice features of the Atmel XMega parts as well as FPGA, IE being able to have a value automagically transferred from one piece of hardware to RAM based on a hardware trigger from another interrupt source without having to service the interrupt generated from your hardware as soon as possible to move the value yourself.

For lots of other parts you have to rely on a fast context switch to your ISR and at least put that value somewhere where it won't get changed by the continuous stream of pulses being sent to the counter while your software gets around to using the value.

Every time you waste hi-priority foreground execution time on real time events, your real time system as a whole becomes less and less real time. Android also has nothing to deal with this, which makes it unsuitable for these types of real time control applications. There is nothing to guarantee that your 100 mSec hardware stored value will get read correctly by every asynchronous 100 mSec software loop, and the two will get out of phase enough that you will start reading one value twice on the same sample, and the control loop will begin missing every other sample from your hardware, or WORSE yet, one of your loops gets on the stack, and finally gets executed 10 mSec after the loop already ran again using the data from before as a new process input, and your autopilot was just informed it is now going backwards.

I've seen (fixed the problems caused by) software loops that relied on the value from a 100 mSec event scheduled to execute at 20 mSec intervals as forground tasks because that way the program would be sure to "not miss an update" because the software was too decoupled from the state of the hardware due to the OS selected. It was impossible to guarantee that two separate tasks set at 100 mSec intervals (one storing data, one using it in a control loop) would execute in the right order within the right timeframe to have any reasonable level of (stable long term) control over a process.

If you can live with stale or missed samples for the data in your control loops, by all means use WinCE, or Android (:and use lots of threads too:) If you need to do a proper job of real time process control (and monitoring) then you need a real RTOS with hard constraints on the resulting program execution. You have to be able to properly define the order of your software operations to match what's going on in the real world. Many things you just assume would have to happen correctly will not work correctly 100% of the time without an RTOS, and you might not notice it until you ship it, and your customers complain, and then you are really fucked because you have 2 years in band-aiding WinCE along, and you thought you had it working, but to really fix it right you have to start over (but expression blend made it easy to make a really pretty GUI) after you try to respin the hardware quick with a CPU that costs twice as much to cope with all the wasted cycles, and it still doesn't work right.

Cheers!

Re:Wrong conclusions from the data

[Billlagr]

Just curious - what eventually swayed your decision to go the Windows path?

Re:Wrong conclusions from the data

[musmax]

Why anyone, today, would chose Windows for "embedded" products, is completely beyond me. WTAF ? I would really like to see and try to understand the decision tree that lead to this outcome. If only to guard agains it in my own organisation.

Re:Wrong conclusions from the data

[n7ytd]

Underneath Android is still Linux, anything that needs to avoid garbage collection can easily run outside of the dalvik VM.

Then it's up to the whims of the overcommit memory killer in Linux. I'm not sure if turning that off will cause fits in Android...

Re:Wrong conclusions from the data

[AmiMoJo]

The company that provided the ARM CPU module recommended it and said it was "fully supported". They lied.

Additionally they were only offering Android 2.2 at the time, which lacked USB host support, but it would have been worth porting 4.0. As it is we had to write our own GUI framework anyway because Silverlight was fucked.

Re:Wrong conclusions from the data

[Billlagr]

Ah the old 'its fully supported and works great!' cry. Having been on the receiving end of that one as well, I sympathise. Thanks

Re:Wrong conclusions from the data

[jc42]

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

Yeah; that's a common attitude. More often, the job is to take what management has ordered, because they think that's what the customers want, and find some way to implement it to meet the management requirements.

For example, years ago when MS-DOS was still widely used and MS-Windows was new, I was involved on an "embedded" project that was "required" to run on MS-DOS. I had a critical part of the task, making the startup code work (and also the shutdown that got a DOS prompt back on the screen). What my startup code did was:

1. Call the initializers for all the app's packages,
2. Overwrite the interrupt table to point to our interrupt handlers,
3. "Return" DOS's space to our free-space list,
4. Call the start routine for the app.

There was also a reboot routine called from various parts of our code, to "exit back to DOS". This was called by a routine that handled a CTL-ALT-DEL keyin, for example. Testing showed that this did satisfy the requirement that our app "runs on DOS".

Since then, whenever I run across discussions like this one, I wonder whether the engineers have had to find equally "interesting" ways of making it look to managers and customers like the code runs on the claimed OS. But mostly, I've learned that this is often the sort of kludgery required to satisfy the requirements of management, marketing, and/or customers who think they understand how the engineering should work.

Of course, nowadays memory is a lot cheaper and available in GB-size chunks, so it may not be necessary to use the OS's memory. Just caching the OS's interrupt table, leaving the OS in memory, then restoring the interrupt table and exiting can do the job. But you still might want to try to guarantee that none of your app's routines overwrite any of the OS's "unused" memory, and that could be difficult to enforce if you have smart developers.

(And why am I tempted to add a "5. ... Profit." to that list? ;-)

Silly angle

[Gaygirlie]

A kernel all by its lonesome self doesn't really do all that much, it needs userland to become a useable OS. For example, Linux-kernel by itself would just be a Linux-kernel, nothing more, but slap uClibc and Busybox on top of it and you've suddenly got yourself a bare-bones OS. However, as the Linux-kernel is so utterly modifiable and flexible the userland can be almost anything and there is nothing about the kernel itself that somehow mandates that the userlands be in any way or form compatible with or even so much as resemble one another! So, if we are just going to slap together all the different forms of operating systems with absolutely no regard for the userland simply because their kernels are based on a similar source we should do the same for the other kernels, too, in order to be fair: slap OSX and iOS together with all the BSDs, all the Windows NT - based kernels together and so on, and then compare the numbers.

Linux, the kernel, would likely still come on top and we could all rejoice and sing Kumbaya, but... well, what would you gain at that point? What does such masturbation to the types of kernels actually give us? It says nothing about the operating systems, it says nothing about finer details like e.g. if the kernels are even compatible with one another due to modifications or anything, it's just simply a way of masturbating to the numbers.

Re:Silly angle

[Tanuki64]

100% correct what you say. Nevertheless, masturbating is necessary from time to time. Far too often important technical decisions are made by business people without a clue. Presenting them with some nice power point presentations and impressing numbers might help. Linux on top? Then it must be good. One million flies cannot err. So we might get directly or indirectly another supporter of Linux.

Re:Silly angle

[maxwell demon]

So, if we are just going to slap together all the different forms of operating systems with absolutely no regard for the userland simply because their kernels are based on a similar source we should do the same for the other kernels, too, in order to be fair: slap OSX and iOS together with all the BSDs, all the Windows NT - based kernels together and so on, and then compare the numbers.

Given that Linux got already 50% this way, even if all others, including the homegrown, would use the same non-Linux kernel, they still would not beat Linux.

Re:Silly angle

[Gaygirlie]

Way to miss the point of the comment.

Re:Silly angle

[sjames]

As long as there is significant demand for small devices that run a Linux kernel, MS can't get the HW vendors to totally lock things down. It also makes a good argument for Free Software as Linux drives proprietary out of yet another market.

On the creative hacking side, it presents a possibility to drop uClibc and busybox on your device and have fun.

News at eleven

[ls671]

News at eleven...

Linux has been dominating the embedded market device for at least 10 years.

Re:News at eleven

[Anonymous Coward]

That's not strictly true. Although my speciality isn't embedded systems, I went to an embedded systems conference back in 2000 and Linux very definitely was not dominating the market. Fears over the GPL were holding a lot of people back, especially those with custom hardware. VxWorks, LynxOS and QNX seemed to be the big boys, Linux was an interesting novelty, Windows was something to laugh and point at. How times have changed.

Re:News at eleven

[ls671]

In 2000, F5 networks and vmware were already running linux as many others were.

It is just not that well known, they kind of not advertise it that much...

Re:News at eleven

[BrokenHalo]

Windows was something to laugh and point at. How times have changed.

Admittedly taking these two sentences out of context, this might show how some things just haven't changed. ;-)

Re:News at eleven

[maxwell demon]

I went to an embedded systems conference back in 2000

Note that in the last ten years, there was no year 2000.

Re:News at eleven

[asylumx]

Ah, you beat me to it!

Re:News at eleven

[EETech1]

If it was THE embedded systems conference (ESC), in the early 00's it was sponsored largely by QNX, VxWorks and Mentor Graphics (Nucleus RTOS) they even provided your folders for the event at that time, and sponsored many of the classes they had. I remember attending (still have the handouts in the binders) many talks that mentioned Linux, used it for part of the demos, and either made note of it's increasing functionality and popularity, or gave hints that Linux based products were being developed by nearly all the big proprietary RTOS vendors, and by 2003 - 2004 Linux was Everywhere at ESC.

I first ran Linux in 2001 after some kind soul gave me a boxed copy (with manuals) of Mandrake Linux 8.0 at ESC. My boss and I spent the night installing it on our work laptops with partition magic and boot magic so we could play around with some of the demo code from class.

There was also lots of talk at that time about could you use GCC as a replacement for Green Hills etc. and we played around trying to get our ECU software and proprietary OS to build under GCC dreaming of the cost savings we would realize once we got it to work!

Good Times!

Re:News at eleven

[Bill_the_Engineer]

My speciality is embedded systems and I can attest to Linux being a dominate force for the past decade. Mainly due to a lot of work requirements being downgraded to soft real-time instead of the default hard real-time. QNX, VxWorks, and Phar Lap ETS still are preferred for projects with hard real-time requirements (Phar Lap ETS has fallen out of favor in our shop).

While Linux is growing in dominance it is not the only rising star. Projects like L4/fiasco looks promising and being deployed in projects (though not by us). I believe Qualcomm is incorporating L4 microkernel in their chipset.

My colleagues "just down the hall" have used RTEMS, and my colleagues farther "down the hall" are the ones maintaining it. If you are interested in an open sourced RTOS then please check it out.

Re:News at eleven

[scorp1us]

Dominating? No. It wasn't until 2.5/6 that Linux got to be embedded friendly. 2.4 was starting to make inroads but you needed the MontaVista kernel with the SMP spinlock pre-emption points to get good regular behavior (2001). Before that it was way too unpredictable to ever be used in any "embedded" device. Since 2.6 things have gotten a lot better and the interests of the embedded market have always been taken into account.

But not dominating. VXWorks was and still is dominant. Around 2.6 era (2005), you could finally get VXWorks apps to run on 2.6 without a whole lot of work. Again MonstaVista had shims for porting from VX to Linux. The shims were ok, though the preemption handling was not all there so there were still challenges.

I'd say linux is now the dominant OS, but that's only since about 2008ish, with the rise of Android.

Re:News at eleven

[Darinbob]

Linux is maybe bigger on the high end, but it's not big overall if you count embedded devices that range from using 64-bit power hungry chips all the way down to 8-bit micros. Linux essentially is big and bulky, relatively speaking. It's nice when you can afford the extra memory or CPU cycles as you get a lot of flexibility and free pre-built components, and Linux&BSD have far better network stacks than any commercial RTOS offerings I've seen. But a full Unix kernel is a drawback if you're on a slow CPU and tight on memory, or with real time requirements. Homegrown or partially home-grown is common because very often your embedded product doesn't need to do a lot, or what the product does.

Linux is a bit of a pain due to GPL. You can't easily modify part of the kernel with your proprietary code. Most embedded Linux uses tend to use user space process for the applications. Even loadable modules is iffy; industry saw how harshly people came down on Tivo despite them doing it the right way, so they see Linux as something to avoid.

options?

[crutchy]

unless you are into projects that don't require much of an operating system (such as assembly on AVR etc, probably the 28% custom/in-house figure), how many options are there apart from linux?

Re:options?

[Pinky's Brain]

TFA has a list of commonly used ones besides from Linux.

Re:options?

[loufoque]

NetBSD, FreeBSD...

Re:options?

[drinkypoo]

Off the top of my head there's qnx and vxworks, but there are scads of small embedded operating systems, realtime and not, some of which are basically paired with a specific architecture and some which aren't, etc. There's no shortage of options.

Re:options?

[Bill_the_Engineer]

(substitute the greek letter for the word micro)

You may want to google "microC/OS". It is a simple library that you can add to your program. MicroC/OS-II was free for use if you purchase the book "microC/OS The Real-Time Kernel". I think it has since gone commercial at Micrium.

Re:options?

[crutchy]

reading tfa? next you'll expect me to rtfm
omg what has /. become

Re:options?

[crutchy]

wow there are quite a few options... thanks guys

Wrong angle

[Anonymous Coward]

Especially since only Linux offers a proper setup for Android development. It's like saying "iOS developers love OS X" just because 100% of them do their iOS development on OS X - as the tools are only available for OS X. They may very well love OS X (really, who doesn't?), but that's not the sole reason behind the number.

Re:Wrong angle

[Bill_the_Engineer]

Especially since only Linux offers a proper setup for Android development.

I don't understand your point. Android runs on top of the Linux kernel and if you go the native app route then you will be making Linux system calls. Unlike iOS, you can develop for Android using Windows and OS X too.

Re:Low end, in house?

[Anonymous Coward]

Depends on what you consider an Operating system I guess. A basic task scheduler and process messaging could be thrown together in an afternoon, memory allocation is easy but you generally don't want it in an embedded application. The peripheral drivers is something you will have to put together regardless of OS.
It's when you need a network stack and a filesystem that you might want to pull in something that is already done.

Re:You are aggregating non-like things

[Bert64]

But since this story is about embedded uses, users don't buy operating systems either, they buy the entire device.
Embedded devs on the other hand do select a kernel, and will often build their own userland to go on top of it.

Who's gaining?

[Cytotoxic]

The takehome from TFA for me was that Inhouse/Custom, Android, Ubuntu, FreeRTOS and Windows Embedded 7 are all gaining marketshare year over year with everyone else either holding steady or losing ground. They also happen to be the top 5 OS in the survey. The biggest gainer in what appears to be a consolidating market was Android.

Minix on embedded?

[unixisc]

Minix wasn't listed, although it would seem that Minix 3.2 is perfect for this niche

High level embedded systems

[ultranerdz]

So many misconceptions here.

1st we can assume Android uses the kernel Linux, so android "includes" Linux.

2nd, there are many types (levels) of embedded systems. Some don't need CPU (nor software). Some require a simple microcontroller, and some require true connectivity, true multitasking, lots of RAM, and maybe an MMU. Some of these systems run OS, and some of there are Linux. Lets call those "high level" -- happen to be the ones we interact on a daily basis (like a Smartphone for example).

Said that, the great vast majority of embedded systems are not "high level", and we normally don't even "use" them directly, so they don't run Linux (nor Android).

What is true is that in general, people that need to program in high level, prefer to code in Linux (or even Android) than to code in Windows CE, bare metal, or any other Embedded OS (or RTOS out there).

But still, it will take "long time" to Linux really dominate the embedded market.

Re:High level embedded systems

[Bill_the_Engineer]

You've confused me with the following (not disputing just need clarification):

Some don't need CPU (nor software). Some require a simple microcontroller, and some require true connectivity, true multitasking, lots of RAM, and maybe an MMU.

A CPU can be a traditional ASIC, RISC, microcontroller, or FPGA based. An majority of embedded applications can not take advantage of lots of RAM or have a MMU.

Re:High level embedded systems

[Darinbob]

Often you're stuck with a CPU that you don't want either, due to cost-per-unit pressures. So you can't run Linux even if you wanted to. Ie, ARM7TDMI is very popular since it's very simple but has no MMU.

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.

Re:50% is domination?

[Bill_the_Engineer]

Well according to the title having only 16% people like Android was enough to declare that embedded developers love Android. So consider the editor/submitter.

Resume'

[Anonymous Coward]

I'm an embedded developer, professionally with experience down at bare metal (with my own scheduler), VXWorks, QNX, Linux and NetBSD. In my opinion, NetBSD was by far the best embedded OS to work with. In places I've worked, the main reason for choosing Linux over NetBSD is "Linux will look good on my Resume... No one knows what NetBSD is." ... I counter that they already have Linux experience, so having more keywords on their resume is better than appearing to only have experience with one OS.

Re:Resume'

[Pinky's Brain]

Would you say that you would cost more or less to hire than an equally knowledgeable Linux developer for consulting services?

Re:What the heck?

[K. S. Kyosuke]

Circuitry and logic are supposed to be half an embedded system, not one percent.

I didn't know that there was an official exchange rates between gates and bytes so that one could numerically compare.

Embedded Projects

[Murdoch5]

I've worked on / built a lot of different embedded systems both hardware and software and I've been left with this question many different times. Linux is great where you need a high level of control, and a great standard posix level interface and If you need to control timers, interfaces, resource tables and more. Custom implementations are great when you need to manage less resources but can handle the overhead of writing a custom RTOS from scratch. Android is great where you want another option apart from Linux. It's not a real cut and dry method of just sitting down and picking out a software platform for an embedded systems, it comes down to what your comfortable with, what you need it do / handle and what your over all requirements are.

To date I've used Linux on 3-4 different Embedded platforms, I've writen my own on about 8 different Embedded Systems, including one that was big enough for Linux but I just wanted a true custom RTOS for fun and I've used Android on 1 of them that is still unreleased. Most of my projects are open source so I tend to release the code after the fact.

Re:Embedded Projects

[gatkinso]

>> handle the overhead of writing a custom RTOS from scratch.

Surely you are not referring to Linux. RTAI, Xenomai, RT_PREEMPT. Not to mention the nonfree offerings.

Re:Windows CE forever !!!

[Holmwood]

Oh come on, that AC deserves +5 for funny for his topic, leaving aside the dorky "first!". I was on the board of a company that was competing in that space (licensing embedded OS's) back in the 90's. We concluded we weren't viable because we were in the ~$7-10m a year range of licensing fees. We found out Windows CE, globally, was in the neighbourhood of $3.5m/y. Boggle.

We still concluded we weren't viable, and transitioned to a POSIX-compliant variant of Linux and other activities. Given this survey, I don't feel sad about that choice.

No OS dominates the embedded market

[Osgeld]

Android maybe if all you look at is consumer do-hickies, but in reality there are billions of embedded systems you never see that perform flawlessly 24/7 for decades which use no OS at all

Forth!

[MasterOfGoingFaster]

OS? I don't need no stinking OS.

Google "Forth"

http://en.wikipedia.org/wiki/Forth_(programming_language)

Horses for Courses

[BlaiseP]

Old man noises: embedded development hardly feels like it any more. When you can say "oh, let's do one side with Cherokee so the configurator can set up the device and it can talk to the C polling stuff on the other side via shared memory" it's almost too good to be true.

Re:Horses for Courses

[TheSeatOfMyPants]

Old man noises

*imagines it* *shudders* Can I have a side of brain bleach with that?

Re:Low end, in house?

[dfghjk]

"A basic task scheduler and process messaging could be thrown together in an afternoon, ..."

Right, kernels are things you throw together in an afternoon. I'm sure most of them are. Bootstrapping code takes, what, 5-10 minutes?

Re:Low end, in house?

[sjames]

If it's basically an app on bare metal on fixed hardware, yes, you might throw the 'kernel' together in an afternoon if you have some parts lying around in your code library.

Dalvik and processes

[Dennis Sheil]

"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."

Dalvik has specifications and documented behavior and Dalvik follows that behavior pretty well. You do not see Dalvik disposing of anything connected with a process that is state that it supposed to save. Some state is ephemeral and documentation states it is ephemeral. I have yet to see an object held by a running Service to be arbitrarily destroyed by Dalvik. Offscreen Activity objects might be destroyed, but Android API documentation explains this up front. If you want to hold state in a process outside of the current onscreen Activity, you put it in a Service or like class, not in the Activity object. Activity objects are supposed to be short-lived when they go off-screen.

Dalvik has no problems holding state if you hold state properly in a Service object. If you try to hold state in offscreen Activity objects then you shouldn't be surprised when Dalvik doesn't hold it. It's not supposed to.

Re:Dalvik and processes

[bfandreas]

I am fully aware of this and I understand the reasons for it. Not only was it a sound decision from an engineering point of view, it also hammered the need for state saving into the heads of developers. But I'm not altogether sure if the reasoning behind getting rid of stuff asap hasn't already been eliminated.

But for a(most likely) headless embedded system with a very specific task this is something I would not want. OTOH if you only use it for non-essential UI stuff like the display of a washing machine or the dashboard of a car then I'm not going to object.

Android wasn't built for headless RT stuff and it doesn't have to be. Right tool for the job. Not square pegs/round holes.

Syntax Error

[TheSeatOfMyPants]

...it's dominANT, like "is dominant in BDSM scenes" rather than "will dominate the penis-length competition" or "that bitch is totally dominating his ass."

I dont always use an OS in embedded projects

[gatkinso]

But when I do, I prefer to use Linux.

I did not mean to quote the most interesting man in the world, but it I like the way that reads.

NetBSD

[manu0601]

NetBSD is not famous, but it definitively deserves a look for an embedded OS.

First, it supports major CPU used in the embedded field: ARM, SH3, SH5, PowerPC. So does Linux, but NetBSD has the nice ability to be cross-buildable from any POSIX/ANSI C platform. You can build your NetBSD embedded system from Linux, MacOS X, and even Windows + cygwin

Then there are the architecture and bus independant drivers. NetBSD uses the same driver for a given chip, whatever the CPU is, or whatever the bus the chip is hooked to. This means most of the time you do not have to rewrite or tweak drivers when working on an embedded platform: you reuse existing code.

Re:Low end, in house?

[mathew7]

I work in automotive non-UI enviroment. And I can tell you that the OS is very minimal. It hooks to a timer interrupt and executes predefined tasks based on timer. It has no memory sharing, no drivers, no filesystems. It just handles context switches.
So me knowing about it, I can tell you that yes, you can make a working OS in one afternoon.

Oblig. quotes

[Errol backfiring]

'Statistics are like a drunk with a lamppost, used more for support than illumination.'
-- Sir Winston Churchil

"There's Lies, Damn Lies, and Statistics."

If you tweak statistics enough, you will always find what you are looking for. Especially if your sought answer has nothing to do with the questions that were asked. Or would you really ban sober driving if 25% of the traffic accidents are due to alcohol use?

Re:Low end, in house?

[WalrusSlayer]

For some definitions of OS I suppose.

I can also make a working web server in an afternoon, if all it does is listen to port 80 and translate GET commands into the file system, and error out on everything else.