This question arises in many places: circuit design, physical dimensions, and cost, to name a few. For my case (or rather, opinion), here are the important criteria to check for:

  • The volume of data going in and out
  • Size constraints
  • Environment of the embedded-system

A processor handling massive amounts of data per unit time requires more power both computationally and electrically, a faster clock (which also needs more electrical power), and, perhaps, ventilation for applications reaching very high clock rates. Size constraints will always depend where the embedded-system is meant to be placed. A system containing many components in a confined area requires more careful designing and construction. Environmental factors are among the most important: humidity, temperature, and electrical spikes, to name a few. Generally, processors packing more processing power are less forgiving in terms of environmental extremes.

Generally, those processors whose only task is to control equipment through commands issued by a more powerful processor are more rugged in build, since although they have to handle quite large volumes of command/response data, they are spared of the more complex computations such as PIDs that are common in industrial automation, since controlling equipment is their only task. A small program may be added to handle the case that the I/O controller be separated (i.e., the communications link severed) from its controlling station or computer; but that is little.

The well-known Linux operating system is used from desktop computers to high-grade corporate servers, mainly due to reliability, which in turn stems from the large community support base of Linux, since it’s open-source. Personally, I prefer Linux over Windows, although many of my software tools require Windows XP to run.

Linux has also been used in embedded-systems devices because of its stability. For me, I would think of having a normal desktop computer controlling the machinery, through a man-machine interface (MMI.) That is because remote control is always surpassed by local control of a human operator near the machinery – a basic automation rule. And desktops can pack more power and flexibility in terms of processing power than embedded-systems can.

It’s easy to make an interface circuit between the computer and the machinery controls using off-the-shelf components. You can program the microcontroller with just the necessary code for interfacing to the desktop, using the all-classical COM or LPT ports. I like the LPT port, since you can manipulate the 8 bits individually, and they all appear at the hardware port at the same time.

As for the desktop software part, technologies such as remote-procedure calls (RPC), streaming compression and encryption, and even Web servers can be used in tandem. Linux handles networking extremely well, and provides RPC for seamless calling of remote procedures and functions.

Local-operator controls can be designed with cross-platform kits like Qt, or with the native looks of Linux. The graphical UI is left at the discretion of the end-user.

Linux has a lot of uses, indeed. More may be waiting.