Living in a Linux Embedded World 146
krow writes: "Embedded.com is running an article where the author is making some assumptions of Linux's use in the embedded markets based on the opinion of one consultant and the fact that Lineo had to lay off some people this year. It's still interesting reading though for some insight into a different world for Linux and there is a nice reference in the comments to the interview of Victor Yodaiken of RTLinux fame by by Kevin Fu on the ACM site."
Tivo (Score:2, Interesting)
The fact that other companies are failing is simply a factor of business, not anything necessarily having to do with the viability of Linux as an embedded platform.
Re:Tivo (Score:2)
Take for instance Axis's camera servers. Ok, we have what looks like a pretty compelling argument here gor the power of Linux (or actually ucLinux, but the 100lx processors do the real thing), what with straming video and all, but when you actually look at it, you see it's not just linux at work there. The processor is a joy to behold and that does help, and most of the video grunt work is done from an offboard mjpeg processor chip.
Linux works beautifully on this platform, because it was designed for it, and maximo kudos for the Axis lads for a real nice distro.
None the less, linux has some big problems with latencies. It's not tooo bad, on the etrax dev mailing list the other day, there was some talk of latencies, and *from memory* I think the 1ms figure was bandied about as achievable.
But for a lot of stuff, it's just too much at once with linux. There really is nothing like ripping out the old forth compiler chain and having exact hard realtime control over latencies and the like
It all depends on the app. I would not trust a cardiac pacemaker to linux, but I wouldn't want to make a mp3 player on VX-Works. It really depends on the app, and that all boils down to timing.
Kada (Score:5, Interesting)
It's a pretty strange coincidence. Today I had to get information about a company for Professional Communications class. I went to the library, picked up an IT trade magazine, and went to the section about emerging companies in the new year. There is apparently a company called Kada Systems [kadasystems.com]. That has created an extremely small JVM that can run very powerful applications on very small portable devices. Take that and your tiny linux kernel, and you're set.
Re:Kada (Score:2)
Re:Kada (Score:3, Informative)
I dunno about your left nut, or if there's a RT Java implementation, but you (and many people on Slashdot, I've noticed) have no idea what "Real Time Applications" are.
16 milliseconds to process a single RSA key?
As long as it does that utterly reliably, it could take 30 seconds to processes it - it doesn't matter. As long as the process can be reliably timed, and can be predicted to complete in a given timeframe, irregardless of any interruptions, task switching, etc. That's what real time means. Not "125 fps vs. 127 fps" or anything like that. A radar might have a refresh of 3 frames per second - but the system had better *damn* well be ready to process the input as it comes in.
--
Evan
Re:Kada (Score:2)
Ericssson's language, Erlang [ericsson.com], mixes garbage collection and realtime systems without a problem.
OK, admittedly a telephone exchange doesn't exactly have the same safety-critical problems as aircraft avionics or intensive care patient monitoring. Plus the Erlang GC system won't work for Java and remain real-time (it depends on each thread having a local heap so they can be GC'd separately). Still, it does show that the combination of real-time systems and garbage collection does work well, even outside academia.
Re:Kada (Score:2)
Even it's slow it can still be used in RT system. I recommend you to pick a book on RT and actually spend some time to read it before opening your big mouth.
Of course, I sure something sucking your left nut wouldn't be suited to run on any RT system.
Of course not (Score:5, Informative)
Most embedded componants that I know of use an in house OS. Where I work we bought vxWorks, but we are seriously considering replacing it with something cheaper. Not linux, something we write in house. It turns out that most real time systems cannot afford the overhead of a OS. Sure we need something to deal with hardware, and schedualing, and if you have networking it is nice to have sockets are similear. In the end though, a OS gets in the way more then helps.
In our particular case we have a lot of code to jump out of interupt context and then back in every 15 seconds. That really hurts performance. (Yes, we often want to spend more then 15 seconds processing interupts, with out hardware it turns out to be a good idea, though I don't want to give away why) Of course the OS clocks get all screwed up when we do that.
Re:Of course not (Score:1)
Re:Of course not (Score:1)
BTW, we're using vxWorks & C++ on PPC. Very good platform for development. We're looking at RT/Linux but are reluctant to make the jump.
A good threaded model should negate (abstract) the role of the RTOS.
Re:Of course not (Score:2)
Accually we do it differently. Because there is overhead in jumping to a ISR, once we get an interupt, we disable interupts, keep polling for more data until there is none for a while. Since we only deal with one data stream per processor, this isn't very hard to program, and allows us to get a lot of throuput.
Remember, for our application it turns out to work good, in general you are right, the less time in an ISR the better.
Re:Of course not (Score:2, Informative)
Except for very simple applications which can run as a single threaded application with interrupt handlers to perform processing, an RTOS is almost always essential. In fact, an RTOS with a correctly partitioned and architected application can be significantly more efficient than a single threaded application that has to periodically poll hardware or status variables. You don't want your protocol stack running in your interrupt handler, and polling to see if there's more data for the protocol stack is very inefficient compared to a context switch in an RTOS when data is actually available.
VxWorks may be overkill or may not be customizable to do what you want, but there are lighter solutions such as Nucleus, eCos (which is open source), RTEMS (BSD license), etc. These solutions are available for relatively small amounts of money. And this cost is a real win compared to the cost to develop and debug thousands of lines of "homebrew OS". And there's much more to the price of building an RTOS than just the developer time. Slipping a product by 3 or 6 months can cause the project to fail completely.
Even the ever-popular "write a homebrew abstraction layer" over a commercial RTOS is almost always a waste. It just introduces overhead, prevents the application from making full use of the underlying RTOS, and almost never makes porting to a new underlying RTOS much simpler.
In the meantime, it really sounds like your application has some serious architectural issues. If you're spending 15 seconds in your ISR, none of your other tasks (or lower priority interrupts) get to run. That's hardly "real time".
The more typical solution is to grab the data from the hardware and send it to a (high priority?) task to process. I find it very difficult to believe that running a single ISR for 15 seconds is optimum. On most systems I've worked on, that would trigger a hardware watchdog time-out.
Basically, it doesn't sound like you've got an competant, experienced embedded developer working on your project. You might consider finding someone to provide consulting services, or hiring someone with more background in the area.
Re:Of course not (Score:1)
It turns out that most real time systems cannot afford the overhead of a OS. Sure we need something to deal with hardware, and schedualing, and if you have networking it is nice to have sockets are similear. In the end though, a OS gets in the way more then helps
I've just started to poke my head into it, but eCos [redhat.com] (an embedded linux based OS) is a nice place to start when designing your in house OS.
From the linked page:
eCos provides engineers with maximum control, flexibility and understanding over all aspects of their embedded solution. eCos is highly customizable and adaptable, and can be easily configured using the eCos graphical configuration tool to meet application-specific requirements
It's used as the base for dadio OS (on my hipzip [iomega.com] MP3 player) and it looks like a nice little package with lots of tools for developers.
Proprietary does seem like the way to go, (After all, keeping things small is important, and it is likely that there will not be a general solution that meets your specific needs exactly) but it is also nice to work from a proven base OS instead of starting from scratch.
Re:Of course not (Score:2)
Do wxWorks interrupt handlers disable all interrupts? How odd. QNX interrupt handlers only disable the interrupt that was invoked (hardware permitting) precisely so that higher-priority interrupts can still be delivered.
Of course, I don't know why you're not just using the interrupt handler to wake up a thread which does the real handling, like a lot of real-time systems encourage. Presumably you have a good reason which you could tell me but then you'd have to kill me.
Embedded Linux Company != Embedded Linux (Score:4, Interesting)
The people who need the hand-holding which Lineo, etc. are trying to sell, those people are too conservative to choose Linux, they just go with the Microsoft of the embedded word, Wind River.
Re:Difficult (Score:1, Interesting)
Linux is based on Unix, which was origninally designed to be a multi-user Time Sharing System. Look at the early introductory papers about Linux by Thompson and that's what you will read.
For most embedded devices there is no need for multiple users. There is no need for groups. A lot of this can be pared out of the special kernel you need, but if that is the case, why start out with something as complex to start with?
Long Cycles (Score:5, Insightful)
Re:Long Cycles (Score:2)
Why some developers are running from Linux (Score:5, Insightful)
Unfortunately, if the many features of Linux and the transition from assembler to C didn't hurt us, the licensing did. Things went very smoothly until we needed to make some big changes to the kernel to accomodate a newer version of our hardware. At that point, there was a schism in the group: some of the developers wanted to change the kernel and release the product without source (the "who would find out?" crowd) and the rest of us knew that Linux was not going to fit our needs anymore unless we wanted to give our work away to competitors.
Well, the "who would find out?" crowd won the first round, and because of release deadlines we "slipped" the kernel changes into the next version of the product. And nobody knew. Except one of us told the legal department about what happened and they became very agitated.
Now our software runs on embedded NetBSD. It wasn't quite as robust as embedded Linux but it works well and we really can't complain. Transitioning to a new OS took a lot of effort but it was a necessary evil. After all, we couldn't risk getting sued out of existence to save a little money.
But the question I draw from this is: why not relax the GPL restrictions a bit for embedded applications? It seems like this area of the market will never be dominated by Linux until companies can stop fretting about licensing problems and start concentrating on coding instead.
df
Re:Why some developers are running from Linux (Score:2, Insightful)
Re:Why some developers are running from Linux (Score:1)
Because this is what you have to pay for using GPL software. You get Linux for free, so if you have to change it to fit your product, you have to distribute the changes, now you are even with the developers. I don't understand people who want to take something for nothing and use it for their own commercial advantage, they really don't appreciate the work that went into Linux. If you don't like the license then don't use it. I think even considering to use it without distributing the changes is sleazy.
If you want NetBSD, use it in good health (Score:4, Insightful)
I don't see a big problem with that, nay, I'd think it a good thing for there to be some diversity of licenses, OSes, and approaches.
Supposing there turned out to be some horrible situation where NetBSD turned out to have killer bugs for particular purposes, it's a good thing to have some alternatives. Or vice-versa, and the potential causes can remain "n'importe quoi."
I don't see any reason why it is forcibly necessary for Linux to be "dominating" the area, either. I would think dominance would lead to all sorts of Bad Results as it denied the availability of choice.
And as for licensing, if you're going to use Linux, that certainly has some implications on being mandated to release source code. If you reject that mandate (and there's some "ethic" behind it; the authors are unlikely to let go of this), then Linux obviously isn't going to be the right choice. Which makes it fortunate that the market wasn't dominated by Linux, as if it were, you wouldn't have had other choices like NetBSD.
Re:Why some developers are running from Linux (Score:4, Insightful)
Because if your company is the sort that takes the hard work of others, uses it for free, makes a profit they would otherwise not have, and does not contribute back the changes made, then your company is NOT the sort of company that the Linux developers want to be using Linux.
Linux does not exist to make your company richer. Linux does not exist to give your company a head start on other companies. Linux exists to help make free software pervasive and available for everyone. Your company is counter productive to the goals of Linux.
"If the price of your friendship is the loss of my freedom, then I don't want your friendship."
we should have a solution (Score:5, Insightful)
Lets say our company invents a device and plans to sell the device with Linux loaded terminal with Linux device driver. The hardware+software is our IP and we can't give it away. please don't lecture me of how everything should be free...etc. I know that, and I also like a roof above my head. Letting people download my driver for free from a FTP server doesn't quite pay my bills.
So the solution:
we need to have something like FSF or Linux Fund. If I want to keep my driver closed source say for 1 year then I pay a license fee for them (it can be a one time thing or royality based). The 'foundation' distributes the money as it see fit, funding developers, funding new projects..etc. After a year, I have 2 options
- release the source to kernel main tree and make it open. Now it doesn't matter as competitors can't abuse my work to overtake me.
- continue with closed source for another year and keep paying (may be revised) licese fee / royality.
This has best of both worlds
- I get to use a stable well maintained software (in this case Kernel). so I don't have to re-invent the wheel inhouse everytime.
- I keep my IP intact for a short period and at the same tiem paying for other developers efforts.
any one know any similar licences like this?
LinuxLover
Re:we should have a solution (Score:1)
There are a couple of choices:
1) Write Your driver as a module. Then You can release binary only.
2) Release the driver code. You're selling a box with software preloaded, not software. If competitors can whip up the same piece of hardware cheaper than You, then You have a problem, but that's not a problem with the software licensing.
I don't really believe that an embedded linux solution would really depend on the development of kernel code - or at least not the kernel code that can't be written as a module.
Now, I assure You that I do respect IP. I'm working on embedded solutions, too, and the customers have their rights regarding the IP. However, if they choose Linux and want to modify the kernel, they can either write a module or release the code. And they know it. They also know that they depend actually on selling the boxes and not the software - the software enables the box to function. The kernel mods are released - as are new kernel APIs and so on. Then, using those APIs proprietary software can be written.
Re:we should have a solution (Score:1)
However, there are always some design and coding guidelines that should help make the code readable. Sometimes the guidelines don't fit the situation, in which case exceptions should be documented.
The problem with releasing code is that without the spec, the code may well look like sphagetti. With the spec, it makes a lot more sense. Still, the code should have enough comments that it can be read and understood even without the spec, although then the big picture and many of the reasons for why the code looks like it does are lost. And, releasing the spec tells more about the company and it's software development than the code itself, so even if the code is released, the spec might not be released.
I'm not sure though what would the IP protection be should the spec be released.. Remember that the spec itself is protected by copyright, and as the spec describes the software, software written from the spec can be considered an implementation of the spec, and thus a work derived from the spec. If the spec is copyrighted and restrictively licensed (or not licensed for commercial implementation at all outside the owning company), could it be that by releasing the spec the company would gain better protection for the software, even in cases where the implementation is covered by an open license like the GPL? Could it mean that only the codebase released under GPL is open, and any implementation of the spec other than the GPL'd release is protected by the copyright?
IANAL. But that would be an interesting question to present to one..
Re:we should have a solution (Score:2)
No! Linux is NOT your companies IP. Combining Linux with hardware doesn't make Linux your IP either. Linux is owned by the developers that wrote it. They're giving you an unlimited royalty free license to use it but you have to agree to their terms, and one of those terms is that you share with others just as they shared with you.
Then perhaps you can go earn a living to pay for that roof over your head? What you're proposing is to take the hard work of others and reap the rewards. The GPL was designed exactly to stop this sort of parasitic behaviour. Linux was licensed under the GPL because the authors have at least some empathy with the ideals expressed by the GPL. If you don't like those ideals then DON'T BASE YOUR PRODUCT ON LINUX.
This is similar to the Alladin License. But although this license might suit you better, it isn't what the Linux developers wanted. The Linux developers wrote Linux to further their own goals, not yours.
If you don't like the rules then don't play the game. Complaining that you can't get your free lunch and sell it too won't garner you any sympathy.
Re:we should have a solution (Score:2)
For the record,
- I do earn my living (a comfortable one I might add) working for a small proprietary software company...so boo me! (so does Linus and countless other contributers)
- I love & use free software. I have contributed back aswell
I _DIDNOT_ criticize Linux for being GPL. I was looking for a system where
- developers who contributed get something back (in code form or other)
- if code contribution is not possible, then contributes get compensated in some way.
I was looking for first hand experience of any license or any organization like the above existed.
Right now I can use Linux as a development platform. But it is not suited as a 'delivery platform' b/c of GPL (assuming my project involves modifying kernel heavily).
SOme one poited out about binary only modules. That may be a good compromise. But I thought under GPL
"if your software (say the module) would not function without a GPL component (linux kernel) then the source code for the software should be distributed aswell"
did I read that wrong?
Again please don't flame me about GPL and 'free as in beer' concepts. I know them all, and I respect them. I am looking for suggestions, not whinings.
thanks
LinuxLover
Re:we should have a solution (Score:2)
And I gave you one: the Aladdin License.
If you expected this sort of reply then perhaps the problem is with what you wrote, rather than with the people who responded in the expected way.
Take a different perspective! (Score:4, Insightful)
Perhaps it's because all the companies that made extensions to BSD did not make their changes public?
It's this issue, the very issue you raise, that makes Linux the long-term sensible choice. You benefit from the work of other companies, and they benefit from your efforts as well.
Notice that your changes to the BSD kernel are not available to other indivuals and companies. Thus, your efforts do not contribute to the stability of BSD for embedded applications.
The "Share and share alike" philosophy of Linux is the heart of the Linux movement, and your suggestion to "ease up" would represent the very death knell of its forward momentum.
It's really a question of "Pick your poison". Which flavor do you prefer? You can either A) leverage the efforts of others and let them leverage off of yours, or B) Go your own route.
Either route has its advantages and disadvantages - but don't complain when you can't have it both ways!
-Ben
Re:Why some developers are running from Linux (Score:1)
I'm now working privatly quite some time on some free software apps. My experience on how many people are really interested in the code were depressing.
Put your modification on a ftp server, or ask them in the user manual to request it per email. After all your competition first has to buy a product from you, than has to tell you that it did so, and than request the source changes, and than has to find them usefull at all.
Okay if two competiting companies run linux on the same processor type I can imagine that you want to give away your changes at the last moment as possible. But as long they run a different os or a different cpu only, they will find your patch worth nothing. Giving it to puplic will not hit your competiting advantage.
Getting it in the torvalds kernel is a task itself, and you must be really after it if you want to see a patch in there. If you're just selling a device and a patch with it, there is in reality no way it will find it's way in linus' kernel
A better question (Score:5, Interesting)
Re:A better question (Score:1)
Remember that this is an _embedded_ system, which is usually _not_ the same as taking a desktop OS and slapping some user-space application on it.
Frankly, as an embedded developer, I do not see the great value of using Linux over *BSD in embedded space (unless you use some hardware that no BSD supports); the license alone is an enormous turn-off for any company that needs to modify the kernel (see above) and does not want its competitors to get a glimpse into its code. And in any case, if you need true real-time, you'd be MUCH better off with LynxOS or somesuch rather than some half-baked Linux-RTOS microkernel solution; you'd be getting better POSIX compliance, and TRUE REAL TIME, from an experienced company.
And as far as real-time is concerned, Solaris and IRIX have had true realtime capabilities (for userspace processes too) for years. Linux is still a toy OS compared to commercial offerings in embedded (and, dare I say it, server) space.
Re:Why some developers are running from Linux (Score:2)
first, your changes, what your company wrote, like the modules for the linux kernel you needed were not required to be released, TVIO did this and they released everything BUT what they did. Now of you guys just changed a driver a bit and were worried that your competition would instantly take your idea and make billions is plain stupid. your competitors are not greedily watching you for a slip to run with, they are quite busy themselves. if you made a drastic and innovative change to the kernel then cool, dont release your innovative code, why? because you DONT HAVE TO unless your innovation was not really an innovation but a change to someone else's GPL'd code. otherwise release the minor changes and be a good open source citizen.
Re:Why some developers are running from Linux (Score:1)
The PS2 Linux port (Score:1)
He's Right (Score:5, Insightful)
I'm an avid Linux user at home but for fault-intolerant real time systems, I would feel a bit uneasy recommending Linux for an embedded system just yet. Once I go 6 months without a story on
Re:He's Right (Score:1)
Bet you MONEY that there's comments like that... (Score:3, Insightful)
Re:He's Right (Score:4, Insightful)
Just because you've never seen the [insert proprietary OS here] source code doesn't mean that it is any better than Linux's. The fact that you can see the hacks is actually a *benefit* of Linux.
Re:He's Right (Score:1)
Those are small and very clean, in my experience.
Re:He's Right (Score:1)
/* This is a Hack */ in non-open code (Score:4, Funny)
There was a famous comment in the SunOS proc.h header file that said something like /* Please forgive me for this hack */
And I've seen plenty of commercial code that should have had comments like that, but didn't, which is a whole other kettle of fish.
Re:He's Right (Score:3, Insightful)
As opposed to a kernel that still has those issues, but you don't see them because you don't have the source code? All code has its less than pristine spots. At least with Linux, those places are documented and more likely to be changed by the large cadre of people working on the code. Your "sense of well-being via obliviousness" stance might be personally satisfying, but it does not, in and of itself, guarantee a better system.
If you want to bash Linux as an RTOS, there are a lot of other more appropriate technical factors to bash it with. Your aforementioned statement is not one of them.
Re:He's Right (Score:1)
Re:He's Right (Score:2)
First, have you seen 'hacks' in other source code? If so, were they labeled as such? If not... Well damn. That's impressive.
Second, how responsive are other OS developers for making changes in their source?
(Not trying to flame. I realize it can be taken that way. I really want to know if things are THAT different.)
Re:He's Right (Score:1)
If not, how can you possibly know that there's not lines like:
/* I hope they never really want to try this */
In the source?
>Most companies won't go with Linux because of the fact if something breaks they can't submit a bug report and withhold payment until it gets fixed.
Yeah, I'd like to see a company withhold payment from a software company till a bug is fixed.
I'd still not have paid for Windows 95 yet if this were possible.
>We don't hire OS programmers for the very reason that we buy our OS, we're DSP engineers.
Here's a quick question:
How much do you spend to "rent" your OS? Is it less than getting a programmer part-time to fixup the Linux kernel to your specs?
Just wondering.
>Once I go 6 months without a story on
When I go 6 months without a vendor lieing to me that their software is A-OK I'll start purchasing more closed-source software.
Re:He's Right (Score:1)
I think you've hit the nail on the head there - that quote is definitely sigworthy.
Of course, you could have the worst of both worlds - use a popular embedded Linux vendor's product, but when you want the source they give you the runaround and a month later I still haven't gotten it. I'd name names, but since I work for another arm of the same far-flung conglomerate that they do, I'm afraid that I can't.
My advice on embedded linux: use it if it meets your technical requirements, but get the source up front when you get the binaries, and verify that the source really does produce the binaries. Don't wait 'til crunch time to find out that getting the source isn't as easy as you would have thought.
Re:He's Right (Score:2)
#include
/* This is a hack */
main ()
{
Re:He's Right (Score:1)
I'd worry more about comments like these...
/* printf("Welcome to Windows 3.1\n"); */
/* printf("Welcome to Windows 95\n"); */
/* printf("Welcome to Windows 98\n"); */
printf("Welcome to Windows 2000\n");
So it's facing reality that's the problem. (Score:2)
The reason Linux (and other OSS software) has so much trouble being accepted is that it forces you to face reality.
So comments like
Or submitting a bug report and - snicker - witholding payment until it gets fixed. As if any proprietary vendor would ever let themselves get roped into a contract where customers could not pay if the software had bugs. That's pure fantasy on your part -- and yet I've heard the same argument repeated as to why they wouldn't choose Linux. But since Linux doesn't let you pretend that you can hold someone accountable it gets rejected.
In a way, it's the same with the whole UI problem. People will tell me how easy to use Windows is, and I'll sit next to them and listen to them cursing as it does things they don't expect. But Windows keeps telling you it's easy to use, so they can pretend it really is. Linux doesn't try to trick you that way, so they can't let themselves be tricked.
Okay, that was starting to get off topic, but it is related I think. Stop fooling yourself -- if something works for you, then fine, but don't prop up the system with self-delusion.
Converse question (Score:4, Insightful)
Let me tell you, about 80% of the Linux jobs out there are asking for embedded experience as well. If Linux is hot anywhere, it's in the embedded market.
Now, it may just be that embedded is hot and, because I'm not searching for it, I never see the non-Linux ads. That doesn't change the fact that nearly the only Linux ads I see are for embedded stuff.
Linux's Slow Approach (Score:3, Informative)
I'm a platform agnostic. Sure, I'll ask people "why are you running Windows?", but I don't then immediatly plug Linux as the grand solution.
New users -and casual users- need Windows (or a Mac) so they don't have to worry about the details of configuring the system. Learning exactly how PnP works isn't something they are interested in. As long as the only thing they use the computer for is simple tasks -write letters or surf the net- Linux isn't for them.
And on the embedded scale, much the same applies. I use a Handspring Visor; all because I want a OS on my handheld that <i>gets out of my way</i>. The OS needs to pull up whatever app I need- be it the calendar or notepad or whatever- and then dissapear- because the more memory / processor / battery power needed, the more it costs, and the less I want it.
No system can be applied everywhere in the computing world and be the best solution everywhere. Linux has its' issues dealing with new users and embedded systems; this is not a flaw. Where Microsoft has failed is trying to write a system that can be used everywhere. It won't work; IMHO it <i>can't</i> work. Let's not drive Linux down that same road.
Re:Linux's Slow Approach (Score:1)
As long as they have to maintain it themselfs. But beeing an expert you're normally usually target for maintaing your friends computer. Recently a relative, who was totally unaware of computers asked me to indroduce him to it. And against all window users advice, I installed linux for him (with KDE), yes I installed everything for him as he is a complete new comer. (would be the same with windows). I showed him how to start the machine, how to shutdown, how to write emails, how to use konquerer to surf, how to use sysgard to kill hanged ups, etc. etc. Sure he hasn't seen a bash, and I didn't show it to him, but actually he does not need it. Do you think the KDE desktop is any harder to use as a windows desktop? Really not even a bit harder anywhere? And in contrast to windows if he calls me having a problem, I just have to tell him to go online, and can ssh into his machine looking what's going on.
Why the big fuss (Score:2)
But why the big fuss over Linux? As the article (or maybe a comment afterwards) mentioned, to get one of the RTOS distros/modifications costs money. So the licensing is a wash.
Except for some specific platforms, it's hardly optimized. So there is a great deal of vendor specific work to be done. So, marginal time savings, if any.
You aren't going to run Samba/Apache/LICQ on an embedded device, so the software availability doesn't really matter.
Now, the comment from the guy from Intel seemed to make sense: in certain areas on certain hardware, Linux is a good thing. Unfortunately, this article is largely a waste, as it ignores the breadth of embedded systems, and attempts to paint the entire Embedded Linux effort with one stroke. Were the author to say that one processor with one OS were the end-all/be-all of embedded systems, he'd get laughed out of a job (one would hope).
Saying that one OS has no/little place in embedded is merely the other side of this ludicrous coin. (BTW, again, I know next to nothing about embedded systems. If I can pick up on these glaring flaws, why should anyone give this article the time of day?)
Real-time systems (Score:1)
There is a problem with running any variant of UN*X with a real-time system: the fact that it is possible for any process to be interrupted for an arbitrary and unpredictable amount of time. You can play games by using nice with negative values to reduce the probability of this happening, but you can't be 100% sure.
Of course, "real-time" is poorly defined, and "embedded" is even worse. Nevertheless, in practice, these fuzzy blobs seem to go together. Embedded systems tend to need to be real-time, either because they are in an application that absolutely demands it (engine computer, perhaps) or the hardware on which they are running is so wimpy that time irregularities people wouldn't notice on much faster systems would be a big problem.
Probably, big chunks of Linux, suitably hacked, would form a good basis for a variety of embedded devices. The kernel is already small, and it would be smaller. However, just taking the kernel per se and building an embedded application on top of it is a bit like the tail wagging the dog.
Re:Real-time systems (Score:3, Insightful)
Actually, I believe Solaris has kernel extensions which can be used to garuntee a process a minimum amount of runtime. But I could be wrong.
I agree with most of your comment, though. Although "real-time" has a very good definition (A real-time problem is any problem in which the time taken to arrive at the answer is part of its correctness) people abuse the definition horribly. Embedded has no agreed on meaning.
This reminds me a bit of the previous slashdot article on "XP-embedded". That's the product I think Linux has a chance to beat. High reliability, fat budget systems--embedded but not really real time.
Oh--and I am an embedded developer. I love Linux. But 60us interrupt latency on a 800 MHz CPU* just ins't acceptable for a hard real-time system. If it means a compression artifact in my Tivo, no problem. If it means 60 kb of data loss from my Gigabit ethernet card, that's not cool. If it means none of my avionics systems respond for that long, it's out of here!
*The guy says "Pentium" which is probably incorrect--I don't think they ever clocked those old chips that high. Not a very good author.
Re:Real-time systems (Score:1)
Here's my old-fashioned list of the characteristics of an embedded system:
System has a dedicated function (not general purpose)
Real-time
Code executes only out of ROM
Scarse resources
Code rarely updated
Can be implemented in non-assembly langauge only if you're lucky
Can use an OS only if you're very lucky
The use of desktop operating systems like Linux or Windows wouldn't be appropriate for embedded systems given this list. Of course, the list is too restrictive for today.
I think the new definition of embedded SW is really "any software not running on an established hardware platform". This robs from the term "embedded" any unique characteristic, so I think there isn't much value left in the word.
Re:Real-time systems (Score:1)
System has a dedicated function (not general purpose)
Real-time capabilities for some systems
Scarse resources (relative to general purpose systems)
Code rarely updated
Code stored on ROM, Flash, etc., not disk based.
The parts about assembly language and operating systems I think are now obsolete. Resources are still scare, but there are plenty to write in C and have a small operating system to do scheduling and memory management.
Solaris and definition (Score:1)
Actually, I believe Solaris has kernel extensions which can be used to garuntee a process a minimum amount of runtime. But I could be wrong.
I don't know that I'm not wrong either, so I asked the local Solaris guru. He said that later versions of Solaris provide prioctl, which is somewhat better than nice, but that he hadn't heard of any kernel extensions that provided guarantees or any way to make such guarantees to the process. I looked at the description of prioctl in his book, and while it contains some hand-waving about "real-time" processes, it falls short of making any guarantees.
Although "real-time" has a very good definition (A real-time problem is any problem in which the time taken to arrive at the answer is part of its correctness) people abuse the definition horribly.
That's a good definition, provided that it is clear we are talking about wall clock time. Unfortunately, it's a bit like the definition of "gender" (a grammatical marker in the sense that person and number are markers); nobody really pays much attention to it.
Re:Why the big fuss (Score:2)
The thing with embeded linux is there are low overhead versions of many of the nice bits in linux. Boa for web serving does much , including php! , that Apache does, busybox provides a near complete unix toolkit, samba does infact work with soem massaging.
None the less I agree that the article was a little narrow. Linux is clearly inappropriate for some ultra precise RT work, but it's a winner for a lot of consumer stuff like hand helds and the like.
VX-works is really a winner for
maybe RTEMS (Score:3, Informative)
My embedded projects usually don't need virtual memory or processes, just memory protection and threads. So Linux is overkill as well as being too slow.
On the other hand, the driver sources, the libm and libc, have all been useful starting points for either roll your own, or extending another RTOS.
If this sounds appealing, and you need an RTOS, look at RTEMS [rtems.com] an open source RTOS with many ports.
It's a matter of education (Score:5, Interesting)
Like so many things in the computer world, there is a need for education in the Real-Time embedded arena. When I was at the Embedded Systems Conference - Boston 2001, Red Hat's CTO gave a presentation on Embedded Linux, and touted RTLinux as the up and coming 'official' Real Time approach. In a later discussion with him, we agreed what everyone seems be missing here
Most embedded systems are *NOT* hard real time systems. For those that are, there it the RTLinux wrapper that runs Linux as one of it's (lower priority) processes. Yet the people writing for sites like this have no clue and spread FUD, which the unfortunate reader often mistakes as factual.
Will Embedded Linux ever be popular? It all depends on if the Embedded Systems Engineers ever get properly educated as to what it can do, and how. The only real drawback is footprint size. If you need your embedded application to be small and run on 8-bit Microcontrollers, then Embedded Linux clearly isn't for you. However, for the vast majority of serious applications, Moore's law continues to make Embedded Linux a more and more viable solution if the Engineers start addressing the learning curve. Of course, first, they have to know that such an effort is worthwhile. With FUD like this article spreads, it will unfortunately be longer until people get it. No big surprise here. Almost everyhting worth while gets early adopters, goes on hiatus, and then comes back as the new latest and greatest thing that everyone always new was going to fly. You gotta love the cycles of life!
Rewriting from Scratch... (Score:2, Insightful)
VY: The current version is the result of three total re-writes and there is a new version in the works. The number of minor revisions is much larger than three.
Heh... In a sense, this is a nice retort to the interview with the former Microsoft PH manager, whose interview was recently published on Slashdot. Sure, rewriting from scratch is a mistake. Whatever.
the "Linux is doohttp://slashdot.org/med" mantra (Score:4, Insightful)
Linux is doomed in the enterprise...
Linux is doomed on the desktop...
Linux is doomed in the embedded device market...
How long have all of these other RTOS's been in use and development? How long has Linux been an option it this field? A company that is making good money developing under an RTOS they've been using for years and know every quirk of isn't going to switch to Linux overnight just because it's cool. In the long run Linux may provide some advantages that will give it a better market share, but to suggest it is doomed because it hasn't been an overnight success is ludicrous.
The funny thing is that Linux can't ever be doomed because it will never go away. If Microsoft is blown up tomorrow by a government backed anti-trust commando squad, Windows will cease to be. But Linux, being GPL'd will continue to go merrily along no matter how many people conduct bad business ventures around it. I'll believe embedded Linux and enterprise Linux and desktop Linux are doomed when Linux goes out of business. Oh wait, it can't
It's Overkill (Score:2, Insightful)
Layoff-based reasoning. (Score:5, Funny)
Didn't @Home go bankrupt? The Internet must be dying.
FedEx has a hiring freeze; oh, no, people must be using the Post Office more!
Re:Layoff-based reasoning. (Score:2)
Really? they've a hiring freeze? I just saw the ads saying that FedEx will look for competent people everywhere in the world and hire them. Damn, I was beginning to believe them....
Use QNX for embedded work (Score:2)
I can't see running Linux on anything that doesn't have a hard drive.
Re:Use QNX for embedded work (Score:1, Informative)
Then you can't see much... (Score:4, Insightful)
No, I'm not saying Linux is a panacea for embedded system designs, but QNX isn't the ultimate answer either. For things that QNX is a good candidate for, choose it, or the open sourced RTEMS (Which does a very good job of the realtime things). For everything else, why spend the cash on something that you'll never use even 10% of the functionality of?
Re:Then you can't see much... (Score:1)
Yup, cool stuff.
Re:Then you can't see much... (Score:1)
on a floppy ...Re:Then you can't see much... (Score:2)
by the way, if you metion floppy systems you should that a look at the QNX demo disk [qnx.com]
Re:on a floppy ...Re:Then you can't see much... (Score:2)
It boils down to what you're calling embedded systems. And Linux IS used quite a bit up higher on the food chain. I know, I have been using it for years in the context of embedded systems.
Re:on a floppy ...Re:Then you can't see much... (Score:1)
I know, I know. They started on a 486,telling that it most of it fit in the 8kb cache.
Realtime Linux implementations have all of these t (Score:1)
So does an implementation of realtime linux:
http://os.inf.tu-dresden.de/drops
http://os.inf.tu-dresden.de/fiasco
http://os.inf.tu-dresden.de/LinuxOnL4
So does the DWCS scheduler for Linux Systems:
http://www.cc.gatech.edu/~west/dwcs.html [gatech.edu]
Huh?
Huh? The Linux kernel is also ROMable. If you want a microkernel (something I think is a bit wasteful in something like an embedded system), go back up to that fiasco link I put up on top.Success story (Score:5, Interesting)
In fact, RT guy *regularly* slams anything that doesn't have adequate RT support, so I am left to assume that he deems to have a set of RT capabilities which is more than adequate.
We're a small company, and running (like everyone else) under some rather tight fiscal constraints.
AFAIK, linux is what is currently saving our collective bacon -- if we're going to compete with the economies of scale of the big boys (not to mention their 'Deep Pocket Error Correction Algorithm') we can't afford to license some proprietary OS or development environment and pass that cost on to our customers. We have to be clever; therefore, we use Linux.
(Aside: I wish I could provide more details, but really, I'm more of a CS geek. My ideal level of abstraction is somewhere just south of lisp and north of Java. Assembly makes me go *bew*bew*bew*bew* (imgine index finger oscillating in front of lip). )
Re:Success story (Score:1)
I recently attended a talk in which a NIST (National Institute of Science and Technology) guy spoke about his criteria for evaluating a realtime OS. He basically said that he's tested and evaluated every realtime OS under the sun and to him, RTAI (another realtime linux variant similar to the RT-Linux implementation Yodaiken worked on) is one of the best real-time OS's one can get on intel hardware. The worst-case numbers just about proved this to him. Really it was quite an interesting talk.. a lot of fancy statistical gymnastics goes into evaluating a realtime OS, and RTAI came out ahead.
Embedded Linux isn't doomed quite yet... (Score:4, Insightful)
Most engineers that are shopping for an embedded OS want an "out of the box" solution for their embedded device. They want to simply be able to pay X number of dollars and get an OS so that they can quickly move on with their embedded software development. "Generic" embedded OSs, such as WinCE, are indeed a quick fix to that problem. Those same "generic" solutions also lock your project into continous OS licensing costs for the lifecycle of the project, a kernel that can't be touched for optimization (at least, not without paying a hefty fee to the OS manufacturer), and often require larger system resources to compensate for being generic.
Linux offers a unique alternative to these three problems. By leveraging against the open source development of the Linux kernel and the GNU POSIX APIs and OS structure, licensing costs for the OS can be considerably less per device (if you pay any licensing costs at all), simply because the licensing isn't priced to recover the hundreds of thousands of man hours put into developing Linux and the GNU toolchain. This can potentially turn a software cost of tens of dollars per unit into a few dollars per unit. When dealing with high volumes of product, this savings can be quite considerable.
The Linux kernel can most certainly be optimized. Whether your organization optimizes the kernel itself (and you will have the kernel source code, thanks to the GPL) or if you pay another organization to do it, you won't find yourself staring at a kernel that is a black box. And make no mistake... you will need to optimize the kernel in some manner for your embedded platform. Many companies choose to leverage their savings on OS licensing costs towards kernel customization costs (i.e. spend less money on the OS and spend more making it BETTER). Also, if you are using Linux as an OS, you aren't left "holding the bag" if your embedded OS manufacturer goes out of business. Switching OSs can be an extremely costly process because it precipitates a porting processes of the embedded software as well.
A generic Linux kernel straight out of a RedHat distribution will, as Mr. Ganssle has stated, require too many resources of an embedded device. That is why customization work is needed. The core of the kernel (memory management, process management, etc.) needs to be customized, and other portions of the kernel can be removed entirely in order to perform the needed optimizations. You certainly wouldn't want to put Windows 2000 on a simple embedded device... the required hardware resources would most likely be inflated in order to support the OS. In the same way, you wouldn't use a generic Linux kernel.
The Linux embedded space is poised to explode in the near future, and I'm glad to see it happening. The Linux kernel lends itself well to customization, and the GNU toolchain offers a low-to-no cost alternative to expensive development tools, such as Tornado (VxWorks) or Microsoft Visual Studio. All in all, it looks like a bright future for the penguin.
Free software on free hardware (Score:2, Interesting)
We have a project to develop free hardware designs to which free software is being ported, with no corporate backing. For an example of an embedded controller to which Linux is being ported, look here:
http://freeio.org/library/toast.htm
Development kits for college students? (Score:3, Interesting)
Embedded does not always mean small! (Score:2, Interesting)
What many people are overlooking is that embedded systems are not necessarily small...they're just embedded.
The project I'm with at work is a phone switch. We've got dual boards, each with dual 100Mb ethernet, quad serial, fiberchannel, a 450MHz G3 cpu, and a gig of RAM. They run linux.
We looked at QNX, but they would make the required changes to their memory mapping to support our app. We considered Montavista, but decided that we didn't need what they were offering. The kernel mods that have original ideas (intellectual property type stuff) are segregated into a loadable module so that it doesn't need to be GPL'd. All the other incidental stuff will of course be made available to our clients as required.
The biggest advantage of using linux is the sheer user base. Except for the really far-out stuff, almost any normal issue has already been dealt with by someone and its just a matter of looking it up.
While the companies that specialize in embedded linux may not be rolling in the dough, that doesn't mean that there isn't a lot of work being done. It may be that companies have simply decided that they can hire a programmer (or a team of them) for less than they could licence a product from another company.
When linux is embedded in everything (Score:1)
The car is just a variation on the DVD player which is just a variation on the space shuttle.
Do you think power tools and space shuttles will find much in common to talk about?
A success story (Score:2, Informative)
You may remember these guys from LynxOS. This RTOS (in true defintion of the term -- not in the LinuxRT version) runs on countless embeded platforms. Ever setup a JetDirect card on an HP printer? That's LynxOS.
Well, these guys are doing a lot with Linux now. I attended a talk about two years ago, right before their product BlueCat [lynuxworks.com] (strikingly similar to RedHat, eh?) came out. My information may be out of date, but some of the stuff the guys talked about was very cool. An embeded tool-chain. Boot loaders. And most interesting source (and later binary) compatability with LynxOS (by which I mean that LynxOS would run Linux source). To quote from the web page: BlueCat Linux applications can be migrated to the LynxOS platform with no loss of functionality and with minimal effort or delay. LynuxWorks development tools support both operating systems so there are no new tools to purchase and no new learning curves. This all means that customers can develop using BlueCat Linux and then quickly migrate and deploy applications to LynxOS when real-time needs emerge. Anyway, as I said, my info maybe out of date, but these guys shouldn't be overlooked. Oh, and for all who are wondering, I am in no way connected to this company.
Give us a good platform for it! (Score:2)
Me, I'll take a cheap 386-class processor in a handheld, 32 megs ram, some flash, and I'll slap Linux on it. I'd love to compile gcc on battery power and have it not be on a laptop.
Re:Give us a good platform for it! (Score:2)
Re:Linux everywhere, but why? (Score:1)
Re:Completely Offtopic, but anyways... (Score:2)