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.
Adapted from an article that appeared in Personal Engineering & Instrumentation
News.
Return to the article index.
|
