Michael Eager is principal consultant at Eager Consulting in Palo Alto, Calif. He has over four decades experience developing compilers, debuggers, and simulators for a wide range of processor architectures used in embedded systems. His current and former clients include major semiconductor companies and systems developers. Michael has been a member of the ISO C++ Standard Committee and ABI Committees for several processor architectures. He is chair of the Debugging Standards Committee for DWARF, a widely used debug data format. He is active in the open-source and Linux communities.


's contributions
    • Discussions about the quality of programs get polarized between proprietary software vs open source proponents with more anecdotes than facts in play.

    • I'm a sucker for "buy one, get one free" offers, and there's always a line outside of Ben and Jerry's on Free Cone Day, but there are a variety of costs, sometimes hidden, in free (as in beer) software.

    • While there is a small, impassioned, and very vocal community which is concerned about Free Software, the great majority are mostly interested in Free.

    • myrandom.c is a Linux driver that creates a virtual device that will return a pseudo-random number when read. This is a similar to the /dev/random virtual device, but simpler, and not to be used in real programs.

    • Michael Eager discusses open source in embedded systems.

    • I think that the number of developers is more relevant than the number of users. Some projects (e.g. bash or ntp) have many users but very few developers. I don't know anything about the Aurdino IDE and the Microchip driver you mention, but I expect that there is little relationship between the many IDE users and the number of driver developers. Microchip may open source its driver code (for which it is to be commended) but that doesn't change how the code was developed. Both Open Source and proprietary code can be high quality or low quality. The singular advantage of Open Source over proprietary is that you can look at the code, evaluate its quality, and decide whether you want to improve it.

    • Hi Trantuandung -- I think that your list of topics is interesting, but each is much larger than can be covered in this series. Later installments of this series discuss embedded application development and a future installment will cover building a root file system.

    • You're correct, I did not mention TCO. On the other hand, I can't recall a discussion of TCO which included any amount for support of system components like the Linux kernel, NTP or OpenSSL which are available for free. TCO computations include license, hardware, training, perhaps software porting, etc. But never the cost of a security flaw in one of the "free" components.

    • This is a first example of how to write an LKM driver. As mentioned, this only touches on the basics, and I recommend reading Linux Device Drivers for a more extensive discussion.

    • You don't need to be running Linux on your desktop. You can run Linux in a virtual machine (VMware, VirtualBox, etc.) and use if for development. It's possible to develop for Embedded Linux on a Windows or Mac desktop, but it's more complicated than using a VM running Linux.

    • There are many boards which can run Linux. Raspberry Pi and the BeagleBoard series are popular with hobbyists. For commercial applications, there are dozens or perhaps hundreds of boards. I run Fedora on my desktop and CentOS on servers, where I value its stability. Many people like Ubuntu, which I have sometimes run on my laptop.

    • You need to configure networking on your target. I'm assuming that you can log into the target using telnet, SSH, or a serial console. Run "ifconfig -a" to see the network interfaces which are configured. You can use the "ifconfig" command to manually configure the interface.

    • There are a number of options depending on how your target is set up, too many to explore here. One common way is for your target to mount the root file system from the target using nfs. You can copy your program to the /tmp directory on the root fs, log into the target, then run the program. Another approach is to burn the root file system to flash on the target, log into the target, then copy your program to the target using rcp or scp, then run the program.

    • There are a couple typos in the article: In the paragraph following the figure, the last sentence should read "Add your name or a number to the EXTRAVERSION value, preceded by a hyphen." The command to show the kernel version is "uname -r", not "uname -1".

    • Everyone needs to start from where they are. Linux has a significant learning curve. If the objective is to learn Embedded Linux and be able to apply it in the shortest amount of time, being able to leverage what you know now is an advantage. The operative word in your comment is "ultimately". This series of articles is an introduction; it isn't the end point. I might well agree that "ultimately" using Linux for development is better, but until that time, use what you know and learn the rest.

    • Since Linux is similar in all environments (unlike most other embedded operating systems), we are really covering an introduction Embedded Linux, even if we are talking about a desktop environment. The next installments of this series will discuss applications and libraries, configuring the kernel, and building loadable modules, all on a desktop Linux system. All of these are techniques that you will likely need while developing on Embedded Linux. Then we will start transferring this knowledge to the embedded world, discussing target platforms (boards or emulation), cross-compilation, building a target file system, and more.

    • Part two can be found here: http://www.embedded.com/electronics-blogs/open-mike/4421938/Getting-started-with-Embedded-Linux---Part-Two

    • This is an interesting idea. This series will present a roadmap for learning about embedded Linux. Whether this might evolve into the multi-volume work you describe remains to be seen.

    • Indeed, corporate IT folks do have experience with Linux and likely have a distribution which they prefer. But they don't generally like users reconfiguring the kernel or modifying the software, which is exactly what developing an embedded Linux system will involve.