Rostad takes us through his experience replacing an instrument controller with a Linux-based update. A harsh 24/7 environment makes it more interesting.

Our project was to develop an instrument for measuring viscosity in anode paste for the aluminum industry. The mechanical and electrical hardware requirements were carved in stone, as the instrument was to be built on an existing design. Our job was to design a new version of its computing part to replace the earlier incarnation built on a 15-year-old Siemens microcontroller. The complete theory behind the instrument is given in Knut Torklep's “Viscometry in Paste Production” (Light Metals 1988), but in short it works as follows.

A sample is placed between two plates, and the upper plate is then lowered by hydraulic pressure. The speed of the upper plate, the force on the lower plate and the temperature are all determined during the measurement. Every ten seconds the immediate viscosity is calculated and shown on an LCD screen. Finally, the calculations are run again with the average of the measurements as in-parameters, and the final results are displayed on screen and optionally as a printout.

Requirements

The specifications for the system were fairly simple: control relay switches, read voltages, perform calculations and present the result to the user with as little user interaction as possible. For normal operation, the user should only have to use two push buttons on the front panel of the instrument, one for resetting the weight and another for starting the measurement.

Some settings are rarely changed in the instrument, which has a calibration routine for the position sensor. The operating environment is more challenging, however. The instrument must be dust-proof, as there are large amounts of conductive carbon dust in the air around it. It also must be reliable in ambient temperatures from -20 to +70 degrees Centigrade and may be required to operate in magnetic fields of 150-300 Gauss or up to 0.03 Tesla.

The weight sensors are critical in two respects: they are extremely sensitive (an accuracy of 1 gram with a span of 750kg) and may be subject to vibrations. The only way to compensate for this is to measure the weight over an averaging period longer than that of the vibrations. Other requirements must be taken care of by the hardware implementation. Vibrations exclude using any moving parts, particularly hard disks, which are unreliable over time in such magnetic fields, even with heavy shielding. High-speed processors also do not work in such environments. The reason for this is unknown, but we have established that Pentium-II class and newer CPUs do not work reliably in such magnetic fields without heavy shielding. Even with such shielding, they prove unreliable over time.

Why Linux?

We have some experience with roll-your-own OSes written in assembly, as well as with GUIs and data acquisition systems (DAQs) under Windows NT. Neither was particularly suited for this project, however. The roll-your-own approach would have entailed too much work; copyright law prevented us from using customer-owned systems we'd previously developed, thereby requiring us to start from scratch. The time hardly seems ripe for writing a new embedded OS today.

The GUI approach simply did not fit the bill when we considered reliability and simplicity. The viscosity measuring instrument is built for heavy use by people who have other things to worry about than navigating window-based user interfaces.

So we decided to use an embedded distribution of Linux and write the application in C. In most embedded applications there is little benefit in using C++ or other OO techniques because the application normally is small and simple, and one has more or less complete control over the hardware.

We were essentially new to Linux. We do have a web server running Apache under Red Hat 6.2 and have used various flavors of UNIX over the years. However, we fell into the trap of abandoning UNIX in the early 1990s when it seemed these workstations were losing the battle. Thus, we started from scratch on the OS (not to mention embedding the thing).

The Hardware

We decided to use NuDAM modules from Adlink Technology for the I/O. These modules are fairly robust, support any conceivable configuration of analog and digital I/O and can be daisy-chained on an RS485 network. Since space was not a primary concern, we decided on a single-board computer from ICP Electronics rather than one of the smaller solutions. The board was equipped with a Cyrix 486-class CPU, sufficient processing power for our purposes. For storage, we decided on an IDE-compatible 2.5″ Flash disk rather than the disk-on-chip solution. The application was not to be networked, but we did put in a floppy drive for upgrades. This hardware solution corresponded closely to a normal standalone PC while still fulfilling our requirements. We felt this solution would minimize embedded-specific problems, allowing us to focus on the problems we knew would arise from using a largely unknown platform.

We decided to purchase all the equipment from one supplier because we thought this would provide some degree of interoperability. Unfortunately, when we needed some support later on, this perceived benefit was outweighed by the fact that our supplier turned out to have even less experience with Linux than we did. This left us with the unenviable task of figuring a lot out on our own. I strongly suggest you verify that your supplier has some real experience with using Linux before purchasing.

The Tools

We started out by getting a few PCs up and running with Linux. The distribution we selected was Red Hat, simply because it is the most widespread and has an abundance of documentation available on the Net. In addition, Red Hat has a product specifically for embedded development, the Red Hat Embedded DevKit (EDK). We also tried SNiFF+ Penguin IDE but returned to the EDK because it is more intuitive and has more familiar keyboard shortcuts. SNiFF is probably better suited to larger projects than the EDK.

The EDK has a few peculiarities when compiling and working on the target and requires a working network connection. Because our system resembled a PC, we were able to develop, compile and debug on a standard PC and then transfer the finished product afterward. Thus, we did not need remote-debugging facilities, though not having our device network-enabled eliminated this need anyway. The EDK also has built-in support for version control, so we did not need to use CVS separately. The EDK's built-in debugger tended to crash on us, so we decided to go with DDD, a great debugger that gives you excellent insight into what happens inside your program.

Problems

When developing embedded systems using Linux, problems start and end with documentation. While Linux has been criticized for not providing enough documentation, we found our problem to be an overabundance of it. The main part of our communication was based on serial I/O. The Linux community provides several documents on this subject, as well as large amounts of mailing-list archives. Sifting through this information until you find what you need is a formidable task, not to mention the documentation is often provided by people who have written it for one specific purpose. In addition, since embedding Linux is a relatively new phenomenon, very little of the available documentation is relevant.

Most serial communication problems involve either cabling or port initialization. Our main problem occurred with port initialization, but we found information on the Net to be focused on modem communication. Again we were forced to turn to header files, which had saved us several times during projects but are hardly an easily accessible form of documentation. In addition, the hardware documentation from Adlink contained a form of English that was significantly worse than mine, actually bordering on the incomprehensible. When the documentation specifies an “Internal Current Load Resistor”, you hardly expect that you are expected to provide this item, so it took us a while to get the hang of it.

The Result

Today our application runs smoothly. It will never be taken down gently because the system is expected to run 24/7 and will only go down during power failures. This possibility made us a bit worried about disk handling, so we contemplated running it all from RAM disk. This was not our first choice, however, since we needed to store some settings and calibration data in case of system stop. We stress-tested the system a bit by pulling the plug at odd times, and it actually performed as good as, or perhaps even better than, the proprietary OSes we have used before. Debugging on a standard PC was not only a great time-saver, it made the application more stable than what we would have made using another approach.

Conclusion

Embedding Linux for instrumentation control is feasible today. If you have access to the source of a proprietary OS with which you have experience, it may be smart to wait until the Linux solution is more established. Linux is technically superior to most other solutions, but its superiority is diminished by the fact that very little is available when it comes to accurate, reliable information for this specific purpose. If you have the resources to sort the wheat from the chaff, it may pay off to start with Linux today, but this is a cost that has to be calculated in when the budget is made.

In our case, with the experience we have with roll-your-own OSes, we probably would have been able to produce the same application in approximately the same time with such a solution. But, then again, we are now positioned to do other projects on Linux, and this is certainly beneficial in today's market. Our next project on embedded Linux will be finished on a relatively smaller budget.

Thus, if you have an existing proprietary OS and do not expect to develop enough projects to make it worth the switch, stay with what you have. But if you are planning on doing several projects on an embedded OS for instrumentation control, or if you are unable to use an existing OS with which you have experience, go for Linux.

---

About the author: Richard Rostad ([email protected]) got his appetite for programming on the CBM-64 demo arena in the early 1980s. He has seven years of experience in GIS and environmental monitoring. Since 1999 he has been running a small company, DigiDev AS, which specializes in consulting and developing measurement and monitoring systems. When not working, he is somewhere in the world riding a Cannondale bicycle.

---

Copyright © 2001 Specialized Systems Consultants, Inc. All rights reserved. Embedded Linux Journal Online is a cooperative project of Embedded Linux Journal and LinuxDevices.com.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.