Embedded Linux or eCos?

Question

One way to look at it - embedded Linux starts with desktop Linux & ditches the parts not needed for embedded systems (is this actually true?), whereas eCos is designed from the ground up for embedded systems.

Now, assume an ARM processor, probably ARM 7 - does performance make a difference? Actually, we talking a very low load system, max 500 transactions a day.

Any advantages of one over the other (or FreeRTOS, etc)? Stability, maturity, performance, development tools, anything else?

All that I can think of is that if I am certain that I will never port to another o/s, then if I go with embedded Linux, I don't need an o/s abstraction layer to allow me to do unit testing on host (desktop Linux box).

Any thoughts or comments? Thanks.

Answer 1

Every device I've put Linux on started from the ground up and was not a stripped down version of some distribution.

eCos and Linux have different goals. Linux is intended to be a full featured Unix-like system and consequently isn't so concerned about minimum system requirements. eCos is a real time operating system designed for systems that are often resource constrained. There is a lot of overlap between the two OSes and in many situations both will work equally well.

In my experience, if your system has the resources and your requirements are non-trivial, development will go faster with Linux. It's easier to find competent Linux developers than RTOS developers, the tools are cheaper, processes are protected from each other, you tend to have better visibility into the running system, etc.

An (better, IMHO) alternative to eCos is RTEMS (http://www.rtems.com). It's been around longer and last time I checked, supported more architectures than eCos. It also has a PC BSP and runs under qemu for emulation.

Answer 2

There is no real benefit in putting Linux on an ARM7 IMO; ARM7 has no MMU and memory protection is a primary reason for using an OS such as Linux. uClinux will run on targets without an MMU, but you have lost one of the most compelling reason for using Linux, and still need the huge memory resources (A 4M flash, 16M RAM would be a sensible minimum).

Many ARM7 devices do not have external memory busses for attaching that much memory, and on chip flash and RAM typically range form 32K to 1M depending on the device.

Linux is not intrinsically "real-time". For real-time capability it is often coupled with a real-time kernel, where Linux essentially runs as the idle task, or on targets with the capability as a separate virtual machine. So if deterministic and fast response to external events is a requirement, you'll need an RTOS such as eCOS.

eCOS is great in that it has a large ecosystem of add-on features and device support that rivals most commercial offerings. However something like FreeRTOS are likely to be easier to 'bring-up' but provide no more than a thread scheduler and inter-process communication mechanisms. Stuff like a file system or TCP/IP need to be sourced from third-parties (although there equally small and free solutions suitable for embedded systems for that too).

If you use a simple Kernel such as FreeRTOS or uC/OS-III, you will not have wasted too much time, so the investment is not an inhibitor to using something else next time. Linux on the other hand may well discourage you from using something smaller and more narrowly targeted next time, and tour subsequent projects may cost considerably more than they need to just to support your OS of choice.

Answer 3

Embedded Linux == Linux in 99% of all cases. You just configure the kernel differently.

Biggest difference in performance is that with eCos you can, depending on your implementation / configuration, have an expected response time while with Linux you are at the mercy of the interrupt controller.

Linux has a much bigger fan base than eCos thus more help for development, and it supports a wide array of CPU's. Also depending on what drivers you want, you can compile and run your program on a PC running Linux.

Linux can detect lockups / deadlocks and send automatic responses / reboots to keep high availability of the system.