SLTF Consulting
Technology with Business Sense

 Home | Bio | Contact Us | Site Map


 

Standard ICs make it difficult to build an alarming instrument

Scott Rosenthal
January, 1994

My last column (Ref 1) discussed the rationale behind using audible tones and alarms in embedded instrumentation. Briefly, the purpose of such sonic alerts is to convey information. However, if the user ignores or misinterprets the information the alarm is trying to convey, the audio indicator is worthless. To prevent possible misinterpretation and reduce the general racket resulting from alarms in a hospital setting, the European Community adopted a requirement for all new instrumentation sold starting January 1, 1995. This requirement sets forth the type of sounds instrumentation should make including tone frequency, duration and repetition rate. In this column, I'll describe how my firm developed a solution to this European specification.

The search begins

As with any design, I began by getting all the facts. Although initially it seemed that all I'd need was a tone generator, a careful look at the spec proved otherwise. The basic idea was simple enough-just a series of tones sent out in a specific pattern like Morse code. Looking closer, though, I saw two gotchas in the requirements. First, the circuit needed an adjustable volume level. Second, it had to control the tone burst's attack and decay (rise and fall times). All of a sudden, this simple tone generator acquired the need for a rudimentary envelope-function generator. In so doing, it ruled out all simple approaches such as toggling a bit to drive a speaker or audio transducer or enabling a Sonalert beeper. Still, the problem couldn't be that difficult. We're not talking Moog synthesizers or anything like that, right?

My first thought was to again use a sound generator chip from Philips-the SAA1099-that I incorporated into an earlier instrument. This chip provides adjustable volume, envelope and frequency and costs approximately $8. So I quickly designed it into the instrument only to find out that Philips had discontinued the part. What an industry we work in! I looked for a similar chip but couldn't find anything.

Then I remembered a chip that Texas Instruments made back in the '70s. It was a miniature synthesizer that could easily produce the sounds of sirens, gunshots, explosions, "phaser" fire or anything else imaginable. To do so, it obviously had an envelope generator, which also meant that it had a volume control. I rummaged through some old parts boxes trying to find the one chip I purchased many years ago to interface with an Ohio Scientific computer I owned at the time (I thought the Apple II wasn't commercially viable). Of course I couldn't find it, but I did talk to TI and discovered they stopped producing general-purpose sound generator chips.

Now desperately searching for other types of tone-generating chips, I looked into those used in electronic keyboards. They could easily do the job, but questions of chip availability (present and future) and application assistance arose. Next, I checked into electronic telephone ringers. These chips are inflexible and might not meet all requirements. I also considered a class of chips that recorded sounds and stored them (in analog fashion) inside specialized serial EEPROMs. These chips appeared interesting, but the technology raised questions regarding mass programming, program control over tone parameters and where original tones would come from. Also, this technology is still too immature for my tastes, so I'll wait until it's a bit more mainstream.

I also investigated a multiple-chip solution, using a sine generator with a D/A for controlling volume and the envelope function. This solution presented not only cost problems, but it took a lot of board space and overhead from the computer.

A one chip solution?

Finally, remembering a column I wrote early last year (Ref 2) in which I outlined my case for distributing intelligence around an embedded system using low-cost microcontrollers, it occurred to me that maybe a dedicated microcontroller was the answer. Serving as an intelligent alarm-tone controller, the chip would fully implement the European specification and automatically take care of frequencies, durations, tone-burst periods and envelope functions for different alarm types. This idea was ambitious, but if it worked, the microcontroller would become a building block to use in future designs and an object-oriented approach to hardware/software design.

To begin the task, I searched for a microcontroller with a built-in D/A to control the envelope function, with no luck. Every microcontroller I found that said it had an analog output actually only had a PWM (pulse-width modulator) output. How then could I control both sine wave output and volume/envelope function with one PWM output? Also, how could the main CPU communicate with this alarm-tone controller?

Tackling the second question first, an ideal way to have a computer communicate with this controller would be through an I/O port. Specifically, the controller would look just like any other port or memory to the main computer-there would be Chip Select and Write Enable lines and an 8-bit data bus. The main computer could then instruct the controller on which alarm to generate and the programmable parameters for that alarm. The alarm-controller chip could act like an 8250-style UART, a 6845-style CRT controller, an SAA1099 tone generator or a myriad of other parts. However, I couldn't find any OTP (one-time programmable) or erasable parts with this feature, and my volumes aren't high enough for masked ROM parts. Instead, I settled for a serial interface using the I2C bus. Various controllers supported this bus, and it permitted a simple interface from the main computer to the controller.

Building the tones

Returning to the first question, it turns out that one PWM can control both the sine wave output and the volume/envelope function. First, though, you must understand how a microcontroller's PWM function operates. A PWM output toggles at a fixed frequency. The microcontroller divides each cycle period into multiple time slices of equal size. The counter in the PWM determines the number of slices; that is, if the microcontroller uses an 8-bit counter, each period consists of 256 slices.

For example, at the beginning of each cycle the PWM output is High. When the counter reaches a programmed value, the output goes Low and remains in that state until the counter reaches its maximum count value. Then, the PWM output goes High, the counter resets to zero and the process repeats.

Assuming, for example, that the PWM has an 8-bit resolution, a value of 128 means that the PWM output is High half the time and Low the other half (50% duty cycle). Likewise, if it has a value of 64, the PWM output is High for one quarter of the time and Low for three quarters (25% duty cycle).

Although you can use the PWM output directly as a pulse stream to control devices such as heaters, integrating the pulse stream produces an analog voltage. If you integrate a PWM output, you can generate any voltage between 0 and 5V (assuming your system's not based on 3V logic). A 50% duty cycle yields 2.5V, while a 25% duty cycle yields 1.25V.

So, making a sine wave now seems easy. The voltage output from the PWM (after an integrator) can control the amplitude and envelope. All it has to do is go from 0V to some level and back again to 0V to describe the sine wave. However, the process isn't quite so simple. If you apply an envelope function to this scenario, the sine wave wouldn't grow symmetrically around its zero, which would create a strange envelope function (Fig 1a).

Instead, I offset the sine wave output so that its zero was at the halfway point of the PWM, that is, a 50% duty cycle, and then built up the sine wave relative to this zero point. This technique allows the instrument to properly implement the envelope function while maintaining a proper sine wave (Fig 1b).

To implement the sine wave, the controller uses a 12-point look- up table. Each time the PWM restarts, it causes an interrupt in the microcontroller. Based on the desired audio frequency, every N interrupt causes the microcontroller to go to the next location in the lookup table. Depending on the volume and envelope required, the program uses another table to adjust the sine wave lookup value before passing it to the PWM hardware.

The result is a general-purpose alarm-tone generator. Through the I2C bus, the main computer can specify various alarm frequencies and volumes, initiate any one of four alarm types, temporarily mute an alarm or silence any alarms. In addition, we also took advantage of some unused I/O pins to implement a simple Alarm Needed input so, that if the primary CPU in a future project doesn't have an I2C output, the alarm-tone controller can still work. PE&IN

References

1. Rosenthal, S, "For alerting an operator, all beeps weren't created equal," PE&IN, Nov 1993, pgs 69-71.

2. Rosenthal, S, "Check out lower-performance processors, too," PE&IN, Jan 1993, pgs 60-62.



About Us | What We Do | SSM | MiCOS | Search | Designs | Articles

Copyright © 1998-2014 SLTF Consulting, a division of SLTF Marine LLC. All rights reserved.