emBuild.org -- Embedded Software Design Resources

(This site no longer maintained). Last Updated: October 23, 2011

This site is presented by Ted Merrill (emBuildSw.com) in the hope that it will be useful to someone.  You'll find a lot of opinions here, and i hope also you'll find some logic behind the opinions.

See emBuildSw.org for free software goodies from Ted Merrill including the embuild-atool software development suite.

Linux Home Office

I use Linux exclusively for software development... here are some tips.

Embedded Software Mid-Scale

There is i suppose quite a bit of on-going development for 4 bit and 8 bit processors with a few kbytes of memory, while on the other extreme are highly networked 64-bit processors running Linux and making extensive use of memory shared with other processors of various flavors.  My experience is with the mid-range of this spectrum instead of either of those extremes, so that's what i'll talk about.

Operating Systems


Every software project winds up developing their own operating system, even if it is only a modification and configuration of something from someone else. Here is my rant on the subject: Why you should design your own operating system .


The most developed small, free, realtime type operating system is the eCos Red Hat eCos icon operating system. It appears to be the most serious freely available operating system for systems smaller than Linux (but large enough to need an operating system).  A great deal of effort has been put into marking up the C source code for eCos with lots and lots of conditional compilation directives (#if's) so that you can compile in just the features that you need and get the smallest code possible with reasonable effort while retaining compatibility with future upgrades to eCos. They even have a GUI for navigating all these configuration choices, including all of the interdependencies, which works reasonably well.  Various applications such as Berkeley IP/TCP stack etc. have been ported to eCos; however, the range of available drivers is somewhat slim, which likely implies that eCos has not captured a large market share (or else everyone is hiding their drivers).  One omission that caught my eye is that their mutexes (mutual exclusion resource protection primitive operations), while supporting priority inversion safety, do not support recursive acquistion by the same thread... you had better know what your code is doing! They have a simulation environment where you compile your code to run natively on a linux PC but under ecos which runs in a semi-virtual machine implemented using e.g linux signals in place of interrupts (uses only a single linux thread to implement the multiple ecos threads).  The simulation environment includes support for a gui to simulate e.g. buttons and display screens, and connection with a real ethernet port (via linux raw sockets); all of which works pretty well and is quite useful for everything short of counting cpu cycles. My impression of ecos was soured however when sprintf took an exception... after stepping through the code i saw that sprintf was built on top of their file system code and it spent probably hundreds of instructions locking the "file" before even attempting to do any work! In general, their code (written mostly in C++) appears to suffer from some degree of over-generalization... very intelligently written code, but efficiency sometimes gets overlooked. I would question whether ecos is appropriate for a system that had a high rate of context switches.  Ecos has a paucity of embedded routines to e.g. print the state of the system; there is no debugging shell, although oddly their httpd package comes with some web pages of useful system status display.

eCos has, since 2002, been distributed under a modified form of the GPL that excludes the extension of the license to other code linked with eCos code.  eCos was actively developed by Cygnus and then Red Hat until recently when Red Hat pulled out of the embedded software market.  Red Hat has now announced that they are transferring ownership of the copyrights to the Free Software Foundation while the active development nucleus appears to have shifted to eCosCentric (www.ecoscentric.com), a private company that claims to employ many of the original developers.  eCosCentric makes money on support, of which the most profitable part is probably writing drivers for new hardware when someone pays them to.   The new drivers become publicly available to everyone else thereafter for free, which increases the general value of eCos and thus presumeably leads to new work as new hardware enters the market; this is of benefit to those who paid for parts of the development as well.  The Red Hat page for eCos (sources.redhat.com/ecos a.k.a. ecos.sourceware.org ) is still alive at this writing and is a place for downloading the software, although I would check ecoscentric first.  A useful reference and introduction is the book Embedded Software Development with eCos by Anthony J. Massa, ISBN 0-13-035473-2 published by Prentice Hall; it is a handy reference, but does not go beyond the obvious.


The Linux operating system has become quite popular for embedded system use due to it's excellent networking support and broad coverage of drivers, among other reasons.  Linux systems have been pared down and compressed enough to fit (with compression) onto a 2.88 MB floppy disk, although a more comfortable basic platform would be perhaps 4MB of flash and 16 MB of DRAM.  There has been for a few years a major fork of Linux, with non-MMU systems experiencing somewhat more limited support with a modified, trimmed down older version (see www.uclinux.org ) while systems with a memory management system can use the latest and greatest.  Linux 2.6 is said (see for example linuxdevices.com/articles/AT7751365763.html )  to bring these forks together, as well as add better real time performance. 

There have been some distinct problems with realtime performance on Linux that may take some years to be fully addressed.  As a personal example, in work I have recently done on the freely available source code of the Elphel networked camera (see www.elphel.com ) I found that it's low-powered processor was easily saturated when handling the Linux TCP stack with a 100 Mbit/sec ethernet connection.  This would not have been so bad, but the non-preemptible nature of Linux 2.4 resulted in, for example, a write of 4 MB to a TCP socket excluding all other user-level processes for the time it took to complete -- about one second.  The solution in this case was to break the write call up into a series of smaller ones, with some loss of performance.  This type of problem has been worked around by others by placing their realtime code in drivers, or more effectively and radically, by running Linux as a task under a realtime operating system (see for example www.fsmlabs.com), and by various modifications to portions of the Linux kernel and drivers (many of which are said to have made it into Linux 2.6).  Thus, while Linux has been successfully used on a wide variety of devices (linuxdevices.com is a good starting point) some care should be taken in ensuring that it will be compatible with the essential system requirements of your project.  Also, based upon my prior experience, I can say that it is not easy to port Linux to a new bus architecture.  The Linux code dealing with bus architectures tends to be highly oriented towards specific computer products, so even though some of these products may use the same bus interface chips as your device, the code will be of little help to you.  To a lesser extent, this problem applies to some drivers.  If you are designing a new product that you would like to run Linux, begin with an existing product (e.g. vendor evaluation or demonstration board) that already runs Linux, and work from there.  Be aware that there is no officially supported kernel level debugger for Linux, and that the kernel environment is fundamentally different than a normal tasking environment.  It is probably not a good idea to try to make a lot of code run as a kernel driver; instead, large amounts of code should either run at user level, or don't use Linux at all.  If you do want to write kernel drivers, I recommend the book Linux Device Drivers from my favorite book publisher, O'Reilly (www.oreilly.com).  Be aware that the Linux kernel is undergoing constant change, with fairly major changes sometimes made in allegedly maintainence releases of older kernel major versions.


GNU Compiler Collection (GCC) -- gcc.gnu.org  :
The GNU mascotSupports code generation for most 32-bit processors you are likely to run into and is entirely free.  Developed by a loosely knit team of volunteers (largely paid by various companies that benefit in one way or another from the association).  Some key points to be made about GCC (and the two other packages you will need: binutils (assembler, linker, librarian) and gdb (debugger)):
Commercial compilers often require licenses which are enforced through automatic mechanisms.  In a larger organization, it can be difficult to determine how many licenses to buy in order to avoid the occasional "out of licenses" error that can e.g. bring down an automated build.  On the other hand, each compiler has it's strengths.


The C library of choice for small but not tiny embedded systems is newlib (sources.redhat.com/newlib) which is distributed under a Berkeley-style license.  It was originally developed by various volunteers and the paid staff of the former Cygnus company, now absorbed into Red Hat; in spite of Red Hat's subsequent abandonment of much of it's embedded system emphasis, I note that recent updates to newlib have ocurred.  Fortunately, the C standard library is not much of a moving target.  Besides being a complete implementation, this C library is highly suited for embedded development because it's per-thread context is kept in a single data structure referenced via an anchor pointer;  you simply need to ensure that this pointer is updated whenever you switch context.  The library relies upon the presence of a handful of system call functions of the traditional Unix flavor (read, write, etc.) which are easily hacked for simple applications. There is a handy hook for locking during malloc calls (which are an exception to the per-thread context rule).  I have had problems in the past with software floating point support, but otherwise have been pleased.  Floating point is something best avoided as much as possible on lowly processors. Please note that even (s)printf formatting of decimal integers requires many cpu cycles on a lowly processor (e.g. ARM7TDMI) due to the lack of integer division support in the processor; if you do much of this, you wil need to rework the code to replace the standard C divide and modulo by 10 with special fixed point algorithms.
For Linux systems, glibc (www.gnu.org/software/libc/libc.html) is usually used.

The lwip networking library (http://savannah.nongnu.org/projects/lwip and http://www.sics.se/~adam/lwip) provides an IP protocol stack that works asyncronously (i.e. does not sleep, and uses callbacks for completion), which is ideal for some embedded system projects.  It also supports a syncronous interface.  Development seems to have slacked off and there are a lack of some of the peripheral components; for example, there is no integerated domain name resolver.

Merge and Difference DisplayTools

 I can be quite happy using a command line interface for most software development tasks, even sometimes for running a debugger such as gdb, and am happy with a curses-based text editor (vi), but i would be lost without GUI tools for comparing and merging source files. Unfortunately, there are not a lot of choices in the free software world.

I have used xxdiff a lot ( the web site http://xxdiff.sourceforge.net is quite helpful).  xxdiff takes some getting used to but generally does what i want, including 3 way merging of files, and options to ignore some types of differences such as line endings.  Unfortunately, it is pretty limited with respect to directories; it will only do a two way compare of directories, and doesn't provide any control over whether files are shown as equal or not. For directories, you double click on a filename to get a new, independent window for the file.

For a completely different user interface experience, try kompare (part of the KDE suite).  It excels at letting you quickly browse through all the differences of all the files beneath two matching directory hierarchies.  It is still pretty immature and there is apparently no documentation for it.

Reconfigurable Hardware

Software engineers can now write hardware, thanks to Field Programmable Gate Arrays (FPGAs).  This is an exciting new avenue for exploration.  There are a number of hobbiest boards available via the web; unfortunately I haven't tried any yet so I can't recommend them... anyone have any experiences to share?  Of course, FPGAs, being logic circuits doing many things in parallel, have some distinct challenges that rival the worst multi-threaded multi-processor software systems.

Elphel LogoI had the opportunity to make a contribution to the (freely available) software for the Elphel Camera (www.elphel.com), the company of Andrey Filippov.  While not the cheapest cameras, these cameras can be reprogrammed to do what you want to do.  Andrey makes the source code for both software and FPGAs as well as the board schematics available on his web site under the GPL license.  Here is a link to an article that explains what he did and what you can do (there are links to more articles on the Elphel web site).

Embedded software design magazines and websites

For keeping up with Linux (and free software) developments, there is no substitute for reading the Linux Weekly News -- lwn.net
And of course don't forget slashdot.org
The print magazines that i used to recommend have gone by the wayside, except for Dr. Dobb's Journal is i think still around.
Dr. Dobb's Journal -- www.ddj.com
Dr. Dobb's ("Software Tools for the Professional Programmer") has been around since the early days of microcomputers.  It covers a range of software areas, not just embedded software, but frequently has articles of interest to embedded software developers.


O'Reilly mascotO'Reilly and Associates -- www.oreilly.com
O'Reilly sells software-related books, easily identifiable by the cute animal pictures on the covers.  Their quality is usually so high that it is a shock when the produce a lesser quality book (hmmm... i've been disappointed by several of their books).  Look here first for authorative reference and tutorial works.

Software Development Methods

My friend Doug Dahlby contributed his review of current thinking regarding software development methods in an article he contributed: Applying Agile Methods to Embedded Systems Development (also in PDF and DOC).  Example quote:  In short, agile methods use continuous communication (customer/manager/developer, manager/developer, and developer/developer) to manage change, keep close traceability between customer requirements (“stories”) and the software, deliver functional incremental software releases with a rapid turnaround, (and) improve (“refactor”) old code selectively and continually.

Free Software Licenses

Instead of writing software (entirely) yourself, it is prudent to see if you can simply obtain if from someone or somewhere else.  This is is most easily done if the software is available in source code form and is freely available, which leads us to the subject of (free) software licenses.

Software licenses allow use of copyrighted software.  It is also possible to simply not copyright software (by not including any copyright notice) and place it in the public domain (in particular, if you have a notice stating that it is placed in the public domain).  A lawyer writing in the Linux Journal (http://www.linuxjournal.com/article.php?sid=6225 ) claims that placing software in the public domain protects neither the producer nor the user of the software from a variety of ills; however, I have never heard of anyone actually finding this to be a problem (but then again I'm not a lawyer).  There are a variety of free software licenses (see  http://www.opensource.org/licensesOpen Source Initiative logo) , but the most popular are Berkeley-style licenses, the GNU Public License (GPL) and the Lesser GNU Public License (LGPL).  All of these licenses protect the producer of the software from being sued for various imagined wrongs, and give rights to use the software to the public; and as a necessary but sometimes unfortunate adjunct, require that derivative works adhere to and reference the same license (thus copying a few lines of code without giving the appropriate reference puts one in technical violation).  Such licenses are definitely a must  for large software projects with many contributors.  Beyond the afore mentioned basics, Berkely licenses often require that credit be given to the author or author's institution in prominent places associated with a product; this requirement is rarely adhered to in practice.  The GPL goes further in requiring that source code for any derivative works be made available to anyone who buys software in binary form (recursively). The definition of derivative work can include anything linked (by a linker) and thus some people refer to GNU license code as contaminating other code (while other people use inter-process communication to another program to avoid being required to reveal source code).  The LPGL restricts the scope of contamination to the original source files (and is typically used to permit library code to be linked into closed source programs).

After reading the above, you may understand why the wheel is so often reinvented.  I you want to restrict others from seeing your source code, you must live in a parallel universe where much of what you do is has been reinvented by you.  If you are willing to share your source code, then you have many more options as to what software from others that you may use (and modify), although you will still be frustrated to some extent by the license terms (for copyrighted material) or possible lack of legal protection (for public domain software).  Most frequently you may have to live in several universes according to license type.

There are also software patents to (perhaps) worry about.  This is an unfortunate development in recent years.  Patents in general deny benefits to the inventor of an idea unless you happen to be the first to have provably invented the idea.  I have often been advised never to read a patent... because knowing violation of a patent (evidenced by having ever read the patent) carries a far stiffer penalty than unknowing violation.  You may thus find it amusing to learn that patents are justified on the grounds of the benefits of public dissemation of knowledge.  Patents are supposed to be issued for non-obvious inventions only.  Of course, everything is obvious given the background and motivation, so the term non-obvious has (pardon my saying) no obvious meaning.  The predictable result is that the patent office allows very absurd things to be patented, although of course this may not be revealed publicly  for years until a patent is actually issued.  A good protection against being sued for possible software patent infringement is to never reveal your source code.  So much for the benefits of public dissemation of knowledge.  Fortunately, software is easily changed, so a found patent violation may be remedied in many cases by simply using a different algorithm.


emBuild, emBuildSw and emBuild Software Design are trademarks of Ted Merrill (for software and software design). The material on this site is placed in the public domain (and not copyrighted).  Other trademarks and logos are the property of their owners with which they are associated on this page.  You are welcome to beg, steal or plagiarize the material from this site and from embuildsw.org to your heart's content except for these trademarks; you are requested to rename any derivative works to some name not containing embuild