ELC Releases Embedded Linux Standard v1.0 49
An anonymous reader writes "The Embedded Linux Consortium (ELC) formally announced its release of the ELC Platform Specification (ELCPS) version 1.0 this week. This LinuxDevices.com Special Report includes the full text of the ELC's announcement, a whitepaper about the ELCPS standard, a newly updated "frequently asked questions" document, a roundup of news coverage, a poll, a discussion thread, and the spec itself."
Re:Hrm (Score:2)
Re:Hrm (Score:1)
Re:I want Linux to run on my... (Score:2, Funny)
this toaster [sun.com]
burns the weather into your toast - done by java, maybe linux is in there somewhere though
*cough*, incorrect (Score:2, Funny)
embedded Linux of limited usefulness (Score:5, Interesting)
Really cheap devices go for small, older, cheaper processors and memories that can't support the relatively high processing capabilities required for Linux systems. For a hundred dollar VCR, Linux is great, but not for a twenty dollar mixmaster.
Many industrial facilities use great numbers of embedded devices. Linux just can not meet the hard real time deadlines required. Even with the low latency and kernel preemtibility patches, Linux doesn't have the granularity necessary to ensure that hard deadlines are met. There are a couple of kludges around that allow Linux to be used on such devices, such as running virtual machines with Linux and a true real time OS and making them communicate via sockets. Sadly proprietary solutions currently fare much better. Mobile telephones also fit in this category; although expensive ones may eventually run Linux and something else, they won't run only Linux.
With all the difficulties facing them, I can't help but wonder why the embedded Linux people bother. They would be better off writing a new OS that had lighter requirements and a design to allow it to meet hard real time deadlines. That would be a big step forward for putting the GPL in embedded platforms.
Re:embedded Linux of limited usefulness (Score:4, Interesting)
Re:embedded Linux of limited usefulness (Score:3, Interesting)
Witness the proliferation ofcheap PDAs [buy.com].
The other day, I was looking into obtaining some hardware that I wanted to use in my own embedded experiments but I could not find anything that was cheap enough (read: to be profitable if I ever decided to bring my low-volume application to market). The PDA brings an interesting twist to that.
Is there any PDA that lends itself to being hacked apart and used in something other than its intended use? The other day, I was at Lowes and I saw that their alarm system had the screen about the size of a PDA. A closer look revealed that it was running PalmOS.
Bueller?
Re:embedded Linux of limited usefulness (Score:2)
Re:embedded Linux of limited usefulness (Score:1)
kernel and i/o layer (for hard-real-time stuff).
it wouldn't then be linux (or gnu-linux), rather an
elcps-compliant rtos.
Re:embedded Linux of limited usefulness (Score:4, Insightful)
Sure there are embedded applications and devices for which linux is probably inappropriate, but so what? Linux won't get used there. However, the word `embedded' covers a lot of ground, and there are many embedded applications and devices for which linux is a perfectly fine solution -- and that's where linux will be (and is) used.
[Morever, as another post pointed out, the hardware used for embedded devices is continually getting more powerful, for any given application, making linux more and more practical.]
Re:embedded Linux of limited usefulness (Score:2)
Re:embedded Linux of limited usefulness (Score:2)
RTLinux--exactly! (Score:1, Informative)
I'm sure you can see why that is a bad solution. You add complexity, and make a second class Linux citizen just so that you can claim it is there. As far as using it goes, it is just a horrible nuisance.
Re:embedded Linux of limited usefulness (Score:1)
Ever heard of Real-Time Linux [google.com] ?
Or about Hard Real-Time Linux [google.com] ?
Re:embedded Linux of limited usefulness (Score:1)
'Lighter requirements' is a pretty hard to define goal - contrary to many opinions, a Linux kernel configured to have only those functions that are needed for a specific application is pretty close to the smallest size that I've ever seen those functions implemented in. (At one time gcc did not optimize well, making even a simple embedded operating environment written in and for C much bigger than one hand-crafted in assembler - but now that embedded apps are getting more complex, most embedded systems are compiled with a flavour of gcc, so that's no longer relevant)
For a TCP/IP enabled fridge magnet, you could write an application that would parse only those network packets that it was designed to handle and ignore the rest (and build and send only those packets that it needed to know about) but unless you have some programmers who are really skilled with TCP/IP,it undoubtedly costs less to just use a well developed general purpose stack such as Linux.
The per unit cost of slightly more memory/cpu power even for millions of units is still probably less than the amortized development costs (even without time-to-market costs that could be saved with an off-the-shelf stack), especially when there's no per unit cost for the OS - After all most embedded RTOS vendors charge a per unit license fee.
There is very little in the Linux kernel that can't be stripped out of a custom build if it isn't needed - and for an embedded device, that leaves very little overhead. On the other hand, nobody really wants to have to write custom drivers for standard components such as a USB hub.
I tend to think of Linux as a toolkit that you can pick and choose from. It seems the embedded developers have a similar view, with the additional ability for applications to query to see what was chosen.
Ok,
SET
I'm just about fed up with hearing blanket statements that some flavour of Unix/Linux etc. can't do hard real time without specifying (or probably even knowing) just what needs to be run as 'hard real time'. I've implemented many small, special purpose industrial systems over the years, and most of the ones that I have had to deal with had 'hard real time' requirements in the tens of microseconds range, and I've used some flavour of *nix for implementing such systems ever since Xenix on the 286 became available.
The things that Linux can't do is to guarantee that a user-space application will be able to respond to an external stimulus in some small number of microseconds, or will be able to access slow shared resources in some small number of milliseconds.
So what? By most definitions of 'hard real time' then even reading data from a serial line is a 'hard real time' application in itself - if you don't read the character before the next character arrives (or the buffer fills for modern chips) it will be lost - this is a 'hard real time deadline' but nobody questions Linux's ability to do this. You don't need an actual application to buffer each individual character though, This is done by the kernel driver i.e. in the interrupt handler.
Even with old minicomputer real-time operating systems (specifically Digital RT11) the OS couldn't keep up to sub-millisecond deadlines, so I wrote device driver routines to do the 'hard real time' functions.
Moving to *nix systems simply kept the necessity of a device driver to handle the 'hard real time' part of the application.
Similarly, for a lot of 'fridge magnet' applications, you don't need that high a level of real time application support - just a kernel driver for the actual physical I/O applications.
With a pre-emptable kernel, and NO USER APPLICATIONS, just the device's linux appplication code for things like a UI, TCP/IP stack and similar $20 device requirements, application response times can still be guaranteed within fractions of a millsecond.
Only when you get into systems with things such as user supplied apps (i.e. causes unpredictable running conditions) or resource contention (such as needing to prioritize file access on a slow device) does the application response time become unpredictable, and for the scale of many embedded (and even non-embedded) applications this is not a problem.
Very few applications (as opposed to device drivers) need sub-millisecond response anyway. Consider that when a human is involved in the loop, anything less than about 10 milliseconds of lag is not discernable. Despite the observation in software testing (and other things) that errors predicted to occur once in a million times tend to happen 9 times out of 10 (because there is no real 'random choice' in most software), absolute timing guarantees are not often needed. But 'soft real time' capability is a necessity for any UI to be usable. I'd be unable to type this if Linux couldn't do at least that much.
On the other hand, I've had to work with some 'hard real time' systems that guarantee absolute worst case 100 millisecond response - but cannot under any circumstance respond any faster than that!
A chance to compete in an emerging market (Score:4, Interesting)
Re:A chance to compete in an emerging market (Score:1, Informative)
Re:A chance to compete in an emerging market (Score:1)
Re:A chance to compete in an emerging market (Score:1)
This spec is a good thing! (Score:4, Interesting)
produced a simple range of embedded subsets of the
LSB, and carefully avoided inventing anything
of their own beyond a way to query for what
features are available. As a developer of
embedded Linux systems, I think the ELC's
standard is very good work -- suprisingly,
this is an example of a vendor consortium
that did exactly the right thing, engineering-wise.
- Dan Kegel
www.kegel.com
Wow (Score:2)
But I am just wondering, has anyone said they are going to use this specification or are they releasing it hoping someone will use?
Re:Wow (Score:1, Interesting)
Ahh... (Score:3, Interesting)
A large amount of new silicon is hitting the market; the line between microcontrollers and computers keeps blurring. Some of these chips (mostly intended for the cell phone industry) run over 350MHz, include large amounts of memory, flash, and peripherals. Linux is an excellent way to manage all of that power, and ease the transfer of applications into embedded devices.
You will have that communicator/computer you want: has all the power you need, projects onto your eye or a wall, responds to speech input, has excessive bandwidth, captures video, etc. It's within my lifetime. And with the help of some standards like these, perhaps it will run some variant of Linux. You never know.
The importance of Embedded linux (Score:2, Interesting)
Linux already satisfies the four most popular criteria: Real Time capabilities, royalty free licensing, it runs on a variety of CPUs and it provides access to source code.
No wonder Motorola choose [thestreet.com] for the linux solution.
Re:The importance of Embedded linux (Score:2, Insightful)
How is that? Surely you are not speaking of the great RTLinux hack? I mean RTLinux != Linux. It _runs_ Linux and can communicate with Linux, but as far as I'm concerned this is not a solution I would choose unless I _really_ had to use Linux for one reason or an other.
Linux itself is NOT real time and it will probably take a while (if ever) to achieve that. The kernel design is just not right for it (I'm not saying the kernel design is not right though).
Anyways, this has been discussed several times, and I think the most important thing here is that very few embedded apps actually need real-time behaviour. I've used Linux once in an embedded system and it performed beyond expectation.
But I wish people quit claiming Linux was real-time when it simply is not. Running an other OS which loads Linux as a sub-task doesn't make Linux real-time. And I really don't think you're going to fool any embedded developer.
Is the specification available in a free format? (Score:2, Interesting)
John Sauter (J_Sauter@Empire.Net)