Embed with Forth
Authors: Frenger Paul 
Published: November 2005

WARNING: Any reader with a tendency to technoparanoia should stop here and go no further! Information of a potential anxiety-provoking nature follows. Those persons not afraid of hidden, invisible computer systems are free to continue reading.

In October, 1995 I attended the ACM OOPSLA conference in Austin, Texas. The OOPSLA organizers were kind enough to allow me to present a 45 minute robotics demonstration twice, on Wednesday the 18th and Thursday the 19th [1]. This presentation described techniques for object oriented design as well as object oriented programming, with Forth being the high level language used (with OOP extensions). I showed the attendees my (then new) artificial hand design which utilized a distributed multiprocessor network for control from a central artificial "brain". The demonstration was well-attended each day. I'm sure this presentation upheld the finest OOPSLA traditions for systems design and programming, since several people told me so afterwards.

Except one person. He took me aside after the second demo and loudly questioned why I was at the conference at all. His argument, literally and figuratively, was not only with the Forth language (I've heard that before) but with embedded systems programming in general. He was a desktop systems application programmer, and thought that only that kind of work was an acceptable exercise of intellectual talents. I was shocked by this attack, especially since there was no way he and I might ever be in competition for the same job or income source. We just did different things, under the general umbrella of computing applications.

My advice to him and all other persons who disapprove of embedded computer systems is: get used to it! In terms of instantiations of application designs, embedded/hidden systems outnumber desktop systems by a huge margin: around 100 to 1 [2]. They're everywhere, and you really don't want to be without them. Little computers are even hidden inside your desktop workstation (for example, in the keyboard, the motherboard, the plug-in accessory cards, the disk drives and the display unit). They make your video games work, and your Palm Pilot PDA, your CD player, your TV, your washer and dryer, your telephone, your car, your house, the traffic lights, your power company, pretty much everything. By clever design, you are made aware of almost none of this.

One of my favorite examples of this technology: the 1990's Mitsubishi Gallant. It had several computers, for the engine management system, shock absorber control, antilock braking and the automatic transmission. They all communicated with each other in real time. When the driver would go into a turn at a good rate of speed, the Gforce sensors would stiffen the shock absorber settings on the outside of the turn, the automatic transmission would hold the currently selected gear (inhibiting up or downshifting), the antilock wheel sensors would detect wheel slippage and the engine control system would modulate power to reduce the possibility of vehicle spinout. All the driver noticed was that at low speeds the Mitsu drove like a Cadillac, and when pushed harder it drove like a Corvette. No driver attention to these systems was required.

This trend has continued apace. In the 1990's a typical Porsche had more than 60 microcontrollers per car. A current Audi exceeds 80 microcontrollers per car. The Jaguar has become a rolling computer local area network (not including navigation systems, GPS, embedded cell-phones and DVD-CD entertainment). The weight of wiring in cars has decreased; the mass of silicon chips has increased. The appetite for embedded controllers in all products seems bottomless.