Dumb question on embedded Linux - why?

I am seeking to get into RTOS/embedded development for reasons of career development and general geekiness. As I look through job listings I see mostly references to embedded linux and VxWorks.

Embedded linux seems to be a natural destination if you are already into Linux, which I'm not, but I did just install it and it does seem quite useful for everyday activities (e.g. things not requiring Windows-only sw). The development environment seems abundant although I am used to Windows stuff like Visual C++ which holds your hand quite a bit of the way, and does have a number of useful features. One thing I thought would be relatively easy under Linux would be to set up a wireless MP3 player that got its media from a different server.

However, for the purposes of getting some hands-on learning in RTOS, I'm not sure that EL (for short) is a good first step. Too much is already accomplished so it's just a matter of putting together some drivers and trimming down the kernel to bare minimum for the purpose at hand.

What I'm interested in doing for the sake of education is to write some different apps, e.g. TCP/IP routing or just some do-nothing but pass data around apps to see how various changes in task priority affect interrupt latency, etc.

I also looked at freeRTOS which seems interesting, though I'd have to get a development board which also offered a C-compiler tool. freeRTOS is more of a bottom-up, start with the skeleton and write all of your own drivers for hardware, if any are needed (with rare exception for one supported NIC).

Ultimately my questions are:

If you are using EL currently, was that choice made to leverage everything that's already been accomplished for "desktop" Linux or some other reason?

What are the reasons to choose something other than EL?

Better responsiveness? More powerful development environment available? Smaller resource footprint?

I realize these are wide open questions. Btw I am running Firefox under Damn Small Linux to write this, that's pretty incredible! No hard disk required at all. Worked the first time I tried it too!

Thanks,

Gary

Reply to
Gary
Loading thread data ...

Answered most of my questions by scouting the WWW for awhile.

Now I don't know why you would NOT want to use EL.

Reply to
Drily Lit Raga

Industry loves standards. They provide common tools, common interfaces, common building blocks and common understanding. They make life easier. They provide a framework for innovation. Linux is fast becoming the industry standard for embedded systems.

Putting pieces together is what design is all about. Putting together large, more complicated pieces (as with Linux) is just as rewarding and just as challenging as putting together simpler pieces. The difference is that you end up with something more sophisticated, more quickly.

Dan

Reply to
Dan N

1) Lack of resources? [It's pretty hard to run Linux with 40KB of RAM and 132KB of ROM.] 2) It's not real-time? 3) You've got application code that was written for another OS? 4) You don't want to deal with distributing source code for GPL'ed software?
--
Grant Edwards                   grante             Yow!  Gibble, Gobble, we
                                  at               ACCEPT YOU...
                               visi.com
Reply to
Grant Edwards

Seems like 2 MB ROM and 16 MB RAM practical minimum for EL from what I've read?

It's not a pre-emptive multitasker? Or is there some other specific aspect of it that prevents it from being RT (trying to learn all this)?

OK.

Will look into what this means.

Thanks,

DLR

Reply to
Drily Lit Raga

That sounds about right.

Yes.

Linux doesn't guarantee latencies between events and the handling of those events. The latencies caused by the kernel have been greatly improved recently, but it's still not suitable for hard, low-latency, real-time projects.

--
Grant Edwards
grante@visi.com
Reply to
Grant Edwards

If you change any GPL software, or link to GPL libraries, you need to make your software sources available to others. Also, if you write any device drivers for custom hardware, you *might* have to make those sources available too (this is a bit of a grey area).

If the above causes any problems, you could look at one of the BSDs, for example NetBSD, which has been ported to a lot of different platforms.

HTH

Paul.

--
Remove _rem_ before replying by email.
Reply to
Paul Taylor

But it still gets used in "real-time" applications, being "good enough" because a modern-day CPU has plenty of raw speed. Of course if you want that on a PIC I don't know....

Reply to
Drily Lit Raga

It's good enough for some applications, not for others. A buddy of mine recently worked on a project where they had to ditch Linux because the latencies were just too large. IIRC they switched to LynxOS.Since it has a Linux-compatible ABI, they could just re-compile the applications and go.

That depends on the application and on the CPU.

No, I wasn't expecting to run Linux on a PIC.

--
Grant Edwards                   grante             Yow!  ... A housewife
                                  at               is wearing a polypyrene
                               visi.com            jumpsuit!!
Reply to
Grant Edwards

by the way there is a realtime extension for Linux: I personally never tested it, but it stay in a layer under the kernel.

bye giammy

-- Gianluca Moro

formatting link
ISCRIVITI alla Mailing List Italiana su LINUX EMBEDDED snipped-for-privacy@yahoo.com Visit
formatting link

Reply to
giangiammy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.