katalix.com

A whitepaper on "Best Practices in Embedded Linux" is available for download at

http://www.katalix.com/doc/embedded_linux_best_practices.pdf

The paper identifies development methods employed by successful companies using Embedded Linux and explores why some companies get into trouble when they make the switch from RTOS to Embedded Linux. Best practices in areas such as choosing the right hardware, choosing a commercial Embedded Linux distribution or rolling your own, system software design, debugging, testing and obtaining support are discussed. The paper makes some recommendations that would be useful to anyone about to start an Embedded Linux project.

People are invited to post comments in this forum.

I wish this paper had been available 6 months ago!

I used to work for a company that had switched from RTOS to Embedded Linux. We tried to use Linux just like an RTOS and ported the RTOS application to a single Linux process. The application had over 50 threads! Even the drivers were in the application. It was a mess. I tried many times to make my managers listen but they ignored me. Why should they take notice of a 27 year old programmer? So I left and found a Linux company that knew what it was doing. I wish I could go back now and wave your paper in their faces! But I hear they canned the project and have gone back to RTOS.

I think this is an excellent paper!!

I totally agree about redesigning rtos code if moving to linux. I have been thru this myself. We ported vxworks code that used semFlush() and taskDelete(). It took months to get it to work after porting it to linux pthreads. To make it work, we had to redesign to remove semFlush() and taskDelete() - we added new messages to implement task shutdown. This is how the design should have been done in the first place!

Frederik

Thanks!

You did the right thing. Asynchronous task deletion is simply best avoided.

James,

Excellent article! Interesting to read alot of the same lessons I've learned in the past 3 years with Embedded Linux. We started out with a commercial distribution that turned out to be a huge disappointment. On our next project we rolled our own which was a big learning curve but worked out better in the end.

We're about to start another Embedded Linux project. Based on my experience, the things I'm hoping to improve on are:

- How to better manage an embedded linux build environment. We rolled our own build including the kernel, busybox, and other applications. We had some cumbersome low-tech scripts that would partition a compactflash card, install the bootloader (grub), create a file system and copy over the directory structure from the host machine. I'd really like to come up with a nice way to manage this better in the future.

- Come up with a better "Unix-way" of implementing the application programs, instead of the one-big-blob method. Our system monitors and controls several different devices and peripherals. Many of the control functions are independent, but they need a way to send messages to each other to coordinate their behaviour. I really like the idea of having multiple daemon processes to implement the control of each device, but am not sure of the best/simplest way to do the interprocess communication required.

I'd be interested to hear your thoughts on this. Thanks again for the insightful paper.

Mark

Thanks!

Sounds like you're well on the way to making successful use of Embedded Linux. Were you using an RTOS before Linux? One observation I've made is that ex-RTOS users expect Embedded Linux distros to provide the tools and environment with which you can continue to develop embedded products the same RTOS way. It doesn't work. It's best to understand where Embedded Linux is different and design for it. The distros won't say this because they fear they might lose potential customers.

Buildroot http://www.buildroot.org is ideal for this. It can build all the components, create a rootfs (initrd, squashfs, jffs2, tarball etc) which is trivial to install on the target.

Avoid the one-big-blob. I assume you don't have user-mode drivers because they tend to enforce the big-blob model. Find a book about Unix IPC. Simple Unix-domain sockets are a simple way to exchange messages between processes. Also consider shared memory. For more complex IPC, tools such as RPC may be suitable. The following links might also be useful:-
http://www.cs.cf.ac.uk/Dave/C/node27.html
http://www.cs.cf.ac.uk/Dave/C/node25.html#SECTION002500000000000000000
Making use of the process model turns Linux to your advantage. But I guess I'm only repeating stuff I wrote in the paper.