Signals & Noise: February 1, 1996

More praise for Forth

I agree with the points made by Albert Mitchell suggesting that Forth might be a more appropriate language for users of "small" microcontrollers ("Signals and Noise," EDN, Oct 12, 1995, pg 39). I am the hardware project engineer for instrument development at my company and I have successfully used Forth for many years. Our hardware-development team consists of two technicians, a manager, and me. (The company’s software-development-and-maintenance team, in contrast, has nearly a dozen people.)

Our project, which is still in the paperwork-overload stage, functionally comprises a 486-based custom board that performs heavy number crunching and acts as a user interface. This device communicates to a machine-level controller, based on the 68HC11.

During development, we needed a way to test the machine control and analog processing that the low-level processor controls. The software team estimated that it would take two months to develop a device that could twiddle the bits and read the channels. This proposal took too much time and gave us too few functions. Further, the software team did not have the necessary equipment, potentially leading to more delays. I told my boss that I could create a device in less time, without an impact on my other responsibilities.

Having used Forth on the HC11 about five years earlier, I had some resources available. I pulled some old public-domain Forth kernels and checked them for compatibility. With nothing more than my Mac, a good assembler, and a ROM programmer, I had a working and communicating kernel in less than a week. In another week, I had implemented the previously defined pseudo-code routines. This process let us continue developing and testing in one-quarter the time our bloated software department required.

As we tested and verified the components, I wrote more sophisticated test routines. We were also improving our testing methods as we tested the boards. The interactive nature of Forth allowed me to modify the program as we found better ways of testing the system’s performance. When our testing was done, we had developed more complex routines than we would have achieved using the software department’s proposal. And, we had a better understanding of the relationships and interactions of the subsystems than we may have had by letting someone else sweat the details. In fact, the details were no sweat at all. Even the routines that were necessary to write in assembler were easier to implement with a Forth kernel.

For the "real" software, the software department felt the need to reinvent the wheel. The designers would not reuse the work I put into the software. They used a "superior" language, C. I don’t know just how much money was spent in acquiring tools, but it was certainly a lot more than we had used. The designers also required us to add hardware for a special development connector. These devices added approximately $5000 to development costs and a couple of bucks to each unit sold.

The software designers took several months to gain the level of control that I had within two weeks. The team took an even longer amount of time to reach our post-test level of function. I believe the team is still working through the details, nearly a year later. To be fair, the software team’s goals are more comprehensive than ours were, but, I am certain that the Forth program could have exceeded these goals in one-quarter the time.

Sam Mullins
Mallinckrodt Sensor Systems Inc
Ann Arbor, MI