Using Linux to Control the Outside World
Developing real-time control applications using Linux.
David Wagg and Eduardo Gómez
One of the key problems faced by control engineers is how to make a computer interact with the system they are trying to control. If, for example, we are trying to spin a motor at a constant speed, we need to retrieve the data from the tachometer (usually a voltage signal), calculate a driving signal in the computer and then send this signal back to the motor (i.e., convert the numbers back into voltage levels). One of the simplest and most cost-effective ways of achieving this is to use a data acquisition card. The card forms a link between the computer hardware and the analogue input/output signals required to control the external system. This system could be anything driven by an electrical motor--your garage door for example.
In DOS times, average programmers could buy any card they wished, develop the code to drive it in the way they wanted, and use this code on the computer. However, the arrival of more sophisticated hardware introduced the concept of device drivers (which had been used previously in UNIX and other large operating systems) to the world of personal computing. The device driver is the piece of code that controls the hardware and contains the instructions specific to the card. When installed on the PC, they become part of the operating system and, as such, can rarely be manipulated or developed by the end user. After finding a suitable card and installing the accompanying software (including the device drivers supplied by the manufacturer), it's not unusual to find that it does not do what you want. Unless you've made a bad choice of board, the apparent limitations of the system are nearly always software-related. Particularly limiting are the device drivers, as the user has no opportunity to alter their behavior.
Some commercial operating systems make it difficult for an experienced programmer to develop a device driver themselves. The development kit for creating device drivers is usually not shipped with the compiler, and the documentation can be obscure. Some card manufacturers add to the difficulty by removing vital register-level information from their user manuals. When questioned about this, they will refer you to their ``already optimized'' device driver, which will normally reduce the performance of your system.
Luckily, Linux has many contributors around the world who have provided very good documentation for device driver development. Linux compilers, of course, let you create anything you want without having to buy a special license. Card manufacturers can (usually) be won over, once you tell them plainly that you will not buy their card unless register information is supplied.
In this article we describe some of our experiences in overcoming these limitations while developing a real-time control application. In this case we were limited by financial constraints and had only a relatively old ISA card and a 486 PC. So, in order to obtain the required performance (sampling rate), we needed to write efficient code, including the device drivers. We had no need for a GUI and used only command line-driven programs.
The drivers for the data acquisition card were combined with the Linux real-time clock, so that user controller programs could be written to achieve a crude form of real-time control. Despite the basic nature of both the hardware and the software, the subsequent experimental results were good. In fact, they were equal to other results taken using commercial card/software packages but had obvious cost savings combined with the convenience and flexibility of source code accessibility.
For control engineering applications, a Data Acquisition (DAQ) card (or board) forms the link between computer software and a physical system. The term DAQ usually includes Digital-to-Analogue Conversion (DAC), which occurs when the control signal is sent, from OS to hardware.
In the Linux OS a device driver appears as a file in the /dev/ directory. We are only concerned with character device drivers, which read a stream of bytes, and are appropriate for devices such as data acquisition cards.
A device driver file can be created with the mknod command, which requires specification of the type, and the MAJOR and MINOR numbers for the device. The MAJOR number enables the kernel to identify the hardware device from all the registered hardware devices, so it's important that there's no conflict with the pre-existing MAJOR allocation (see Linux Allocated Devices, by H. Peter Anvin, http://www.linux.locus.halcyon.com/pub/linux/docs/device-list/devices.txt, last version 3/23/00). For a single-character device we can set the MINOR to 0.
For example, we wanted to create a driver for the Amplicon PC30AT data acquisition card. To create a character device driver called pc30at with MAJOR 125 (unallocated as yet) and MINOR 0 we give the command:
mknod /dev/pc30at c 125 0
The appropriate file permissions, depending on which users should have access to the driver, can be set using the chmod command. This file can now be linked with the driver code via a loadable kernel module.
Trending Topics
| You Need A Budget | Feb 10, 2012 |
| The Linux powered LAN Gaming House | Feb 08, 2012 |
| Creating a vDSO: the Colonel's Other Chicken | Feb 06, 2012 |
| Your CMS Is Not Your Web Site | Feb 01, 2012 |
| Casper, the Friendly (and Persistent) Ghost | Jan 31, 2012 |
| Razor-qt 0.4 - Qt based Desktop Environment | Jan 30, 2012 |
- Fun with ethtool
- Parallel Programming with NVIDIA CUDA
- 100% disappointed with the decision to go all digital.
- Readers' Choice Awards 2011
- Linux-Based X Terminals with XDMCP
- Validate an E-Mail Address with PHP, the Right Way
- You Need A Budget
- The Linux powered LAN Gaming House
- Why Python?
- Python for Android





2 hours 35 min ago
7 hours 5 min ago
12 hours 12 min ago
13 hours 13 min ago
22 hours 40 min ago
22 hours 51 min ago
1 day 4 hours ago
1 day 8 hours ago
1 day 9 hours ago
1 day 9 hours ago