Embedded Systems Take Off

As Nobel-laureate Murray Gell-Mann described it at the 2002 Embedded Systems Conference in San Francisco, embedded systems is about putting a computer in a bed so the bed automatically moves to best enhance the activities that any couple on the bed may be engaging in (to put it tactfully). The concept extends to more than beds of course, but properly done, it’s clear why this technology will be a winner.

Judging from the products presented at the 2002 Embedded Systems Conference in San Francisco, embedded systems are ready for a number of advertising & marketing applications for the small to mid-sized business, ranging from desktop kiosks to Internet connected coffee makers.

The history of embedded systems goes back at least to the sixties, but the expense and limitations of the early systems limited their use. Embedded systems really took off in 1992, when the PC/104 Consortium was founded by Ampro, RTD, and other manufacturers. The group established a format for Intel microprocessors based on a motherboard approximately four inches square, and just under an inch high. The boards were stackable, allowing a very powerful computer to be assembled in a box approximately four inches square, or even less.

The PC/104 was initially targeted at military and medical markets, where it became widely used and respected. When the processor power increased enough to handle multimedia applications, PC/104-based kiosks became possible, and eventually common.

Today, there are estimated to be well over 100 different companies making PC/104 products. There are PC/104 cards to add ethernet, FireWire, hard drives, RAM drives, video cards, audio cards, general I/O, flash cards, modems, GPS, cellular telephone, wireless Internet, and more, to the PC/104 motherboard of your choice. Some off-the-shelf PC/104 cases can handle up to 13 or more cards, so your budget is your only constraint.

Links: http://www.ad-mkt-review.com/public_html/air/ai200205.html

History of C++

C++ was developed significantly after its first release.1 In particular, “ARM C++” added exceptions and templates, and ISO C++ added RTTI, namespaces, and a standard library.1

C++ was designed for the UNIX system environment. With C++ programmers could improve the quality of code they produced and reusable code was easier to write.

Bjarne Stroustrup had studied in the doctoral program at the Computing Laboratory at Cambridge University prior to joining Bell Labs. Now, Bell Labs no longer has that name since part of Bell Labs became AT&T Labs. The other half became Lucent Bell labs.

Prior to C++, C was a programming language developed at Bell Labs circa 1969-1973. The UNIX operating system was also being developed at Bell Labs at the same time. C was originally developed for and implemented on the UNIX operating system, on a PDP-11 computer by Dennis Ritchie. He extended the B language by adding types in 1971. He called this NB for New B. Ritchie credited some of his inspiration from theAlgol68 language. Ritchie restructured the language and rewrote the compiler and gave his new language the name “C” in 1972. 90% of UNIX was then written in C. The committee that wrote the 1989 ANSI Standard for C had started work on the C Standard project in 1983 after having been established by ANSI in that year. There were quite a number of versions of C at that time and a new Standard was necessary.

Links: http://www.hitmill.com/programming/cpp/cppHistory.html

Booting Linux from EPROM

This is a quick look at making Linux bootable from EPROM on a 486 single board computer.

This article describes one way to run Linux in an embedded system with no hard disk. The application described is an Operator Interface in a monitor and display system developed by Boeing Flight Test. The airborne environment requires something fairly rugged which can withstand common power interruptions. To meet these requirements we decided to build the operator interface without a hard disk.
Overview

The basic concept includes booting from a solid state disk (SSD) in Erasable Programmable Read-Only Memory (EPROM), copying a root file system from EPROM to a RAM disk, loading the operator interface software from a host and executing it. This article focuses on the details of how the system works, and on development techniques used.

The hardware selected is a VME-based Single Board Computer (SBC) 80486 with 16M of RAM, a PC104 SSD cable of holding a 4Meg EPROM, and some other PC104 boards. This SBC has built in BIOS support for using the SSD. The system uses a programmable keyboard and a standard VGA display.
System Operation

For booting, two options were considered:

• booting DOS, then running the loadlin program (to load Linux) from autoexec.bat
• installing LILO and booting Linux directly

The advantage of the second option would be a slightly shorter boot time. However, we implemented the first option, because we wanted to use a programmable keyboard—the software for programming the keyboard runs under DOS.

A bit of kernel-hacking was needed to make the system work. The ramdisk.c code was changed to load from any block device, not just a floppy (see Listing 1, ramdisk.c). Also, a new block driver was written to read from the EPROM device (see Listing 2, epromdsk.c).

When deciding how to implement the EPROM device driver, the first idea was to create an image of a disk in the EPROM. This would provide a RAM disk of the same size as the EPROM, 3.5MB in this case (the DOS portion of the SSD takes 1/2 MB). Instead, to allow a larger RAM disk, a compressed disk image is used. The compression used is simple—any sectors which are identical are only stored once. The primary advantage this gives is blank areas of the disk image don’t need to take up EPROM space. Listing 1 shows the SSD disk compression used.

Links:

http://www.linuxjournal.com/article/0243

http://www.linuxdevices.com/files/eprom/eprom.html

Why I Became an Engineer? Why did you become an engineer?

Some years ago my son was tasked with a high school assignment to build a circuit to re-encode a bank of switches. The teacher expected a simple diode-based design, but I suggested tossing an embedded computer in, so if the problem changed the solution would be trivial.

Also, of course, the thought of tweaking the instructor was appealing. When Graham got the thing working, the flash of excitement in his eye was a tremendous reward. He built the project, he wrote a little code. And it worked.

That’s exactly why I became an engineer.

Engineering is the art of solving problems. “In order to make a machine that does X, I have to figure out how to design some hardware and firmware that does Y.” Puzzling out these solutions is both an intellectual challenge and a game. Am I smart enough to do this? What will I have to invent?

Problem solving is its own reward. But it’s not enough, for me at least. I want to make something that works. Not push paper, not write proposals, not document someone else’s creation, though all of those tasks are an inescapable and wearisome part of this profession.

But I want the thrill of seeing the motor turn, the LEDs blink, or a message marqueeing across the display. No doubt that “I made that work” satisfaction is rooted somewhere in the same brain center that rewards gamblers and addicts.

A lot of developers work on large projects that take years of effort. More power to them, but I could never do that. I want to see something work, relatively soon. Invent solutions, see them implemented, and move on to the next project. You can have those big government projects that consume entire careers; the thought of being caught in that mill horrifies me. Thankfully others are more patient and will see these efforts through.

I sort of fell into the embedded space as it didn’t exist in the late 60s when I was in high school. An obsessive interest in electronics morphed into ham radio, but the important thing to me was always building something. First, learn the material, absolutely. But do start with just an infancy of knowledge and build a small project to get feedback, for fun, and to get a visceral learning that does not come from books.

Links: http://www.embedded.com/columns/embeddedpulse/200000283

Moore’s Law

According to Moore’s Law, the number of transistors on a chip roughly doubles every two years. As a result the scale gets smaller and smaller. For decades, Intel has met this formidable challenge through investments in technology and manufacturing resulting in the unparalleled silicon expertise that has made Moore’s Law a reality.
As transistor counts climb so does the ability to increase device complexity and integrate many capabilities onto a chip. The cumulative impact of these spiraling increases in capability power the economy and the Internet, running everything from digital phones and PCs to stock markets and spacecrafts, and enable today’s information-rich, converged digital world. Intel expects to continue driving the leading edge of Moore’s prediction well into the foreseeable future.

In April of 1965, Electronics magazine published an article by Intel co-founder Gordon Moore. The article and the predictions that it made have since become the stuff of legend, and like most legends it has gone through a number of changes in the telling and retelling. The press seized on the article’s argument that semiconductor technology would usher in a new era of electronic integration, and they distilled it into a maxim that has taken on multiple forms over the years. Regardless of the form that the maxim takes, though, it is always given the same name: Moore’s Law.

Moore’s Law is so perennially protean because its eponymous formulator never quite gave it a precise formulation. Rather, using prose, graphs, and a cartoon Moore wove together a collection of observations and insights in order to outline a cluster of trends that would change the way we live and work. In the main, Moore was right, and many of his specific predictions have come true over the years. The press, on the other hand, has met with mixed results in its attempts to sort out exactly what Moore said and, more importantly, what he meant. The present article represents my humble attempt to bring some order to the chaos of almost four decades of reporting and misreporting on an unbelievably complex industrial/social/psychological phenomenon.

Because this article is quite lengthy, I’ve divided it into three parts. I’ve also provided links and summaries for each part below so that you can skip to the part that interests you most:
Links:

http://download.intel.com/museum/Moores_Law/Printed_Materials/Moores_Law_Perspective.pdf 

http://www.firstmonday.org/issues/issue7_11/tuomi/

http://arstechnica.com/articles/paedia/cpu/moore.ars