Recently in Computer Stuff Category

Adam Gonnerman wrote an insightful post about how showing the average user the Linux command line (or the DOS command shell on a Windows box, for that matter) can create a sense of fear and intimidation.  It's an interesting piece and I highly recommend reading it as well as the conversation in comments.

As I look at my own comments in that discussion, I'm reminded of how much my thinking about computers has changed over the years.  When I was in college, I was a total command line snob.  I looked down at GUI's in general and thought they were the road to making every computer user stupid.

I think this was a common mentality for a lot of us who were into computers back when I was in college and before.  After all, when I first started college in the Fall of 1992, Windows was still something you started from the DOS command line after you booted the machine.  And the computers in the college's computer labs were set up under Novell.  You'd enter your login credentials, get dumped to the DOS prompt, and type "win" if you wanted to start that stupid GUI.

Even Linux distributions tended to treat XWindows as an afterthought at the time.  That same freshman year, I loaded Slackware Linux onto my IBM XT clone (I will admit that I was nowhere near the cutting edge in terms of the computer I personally owned).  It involved downloading a couple dozen images and burning them onto 3.5" floppies and then using a special boot disk to install the system on the computer.  XFree86 was an optional install and the distribution was -- again -- set up to have you log into a command prompt and then start XWindows from there.  And since trying to get XWindows to work on your particular configuration was no easy task back then, it struck me as mostly a waste of time.

So I came through a time when using a computer meant you had to be a wizard with a command prompt.  It wasn't optional.  You learned all the magic commands and you lerned how to use them extremely well or you were hopelessly lost.  It was a glorious time, especially for those of us who loved the challenge.  So to me at the time, the growing popularity of GUI's (by my senior year, all the computers in the lab were running NT 3.5) and the ease of access they offered was destroying the challenge.  It was making computers something useful for anyone rather than the playground of the geeky elite.  And I was just enough of a snob (and had just enough of my self-worth invested in my geekiness) that this upset me.

So what changed?  To be honest, I changed.  I quit keeping up to date on computers.  I became the average computer user myself, and I found that I liked being an average computer user.  So I let go of my elitism.

I suppose a few readers may be surprised to hear me refer to myself as an average computer user.  After all, how can a software engineer -- someone who is well versed in programming computers -- be merely an average computer user?  Well, the answer to that is that I'm an embedded software engineer.  And that's a rather different kind of computer programming.

I'm currently developing the software for a very unusual device.  It's a computer, but you won't see it sitting on anyone's desk.  It has no keyboard, mouse or monitor.  In fact, if you look at it, all you see is a big metal box with a bunch of cables coming out of it.

Inside, there is a bunch of analog-to-digital converters and I/O expanders that allow the processor to read or assert logic levels on various signals on the circuit boards inside that box.  My job is to develop the software that accesses those ADC's and those I/O expanders with all the signals, do stuff with the data read, and assert certain signals based on that data.  I spent most of this afternoon making sure I could communicate with the ADC's and I/O expanders.  Tomorrow, I'll spend a significant amount of my time making sure that the readings I'm getting from the ADC's are valid and mean what I think they mean.  I'll also spend time making sure that I can read and control the logic signals from the I/O expanders as I expected.

This is a typical programming project for me.  I spend most of my time looking over data sheets for devices like ADC's, I/O expanders, microprocessors/microcontrollers, EEPROM's, and power management chips.  I also read schematics and hardware design specifications that explain how these devices are configured and are supposed to work on the system I'm currently working with.  I've learned to write assembly code for PowerPC's, ARM processors, Blackfin processors, and a few others I've probably forgotten about.

Quite frankly, after I've spent all that time learning about the stuff I need to know to work with the devices I program, I don't want to learn about the computer sitting on my desk anymore.  I just want it to work and work relatively well.  I'll let someone else worry about making sure all my programs work correctly and that my computer is secure and safe from viruses.  After all, the computer on my desktop is just a tool to me now, and tools are good if they're easy to use.  It gives me more time to focus on all that embedded stuff that's part of my job.

So I quit being a command line snob.

One of the annoyances that I run into due to my job as a software engineer is that when I tell most people that I'm a software engineer is that most people get that I work with computers. Unfortunately, they assume that this means I work with personal computers, which usually leads to them uttering the phrase, "You know, I'm having problem with Windows, and..." That's usually when I have to stop to them and explain to them that when it comes to the PC world, I'm only slightly more knowledgeable than the average user. Most of my professional expertise is in the world of embedded systems.

Of course, part of the problem is that the average person doesn't really understand what an embedded system is. They're naturally inclined to think "computer" and picture that machine with a monitor, keyboard, and mouse they have sitting on their desk. So that usually leaves me racking my brain figuring out the best way to explain what an embedded system is.

Today, while talking to Tracie, I realized that I've been overlooking a perfect example of an embedded system (though the more geekish might argue how accurately said example can really be called an embedded system) that everyone is familiar with. In fact, three different flavors of this example are quite popular now, the Xbox360, the Nintendo Wii, and the Playstation 3. In the loosest sense, gaming consoles are embedded computer systems.

For those who may not know what an embedded system is, it is a "computer" system that is designed and programmed to perform a dedicated task, as opposed to a general purpose computer -- most notably a PC -- which is designed to be highly configurable and usable for just about any task. A game console fits this definition quite well in that it is a computer system designed to do exactly one thing: Allow a user to play games.

Most importantly, as an example of an embedded system, the gaming console excels in that it shows the advantage of embedded systems over general purpose computers. After all, a user can play games on his PC as well. However, because the PC is designed for multiple purposes, playing a game on a PC incurs a great deal of overhead. The game software has to interface with a rather complex operating system that has been highly abstracted and work with (or bypass, which is just as problematic) the operating system's device drivers in order to access resources like the keyboard, mouse, game controller, and graphics controller. If there are other applications running in the background, the game has to be able to play nice with them as well. The net result is that games can run slow on a PC. Anyone who has played many graphics intensive games on a PC will notice that there are just times when the image or sound lags while the computer tries to catch up. This is usually because the operating system or some other application has been doing things to steal resources from the game.

Like any embedded system, a gaming console doesn't have this problem. The core operating system on the console is bare bones, and designed to support the current game being played. Because of this, the game has access to all of the system's resources and doesn't have to worry about another application jumping in and slowing it down. More importantly, the interface to devices like the graphics controller, game controller, and audio controller are much simpler and less abstracted. In fact, while I cannot say so for certain, it would not surprise me if most console games access these devices at the hardware level directly rather than going through any device driver at all. Again, with an embedded system serving a single dedicated purpose, this is not only possible, but perfectly acceptable.

Of course, as I said, a game console is not a perfect example. After all, they are still far more configurable and less dedicated than more traditional embedded systems, such as the electronic computer module that controls the fuel injection process in your car. The game console can accept different games, which will provide different software and a different gaming experience for the user, which makes it slightly more "general purpose" than some purists might consider worthy of being declared an embedded system. However, as a coworker pointed out a few months ago, this is a problem in the world of embedded systems in general. With the increasing features being added to cell phones and PDA's (two other devices that have tradtionally been considered embedded systems), the line between general purpose computers and embedded computers is becoming increasingly blurred every day.