THIS ARTICLE is basically the first step (actually there are only two steps) to embedded computing using single-board computers (SBCs).
SBCs are generally just 5-8cm square and cram a complete PC onto a single circuit board. They are extensively used in applications requiring small size and/or resistance to vibration, such as automated teller machines, motor vehicles and portable machinery etc. These days, many run a version of Linux as the operating system due to its low cost, flexibility and range of development tools (some instead use one of the BSD-based Unix clones or Microsoft Windows).
They do tend to be rather basic, so it’s much easier to do all development work in the luxury of your desktop PC, then stuff the finished software into the SBC when it’s all debugged and running.
In the last year or two, SILICON CHIP has presented several spectacular examples of just what can be done with the newest generation of powerful microcontrollers. There has been the Web Server In A Box (WIB), the Data Logger and just recently, the Maximite computer. It gives an indication of the direction that technology has taken and it’s amazing to think that a tiny piece of plastic and metal with a silicon “brain” can present you with seemingly endless pages of full-colour web content.
Penguini with Mint: the Linux Mint desktop, from a distribution supplied by P. J. Radcliffe of RMIT. The root versions of the file browser and terminal provide you with unlimited power but no handrails or safety net. The tool bar pops up when the cursor hits the bottom of the screen.
PCs have mirrored this upward trend but in so doing, have made themselves more and more inaccessible to the casual experimenter. It’s harder to interface with USB than the older serial and parallel ports; even if you still have one of the latter, the latest Microsoft operating systems make writing software to access it a difficult task.
But then there’s Linux. Linux is most certainly not such a black box. In fact, everything is out in the open and it’s really quite easy to access the various PC communication ports. By using Linux as the operating system (OS), you once again have a PC that you can experiment with. Want to log data, surf the web, flash LEDs or switch relays in response to varying light levels? No problem at all.
You may never have found much need to use to Linux and I certainly hadn’t. But during the course of this work, I found that Linux is the number one choice for an embedded operating system, with “Android” (now commonly used in mobile phones) being perhaps the most famous derivative. This and many other embedded operating systems are based on the Linux kernel, which is the core component that provides all the basic functions.
The kernel is now up to version 2.6, and has a well-deserved reputation for functionality, stability and security.
Linux control paths
There are three clear paths to Linux control and it’s worth spending some time to explore them.
The first is the simple, old-fashioned use of the serial and parallel ports. Yes, I know that they have been largely phased out but rumours of their deaths have been greatly exaggerated. Suitable interface cards are readily and cheaply available (including USB-to-serial or USB-to-parallel adaptors) and the average desktop PC has lots of space to fit them. Likewise, many embedded applications still use them and a glance through the Ocean Controls catalog will quickly illustrate the point.
Fig.1: a simple supervisory control scenario. Smart modules run a process while a central supervisory computer provides broad operating parameters and responds to any alarms.
The second path involves the use of USB I/O (input/output) devices. They come in every imaginable configuration, from simple USB converter cables to boxes full of relays, ADCs and digital outputs – all driven from the USB port. For a (very) good example, take a look at the Arduino-compatible I/O controller featured in the April 2010 issue of SILICON CHIP.
However, while the above approach is very useful, it has two failings: (1) the devices are generally “brainless”; and (2) it is difficult to use a PC in real time for such tasks. Your controlled system can be going haywire and over-running its limit switches while the computer is blithely servicing some trivial interrupt.
A better approach is “supervisory control” (see Fig 1). It can be used with a bewildering variety of busses and protocols but let’s assume for the moment that it’s all USB. In that case, the PC and one or more USB I/O devices are linked together in a network, except now the USB I/Os are intelligent.
An an analogy, imagine a ship’s captain and engine room crew. The captain (supervisory computer) drives the boat according to a plan involving high order functions such as navigation, sea state, schedule etc. The captain issues orders to the engine room for a certain speed and the engine room crew (USB I/O modules) takes care of monitoring and adjusting for steam pressure, engine operating parameters, lubrication and all the myriad functions that the captain does not want (or need) to worry about.
The point is that each control module can monitor and adjust for its own feedbacks in real-time so the PC can then interact with them on its own schedule.