68HC05-Based Peripheral Devices: Part II

The authors are engineers at Motorola, and can be contacted at r20367@ email.sps.mot.com.

Although the IBM AT's keyboard port is the primary means of user input, you can also use it as the power supply and communications link for small low-power computer peripherals. In this two-part article, we present a system model around which such peripherals can be designed. The application we present is a Caller ID peripheral device based on the Motorola MC68HC(7)05P9 microcontroller. This device is capable of receiving Caller ID transmissions and displaying the received data on an AT-compatible computer. Last month, we focused on the Caller ID protocol and hardware design issues. This month, we complete our discussion of the hardware and zero in on the software.

The Caller ID Data-Acquisition Block

The Caller ID data-acquisition block performs two functions within the application's system design:

• Provides an electrical interface to the telephone line.
• Demodulates and validates the Caller ID analog signal and converts it to a digital bit stream.

Though many Caller ID designs implement these functions with discrete analog circuitry, we selected a more integrated solution for this application -- Motorola's MC145447 Calling Line Identification Receiver with Ring Detector. This device provides the needed interface to the telephone line, demodulating the BFSK asynchronous data signal, and outputting a digital stream. The design of this block was largely taken from the application note section of the technical data sheet for the MC145447. The device also has a number of signal validation and power saving features that are useful for Caller ID designs for which low power-consumption is an issue. Since this application is powered by the host computer's keyboard interface, it does not use any of the MC145447's power saving modes.

The MC145447's interface to the telephone line's twisted pair can be divided into two types of signals: Caller ID data acquisition signals and ring detection and validation signals. The ring detection and validation signals serve to detect the presence of a valid ring signal on the twisted pair and participate in bringing the device out of power-down mode. There are four signals that comprise the ring detection and validation portion of the interface. Three of the signals -- Ring Detect IN 1 (RDI1), Ring Detect IN 2 (RDI2), and /Ring Time (/RT) -- are inputs. There is also one output -- /Ring Detect Out (/RDO) -- which is asserted when a valid power ring is detected on the telephone line twisted pair. The /RT pin works in conjunction with the RDI1 pin to generate internal signals that are part of the device's power-up circuitry. To conserve power, the MC145447's power-up circuitry applies power to different sections of the device as they are needed.

In the power-up sequence, the /RT and RDI1 signals are used to activate power to the Ring Analysis section of the device. This section determines whether a valid ring signal is present on the twisted pair. As the schematics in Figure 1 shows, the voltage at the RDI1 pin is provided by resistor R10, which is part of a voltage divider circuit comprised of resistors R10, R11, and R12. (More complete schematics are available electronically in .EPS format; see "Resource Center," page 3.) The resistor network divides an AC coupled, rectified version of the voltage present between the tip and ring sides of the twisted pair into voltages that are sampled by the RDI1 and RD2 pins. The value of R10 is chosen such that if a voltage of 40Vrms or more is present on the twisted pair, which indicates that a power ring might be taking place, the RDI1 pin and its associated circuitry will turn power on to the Ring Analysis circuitry. The /RT is connected to a RC combination that holds the pin low during the low periods of a power ring. The RDI2 pin serves as the only input to the Ring Analysis section. The signal at this pin is provided by resistor R12 of the divider network. The duty cycle of this signal is used to validate the presence of a power ring. In the event that a power ring is detected, the Ring Analysis circuit asserts the /RDO pin.

The data-acquisition signals on the MC145447 consists of a Tip input (TI) and Ring input (RI) pin. The TI is AC coupled to the tip side of the telephone line's twisted pair through capacitor C7. The RI signal is AC coupled to the Ring side of the twisted pair through capacitor C8. The signal that is presented to these two pins is demodulated and converted into the digital stream that is output by the device.

In our application, the MC145447's interface with the system's microcontroller consists of three pins -- the Data Out Cooked (DOC) pin, the /Ring Detect Out (/RDO) pin, and the /Power Up (/PWRUP) pin. The MC145447 outputs a digital stream on two pins, which are the Data Out Cooked (DOC) pin and the Data Out Raw (DOR) pin.

The DOR pin outputs the entire data stream demodulated by the device starting with the Channel Seizure and Mark Signals and ending with the checksum byte at the end of a transmission. The DOC pin, on the other hand, outputs data after a transmission passes an internal data validation process and does not output the Channel Seizure and Mark Signals. Data is captured by the MC68HC(7)05P9 by connecting DOC to pin PC3 on the MC68HC(7)05P9, which is configured as an input.

The /RDO pin is connected to pin PC2 of the MCU, which is configured as an input. As stated earlier, the /RDO pin is asserted when a valid power ring is detected on the twisted pair. The assertion of the /RDO pin, along with the start of the transmission of data within 0.5-1.5 seconds after the deassertion of /RDO, is used by the MC68HC(7)05P9 to qualify the start of a data stream from the MC145447.

The MC145447 has a requirement that its /PWRUP pin be at a Logic 1 for a minimum of 10mS after VDD reaches its full value. Typically, this requirement is met by delaying the assertion of /PWRUP with a RC circuit. To eliminate the need for these two components, the /PWRUP pin is connected to the MC68HC(7)05P9's PC3 pin, which is configured as an output. This pin asserts /PWRUP after an appropriate delay.

The Keyboard-Interface Block

The main function of the keyboard-interface block is to transmit Caller ID data captured from the MC145447 to an AT-compatible host computer through its keyboard interface. Pins PA0 and PA1 of the MC68HC(7)05P9 serve as the application's keyboard interface's data signal. PA0 is configured as an output and is used to transmit data to the keyboard interface. PA1 works in conjunction with PA0 and is configured as an input. This arrangement satisfies the AT keyboard interface requirement that the keyboard interface data line be a bidirectional signal that is capable of both transmitting and receiving data to/from the host. Pins PA2 and PA3 function in a way that is similar to the PA0-PA1 pin pair. PA2 is configured as an output and generates the clock signal required for both keyboard-to-host and host-to-keyboard data transfers, and PA3 is confirmed as an input that reads the level on the clock line.

Though the clock signal never functions as an input as does the data line, the AT keyboard interface protocol requires that its level be monitored in the event that the host wishes to transmit data to the keyboard. Since PA0 and PA2 are not open-collector outputs, they cannot be directly connected to the data and clock signals of the keyboard and keyboard interface. Therefore, a 7407 open-collector buffer serves as the interface between the MCU's keyboard interface signals and those of keyboard and the keyboard interface.

The design of the keyboard interface does not allow the keyboard to be connected to the interface while another device is transmitting to it. Therefore, the Caller ID device must disconnect the keyboard's clock and data signals from those of the keyboard interface whenever it transmits to the host. Port A pin PA5 is configured as an output and serves as the control signal for the 4066 analog switches that connect or disconnect the keyboard's signals to those of the interface. The number of tasks that a host computer's CPU may need to perform may prevent it from processing a scan code at the time that it is received at the keyboard interface. To prevent user keystrokes from being lost, the keyboard-interface protocol provides for a busy signal that the host sends to the keyboard to prevent it from sending scan codes until the host can process them. The host signals the keyboard that it is busy by holding the clock line low until it can accept new scan codes. While the host is busy, the keyboard stores the scan codes for new keystrokes in its internal buffer. To prevent the loss of any keystrokes that may be generated while the Caller ID device is transmitting to the host, the MC68HC(7)05P9 pulls the clock signal low after it disconnects the keyboard's signals from the interface. Port A pin PA5 is configured as a output and performs this function.

Keyboard Caller ID Device Software-Design Overview

The software design of this application is divided into two parts -- the firmware that resides on the MC68HC(7)05P9 and CALLERID.EXE. The firmware's main function is to capture the raw digital data stream generated by the MC145447 and transmit it to the host computer for further processing (source code for the firmware is available electronically; see "Resource Center," page 3). Data is transmitted to the host in the form of keyboard scan codes that are sent through the host's keyboard interface. The host receives the scan codes and interprets them as keystrokes. The sequence of simulated keystrokes is read by CALLERID.EXE, which parses and converts the string back into binary data from which it extracts Caller ID information. CALLERID.EXE (source code for CALLERID.EXE is available electronically) then formats and displays the data in a pop-up dialog box. This division of functionality between the Caller ID device and the host computer allows for the greater portion of processing to be off loaded to the host computer where a larger amount of resources are available. This reduces the functionality of the Caller ID device thus allowing its design to be implemented with a smaller and cheaper microcontroller.

Keyboard Caller IDDevice Firmware Design

As Figure 2 illustrates, the Caller ID device's firmware follows this program flow:

1. On reset, the general I/O pins on the MC68HC(7)P9 are configured and initialized to implement the Caller ID device's hardware design.
2. The firmware waits in a loop for the assertion of the MC145447's /RDO signal that is monitored on the MC68HC(7)05P9's PC2 I/O pin. The assertion of this signal indicates that a power ring has been detected on the twisted pair.
3. If the MC68HC(7)05P9 detects that the MC145447's /RDO pin is deasserted and a start bit on the DOC pin, the conditions are met for the MC68HC(7)05P9 to begin monitoring for a transmission.
4. The MC145447 transmits the CALLER ID data to the MC68HC(7)05P9 in the form of a raw digital stream on its DOC pin. The MCU reads the data from its PC0 pin.
5. On receiving the data from the MC145447, the MC68HC(7)05P9 parses the stream into individual bytes and checks the data for a parity error. If a parity error has been detected, it is flagged by a global variable, otherwise the data is converted into an array of AT keyboard scan codes for transmission to the host computer.
6. The application transmits a <CONTROL L> keystroke sequence as a series of scan codes. This interrupts the application that currently has the focus in Windows 95, activates CALLERID.EXE, and gives it the focus.
7. If a parity error was not detected during the reception of the CALLER ID data, the scan code array that represents the received data is transmitted to the host computer, otherwise an error code is sent.
8. The firmware returns to monitoring the twisted pair for a new Caller ID transmission.

The firmware's functions can be divided into three types of routines:

• Device initialization routines.
• Caller ID data-acquisition routines.
• Keyboard interface routines.

The device initialization routines configure and initialize the MC68HC(7)05P9's I/O pins to implement the application's hardware blocks. As mentioned earlier, Port A I/O pins PA0-PA5 are configured to implement the keyboard interface block, while three Port C pins, PC0, PCG, and PC3, serve as the MC68HC(7)05P9's interface to the MC145447. All remaining general-purpose I/O pins are configured as outputs to eliminate the need for pull-up resistors on them. The data acquisition routines of the firmware consists of the sampling and time delay routines that capture data from the MC145447's DOC line. The MC68HC(7)05P9 samples the data stream at its PC3 pin and parses it into individual bytes. The fact that each piece of Caller ID data begins with a start bit and ends with a stop bit, makes it easy to delineate between individual bytes. The time delay functions used for data acquisition routines are not only used to sample the bits within a byte but must also allow for the inter-character delays that the Interface allows.

The keyboard-interface firmware mainly consists of a transmission routine and its accompanying time delay functions. The keyboard interface's transmit function has within it a call to a routine that is capable of receiving host computer commands. If the host computer detects an error in the data that was sent to it by the keyboard, the host will hold the data low after bad transmission. The host will then send a Resend command (0xFE) to the keyboard requesting a retransmission of the data. Therefore, the Caller ID device must have a receive routine in the event that an error occurs.

For this application, the number of retransmission attempts was arbitrarily set at 1. Therefore, if an error occurs when the device sends a byte to the host, the device will capture the host's resend command and attempt a retransmission of the data. If the retransmission fails, the device will reconnect the keyboard's clock and data signals to those of the host and return to monitoring the telephone line. To transmit data to the host, the transmission routine toggles PA0, which is the data output signal, and the PA2 pin, which is the clock output signal, in accordance with the timing specifications for keyboard-to-computer data transfers. The host command reception routine reads the data from the PA1 pin and toggles the clock signal in accordance with the timing specifications for computer-to-keyboard data transfers.

CALLERID.EXE Design

CALLERID.EXE's design is divided into two parts -- CALLERID.EXE (the executable program) and CALLDLL.DLL (the DLL containing the global hook function). Both modules were compiled with Microsoft Visual C++ Version 2.0. CALLDLL.DLL's code consists of a function to install the keyboard hook function and the hook function itself. In the code's call to the Windows API's SetWindowsHookEx function, the idhook parameter is set to WH_KEYBOARD, which is a predefined value that configures the hook function to handle keyboard events. This code is placed in a DLL because Windows 95 requires that global hook functions reside in a DLL. The keyboard-hook function in this application must be global in scope so that CALLERID.EXE can be invoked regardless of what application may currently have the focus in Windows 95. The only limitation with CALLERID.EXE is that it will not be invoked if the current window with the focus is a DOS window.

The main function of the executable is to receive the Caller ID data from the Caller ID device, format it, and display it in a dialog box on the PC's monitor. As Figure 3 illustrates, the program flow of the executable is as follows:

1. CALLERID.EXE is invoked immediately after Windows 95 boots up. The main window of the CALLERID application is initialized to come up in the hidden state. This causes CALLERID.EXE to begin executing in the background of Windows 95.
2. CALLERID.EXE accesses CALLERID.DLL and installs the keyboard hook function into the Windows 95 stream. The hook function now examines each keystroke that is entered by the user for the <CONTROL L> hotkey sequence.
3. On detecting a <CONTROL L> key combination, the keyboard hook function calls the Windows API FindWindow(), function to locate the application's hidden main window. The Windows ShowWindow() function is then called to activate CALLERID.EXE's main window and give it the focus in Windows 95.
4. CALLERID.EXE displays a pop-up dialog box on the monitor displaying the text: "Receiving Data...".
5. The application waits for a keystroke from the Caller ID device.
6. If CALLERID.EXE receives a ";" character from the Caller ID device, the device has detected a parity error in the Caller ID data received from the telephone line. The CALLERID.EXE will then display "Line Error" in the dialog box: Otherwise, it acquires the full stream of Caller ID data from the device.
7. C-string manipulation functions are used to parse the string into the two character segments that represent each byte of Caller ID data. C string conversion functions are then used to convert each ASCII segment into the original binary data that was captured on the Caller ID device.
8. CALLERID.EXE formats the binary data so that it can be displayed in the dialog box. CALLERID.EXE will format data according to whether the Caller ID data received is in the SDMF or MDMF format.
9. The Caller ID information is displayed in the dialog box. The dialog box remains displayed until users press one of the box's OK or Deactivate buttons.
10. The dialog box is hidden again if the user presses the OK button. CALLERID.EXE then returns to waiting for a hot key sequence. If the Deactivate button is pressed, CALLER.EXE will be deactivated and will no longer function until Windows 95 is reset.

Keyboard Caller ID Device Operating Instructions

To use the Keyboard Caller ID system we've presented here:

1. Copy CALLERID.EXE to the hard drive and directory of your choice. A suggested path might be: C:\CALLERID\.
2. Copy CALLDLL.DLL to the C:\WINDOWS\SYSTEM\ directory.
3. Add CALLERID.EXE to the Windows 95 Start Menu.
4. Disconnect the keyboard's connector from the host computer's keyboard port.
5. Connect the Keyboard Caller ID device to the host computer's keyboard interface.
6. Connect the keyboard's connector to the receptacle for it on the Keyboard Caller ID device.
7. Connect the telephone line to one of the R-J11 connectors on the Keyboard Caller ID device.
8. Connect a telephone extension line between the Keyboard Caller ID's second R-J11 connector and your telephone. This completes the hardware installation of the Keyboard Caller ID device.
9. Shut down and restart Windows 95.
10. Caller ID should now activate. Caller ID will display a dialog box with Caller ID information every time a valid transmission is received. To deactivate the program, press the Deactivate button in the dialog box.

References

Holzner, Steve. Advanced Visual C++ 4. M&T Books, 1996.

Konzak, Gary J. PC Keyboard Design. Second Edition, Annabooks, 1993.

Motorola MC68HC705P9 Technical Data Specification.

Motorola MC145447 Technical Data Specification.

Messmer, Hans-Peter. The Indispensable PC Hardware Book: Your Questions Answered. Addison-Wesley, 1994.

LSSGR: Voiceband Data Transmission Interface Section 6.6, GR-30-CORE, Issue 1, Bellcore. December 1994.

"Message Type Values for SDMF and MDMF." Digest of Technical Information Bellcore. May 1996.

DDJ