Well, here's my list of embedded Linux challenges: 1) It's too complicated to implement quickly on anything other than a X86 desktop-equivalent system. There is so much going on. I've studied embedded Linux, and I still don't have all the pieces assembled in my mind. I could eventually get it all in my head, but I'm a hardware guy, and I'm already on overload with the other stuff I have to know: C, asm, VHDL, etc. That's in addition to the hardware design knowledge that I have. If I had infinite time, I'd learn it all. But I don't. Ubuntu Linux on a desktop X86 is great, but that's because the X86 desktop world is well targeted and supported. Once you stray from the well worn path, you are very quickly surrounded by the jungle!
2) It can take a lot of work to make Linux run on resource-constrained systems. It would be nice if we always had 3GHz CPU, 2GB RAM, and 100W power budgets, but we don't. 3) Lack of truly good complete documentation on how a Linux system works from the ground up. You can find numerous books and on-line info on pieces of it, but I've never seen a tutorial covering it all. And so many tech books are bulked up with fluff, there is not enough time to read them all to put together the knowledge base that is needed. I would like to see a book that puts it all together in excruciating detail. An outline would be something like this: I. CPU reset vector jumps to initialization code in ROM, flash, etc. II. Init code prepares RAM for use, sets up a working stack. III. Init code scans storage devices for a bootable image indicated by a boot signature. IV. Once boot signature is found, init code loads the boot loader from the storage device into RAM. V. Once the boot loader is in RAM, init code jumps to it and execution of boot loader begins. VI. Boot loader scans storage devices for a OS boot image or boot manager (LILO, GRUB, etc.) and loads it into RAM. VII. Once the boot image or manager is in RAM, jumps to it and execution of boot image or manager begins. VIII. Boot image or manager scans storage devices for an OS kernel image and loads it into RAM. IX. Jumps to OS kernel image and OS initialization begins. Somewhere in here a shell script interpreter starts up. X. OS Hardware Abstraction Layer (HAL) scans for attached devices and loads their kernel modules and initializes them. XI. OS shell executes /etc/init (Linux) scripts to initialize software services and escalate run levels. During this time is when networking and GUI services start up. This is also where embedded systems would start the "embedded application". XII. If this were a desktop, a text console or X11 console would be started for user interaction. Did I miss anything? I don't know, I'm no expert on Linux. But what I've outlined has been hard-won knowledge. I haven't found it all in any one book or website so far. 4) Often, starting from fundamental units of functionality and designing bottom-up is easier and faster than taking something big and reducing it (top-down). Design only what you need, don't hack away on something big. 5) GPL license means you have to consider carefully all the licensing issues, and how they fit with your embedded application. BSD license is more liberal. So maybe BSD is more friendly to embedded systems? 6) Super expensive Linux development systems. Linux is free, but the embedded Linux OS vendors seem to think that we are interested in paying tens of thousands of dollars for a free OS. And that we want to pay this amount over and over again as we develop new products. The "per developed product" license terms are absurd. I'd be willing to pay up to a grand for a development system if I could use it on as many products as I want to, with no recurring expenses. Those are my terms - no one has stepped up to the plate yet. 7) Overly complex development tools. This is even true for non-Linux systems. I recently bought an Atmel AT91SAM7XC dev kit, which uses the Eclipse tool chain. It's really too much to ask for a hardware guy to learn a big software tool such as Eclipse. Especially since Eclipse has so many different implementing languages. It's written in Java, but the dev kit has Tcl and bash scripts, runs in a minGW compatibility layer, etc. Guys, I'm trying to design an embedded system written in C here, not learn 3 new languages just so I could fix bugs in the Eclipse development environment (which I had to do just to get things to compile). Were those enough reasons? I'm not down on Linux. I like most things about it. If improvement is made on the areas I mentioned, I might use it in an embedded design. Best regards, Ivan Baggett Bagotronix Inc. website: www.bagotronix.com [EMAIL PROTECTED] wrote: > I just read an interesting article in Embedded Systems Design that seeks > to see the underlying embedded market. In it, it indicates that the use > of Linux by engineers is falling quite rapidly. I'm wondering which > specific challenges others in this group might be facing when attempting > to use the Linux environment. > > Thanks, > Andrew J Jenkins > Avtron Manufacturing Inc. > v: 216 642-1230 x1228 > f: 216 750-5105 > [EMAIL PROTECTED] > > There are in fact two things, science and opinion; the former begets > knowledge, the latter ignorance. > Hippocrates (460 BC - 377 BC) ____________________________________________________________ You are subscribed to the PEDA discussion forum To Post messages: mailto:[email protected] Unsubscribe and Other Options: http://techservinc.com/mailman/listinfo/peda_techservinc.com Browse or Search Old Archives (2001-2004): http://www.mail-archive.com/[EMAIL PROTECTED] Browse or Search Current Archives (2004-Current): http://www.mail-archive.com/[email protected]
