The HP 48SX calculator input/output system

WHEN HANDHELD CALCULATORS were first introduced in the early 1970s, they provided portable computation without much memory. The limited keyboard and one-line numeric display provided just about all the input/output needed to use this capability effectively. As the incorporation of advancing memory technology made possible the storage of larger amounts of data and even programs created by the user in these handy little machines, the keyboard and display became an intolerable bottleneck. The need to enter a thousand or so keystrokes manually to use a program that someone else has written is quite an effective barrier.

The first solution to this problem was to use small magnetic cards to store the data and programs. There were some difficulties with power consumption, physical size, mechanical wear and tear, and cleanliness, but this mode of input/output was the accepted standard for some time. Eventually, however, larger and larger memories began to outstrip the capacity of the cards. This, combined with a need to communicate with other types of devices that did not use magnetic cards, necessitated a new approach.

The HP-IL (Hewlett-Packard Interface Link) was an electronic interfacing system that was designed with the needs of calculators in mind. It allowed systems with several devices to be configured automatically and controlled by a calculator. These devices included printers, mass storage, adapters to other interface systems, and even instruments. In many ways, it was superior to existing electronic interfaces, but this was not sufficient to overcome the inertia of the massive installed base of these other devices. Prices of calculators continued to drop and patterns of use changed as personal computers became ubiquitous. For these and other largely nontechnical reasons, HP-IL was no longer the ideal input/output medium for the majority of HP calculator users.

One area of serious complaint with calculators and electronic interfaces had been the cost and inconvenience of the cables. In addition, some calculators were so thin that even the HP-IL connectors, designed for small size, were unacceptably large. The most pressing need for these machines was to provide some form of hard-copy output to a low-cost portable printer. Drawing upon technology similar to that used in infrared remote control of TVs and VCRs, HP introduced a printer and a line of calculators that met the basic need with an interface that gave customers what they wanted: no cables at all. The only disadvantage was that this infrared connection was output-only.

Input/Output Needs of the HP 48SX

Market research indicated that an overwhelming majority of high-end calculator users either owned or had access to a personal computer. Clearly, it would be an advantage to be able to perform the data-entry-intensive tasks with the large keyboard and display of the personal computer and the computation-oriented work with the simple and powerful applications resident in the calculator. In other cases, the portability of the calculator was essential for part of the job and the speed and capability of the personal computer and its associated peripheral devices satisfied the rest of the need. These considerations forced the primary objective for the input/output capability of the HP 48SX scientific expandable calculator: an easy-to-use connection to existing personal computers.

In addition, there were two secondary objectives. While most users would choose to satisfy their needs for hard copy with the printer connected to their personal computer, there would be some applications where portable printing was essential, and perhaps some users who needed simple hard copy without access to a personal computer system. Also, our experience with the HP 41 calculators had shown that users of this class of machines do a lot of sharing of programs and data. In consequence, it was felt necessary that the HP 48SX be compatible with the existing infrared printer and that there be a convenient way to do input/output directly between calculators. Fig. 1 illustrates the desired input/output connections.

The most common interface on personal computers is the RS-232 serial port. It would be much too costly and inconvenient to require the customer to buy a special card for the personal computer, such as an HP-IL or infrared interface, to connect to the calculator. Development of these cards would be costly, too, since there are several different types of personal computers. These considerations quickly led to the decision to design into the HP 48SX the capability to connect directly to the serial port already in nearly all personal computers. This required a custom connector and cable, since the traditional DB9 or DB25 connectors used with RS-232 were much too large.

The requirement for program and data sharing between calculators could also be satisfied with RS-232, but the need to have the cable and/or some special calculator-to-calculator adapter was a severe drawback in this situation. A one-way infrared interface was already needed to maintain compatibility with the infrared printer. Would some enhancement of this interface fill the need without requiring the user to carry around a cable? Some investigation showed that a simple infrared receiver circuit for very short distances could indeed be included with minimum impact on the design.

The input/output solution for the HP 48SX is really two solutions, each optimized to particular requirements: the serial port for the important connection to personal computers, and a new two-way infrared interface for compatibility with the portable printer and for calculator-to-calculator communication. The plug-in memory cards, which are essential for memory expansion, might also be considered part of the solution. The RAM cards with built-in battery can be used for archiving and backup purposes and for program and data sharing between calculators as well. This provides only a partial solution, however, and the relatively high cost of the cards makes it very desirable to provide these functions in other ways also.

The input/output capability consists of not only the electronics, but the protocol and software to allow the user to move data easily. Here again, what was widely available for the personal computer was the important consideration. The Kermit protocol' was chosen because it provides automatic retransmission to correct errors, is widely used, and is available essentially free of charge for all the major types of personal computers. It was decided to include the Kermit protocol as one of the built-in applications in the HP 48SX. The Kermit protocol is applied to both the serial interface and the infrared interface, so the user only needs to learn one simple application for most input/output needs.

The Serial interface

RS-232 uses bipolar signaling, that is, different logic states are indicated by voltages that swing both above and below the ground reference level. The HP 48SX does not otherwise need to generate a negative voltage, and it would seriously complicate the system design to have to do so. While integrated circuits are available to perform this function, their cost and power requirements are prohibitive in the calculator. One possible solution was to use unipolar signaling. While this is not really RS-232, most receiver circuits change the indicated logic state at about one volt positive, and will therefore function acceptably with a unipolar input. There are a few serial interfaces on personal computers, however, with input thresholds that really are set at zero volts. These would not work reliably with unipolar signals, and worse yet, customers have no easy way to tell which type of interface they have.

The solution to the problem was found in clever use of the voltages the HP 48SX generates to drive the LCD display. The logic in the calculator works between zero volts and the VDD SUPPLY, about 4.3 volts. The display works between zero volts and the [V.sub.H] supply, about 8.4 volts. Because the calculator has no external ground connection to any other device, it does not matter what voltage level we use as the ground reference for the serial port. By using the [V.sub.DD) supply as the signal ground, we can drive the TXD (transmit data) line to calculator ground and it will be at -4.3 volts as viewed by the receiving device. Likewise, driving the line to V, will make it appear as + 4.1 volts ([V.sub.H]-[V.sub.DD]) at the serial port. The result is a bipolar signal that will work with all serial ports without the additional expense and power of special integrated circuits.

Technically, an RS-232 device is required to swing at least 5.0 volts above and below signal ground. After various circuit losses, the HP 48SX voltage swing is only a little more than three volts positive and negative under worstcase conditions. It would have been convenient if the power supplies were at a slightly higher voltage, but this was not possible since the CPU integrated circuit has a maximum voltage limit of about nine volts. Even though this does not strictly comply with the requirement, it works quite well with short cables since an RS-232 receiver is required to indicate a logic zero for + 3.0 volts or more and a logic one for - 3.0 volts or less. The slightly reduced noise margin has had no noticeable effect.

It would have been convenient, though slightly more costly, to use a standard driver/receiver integrated circuit to provide the necessary short-circuit protection and comply with other interface requirements. Unfortunately, these parts are not specified at the low voltages used by the HP 48SX and their higher voltage drop would have caused the output to be less than what was needed. Strict limitations on the amount of current that the two power supplies in the HP 48SX can source or sink also mandated a discrete circuit to satisfy all the needs.

Considerable experimentation resulted in the circuit of Fig. 2. When the TX line from the CPU is driven high (V.sub.H), current flows through R2, Q8, and CR5 to the TXD pin and the load in the receiver of the other serial device. If this current exceeds about 4 milliamperes, the voltage drop across R2 will turn on Q7. This will cause the voltage at the base of Q8 to rise, tending to turn Q8 off. Thus the current that will flow is limited regardless of the voltage on the TXD pin. Because the circuit is symmetrical, precisely the same action occurs with Q2 and Q3 when TX is driven low (calculator ground). The Schottky diodes, chosen for their low forward voltage drop, are necessary to prevent reverse conduction through whichever side of the circuit is off. The capacitor on the TXD pin slows the rise and fall times of the signal to minimize electrical noise generation. The 12-volt Zener diode on the TX line provides additional protection to the CPU from electrostatic discharges. Capacitor C4 is needed to provide dc isolation between the calculator shield, which is at calculator ground potential, and the shield of the other device, which is likely connected to signal ground, which is connected to the calculator [V.sub.DD] supply. Without this capacitor, the calculator VDD power supply would be short-circuited.

Receiving RS-232 signals in the calculator is a relatively simple matter. When the RXD (receive data) line swings positive, the 2.4V Zener diode allows the voltage to rise above the logic threshold of the RX input on the CPU chip (about one volt above VDD), but clamps it below the CPU V, power supply so that excessive current cannot flow. A similar situation occurs for negative swings as the diode conducts in the forward direction. The 5.6-kilohm resistor limits current and presents the proper impedance for an RS-232 input. The 1.5-kilohm resistor adds additional short-circuit and ESD protection for the CPU RX input. The 75-ohm resistor merely provides a protective current limit between signal ground and the [V.sub.DD] supply.

The infrared interface

Transmitting infrared light is relatively simple from the viewpoint of the hardware. Fig. 3 shows the schematic diagram for the infrared transmitter and receiver circuits. Because of the high current pulses needed to drive the infrared LED, it is connected directly to the batteries, greatly reducing peak demand on the calculator power supply. The other end of the LED is driven low by a special constant-current driver circuit integrated on the CPU chip. Pulse duration and timing are controlled by a combination of hardware in the CPU and firmware.

A phototransistor was chosen as the receiving element. While much slower than a photodiode, it is fast enough for the data rate of 2400 bits per second, and the sensitivity is much greater. Since high ambient light levels can cause relatively large currents to flow in the phototransistor, Q4, some means had to be found to reduce or stabilize the bias current. It would not be acceptable for battery life to be considerably shorter in sunlight than in the office. For this reason, the phototransistor chosen is one that has all three terminals accessible. The combination of this feature and transistor Q5 provides the needed stabilization. If the quiescent current of Q4 increases, this increase goes into the base of Q5, which in turn conducts more current away from Q4's base terminal, tending to reduce its quiescent current. In the office, the total current resulting from the infrared receive circuit is only about seven microamperes. In direct sunlight, this value rises to nearly 200 microamperes. This

The higher-level I/O commands don't use XON/XOFF handshaking since they follow the Kermit protocol, which has packets of at most 96 bytes.

The simplest I/O interface for the user is the two-way infrared interface, which has no wires to mix up, doesn't use XON/XOFF handshaking, and is fixed at 2400 baud and no parity.

All I/O commands on the HP 48SX automatically turn on and initialize the appropriate I/O port (RS-232 or infrared) based on the data from IOPAR. Once the port is ready, the HP 48SX interrupt system receives bytes for either RS-232 or two-way infrared I/O. The HP 48SX can respond quickly enough to incoming bytes so that even at 9600 baud the interrupt system will read the first byte before it is overwritten by the next one. Incoming bytes are placed in a 255-byte input buffer. The interrupt system waits for about four byte times before concluding that the incoming byte stream has ended. Then, before exiting, it checks for other sources of interrupts such as cursor blink, clock ticks (if the clock is ticking in the display), alarms, cards pulled out or added, or keys down or up.

All of these checks can make the time required to exit the interrupt system and then reenter long enough that incoming bytes may be missed. For this reason, alarms, key presses, and the clock display should be avoided during I/O.

Low-Level I/O Commands

The HP 48SX provides a triplet of low-level I/O commands: XMIT (transmit), BUFLEN (buffer length), and SRECV (serial receive). They are intended for use in programs, so instead of stopping the program when an I/O error occurs, they simply return a succeed/fail flag to level 1 of the stack. This allows the programmer the option of handling the error without having to use IFERR. XMIT transmits a string from the stack, using XON/XOFF handshaking if transmit pacing is enabled. BUFLEN tells how many bytes are in the input buffer. SRECV reads a specified number of bytes from the input buffer (waiting for more to come in if necessary) and returns them as a string to the stack.

Supporting commands are STIME (serial timeout), SBRK (serial break), OPENIO (open I/O port), and CLOSEIO (close I/O port). STIME sets the length of time that XMIT (XOFF received, transmit pacing enabled) or SRECV will wait before giving up if the data flow is interrupted. SBRK sends a serial break. OPENIO and CLOSEIO turn the I/O port on and off.

As pointed out earlier, bytes can be lost during I/O transmissions. If the I/O connection is noisy, bytes can be garbled. It is also possible that some communication channels will remove certain bytes (usually control characters) from the data stream. The low-level I/O commands have no protection from this type of data corruption except for parity checking. The Kermit protocol chosen for higher-level I/O commands overcomes these problems to give more reliable communication for transferring programs and data.

The Kermit Protocol

The Kermit protocol encodes control characters as sequences of ordinary printable characters so they can pass safely through to the destination. Garbled data is detected by the checksums on each packet and lost packets are detected by the sequence number on each packet. A Kermit protocol packet consists of a mark byte to mark the start of a packet, a length byte, a sequence number byte, a type byte, data bytes, and finally one to three checksum bytes. The type byte defines the type of the packet.

A typical Kermit protocol transmitter sends the following packet sequence. After sending each packet it waits for the receiver to send either an ACK packet (type Y) to indicate successful receipt of the packet or a NAK packet (type N) to indicate a garbled packet. If the receiver doesn't respond, the transmitter can time out and resend.

Sequence  Packet
 Number    Type   Description
   0         S    Negotiates parameters such as
                  maximum packet length, time-out,
                  and control character encoding.
   1         F    Contains the name of the file
                  to be sent.
   2         D    Data (as many packets as necessary).
   .         D
   .         D
   n         D
  n+1        z    Marks the end of this file. May be
                  followed by another F,D,...,D,Z
                  sequence or by B.
  n+2        B    Marks the end of the whole transfer.

The packet sequence numbers wrap back to 0 after packet 63. If either the transmitter or the receiver encounters a fatal error, it can send an error (type E) packet to tell the other unit to give up also.

The Kermit protocol has another mode setting in addition to parity and baud rate: text versus binary. Computers sending text files are required to end each line of text with a carriage return character followed by a linefeed character. If a computer normally uses some other line terminator, such as a single linefeed, it must transform linefeed to carriage return plus linefeed when sending text files, and must translate carriage return plus linefeed to linefeed when receiving text files. If a computer normally terminates text lines with carriage return plus linefeed, no transformations are needed. This works fine for text files but not for binary files like compiled programs unless the transmitter and receiver both do the transformations or both don't do them. Therefore, to send a binary file, a computer that has text and binary modes must be set to binary.

The HP 48SX greatly extends this concept of text (ASCII) versus binary files by automatically converting an object to string form when sending in ASCII mode, thus converting a binary object into its text form. In addition, the HP 48SX has a 256-character character set based on the ISO 8859 Latin 1 character set. This is not compatible with many current PC character sets, so translation modes were added to ASCII transmission to convert the new character codes to sequences of normal ASCIT characters. To ensure the accurate interpretation of the automatically generated text form of objects, a header string is prepended to the object. This string contains the modes in effect when the text form of the object was created. The modes are the translate mode to allow proper "untranslation"), angle mode (in case the object contains a complex number in polar form), and fraction mark (to distinguish decimal points and argument separators). The header string also allows a receiving HP 48SX to know that it should receive this object in ASCII mode. A short header is also prepended to binary objects to instruct a receiving HP 48SX to receive in binary mode. At the cost of this small amount of extra overhead, a receiving HP 48SX can correctly interpret an incoming file even if its modes are set differently than would be required for that file.

Acknowledgments

Preston Brown and Les Moore did the investigation and design of the IR receiver circuit. Tom Lindberg designed the HP 48SX serial connector and cable. A special thanks goes to the inventors and implementors of the Kermit protocol. The wide availability of this protocol on many machines greatly enhances its value in the HP 48SX.

References

1. F. da Cruz, Kermit-A File Transfer Protocol, Digital Press, 1987.

2. S.L. Harper, R.S. Worsley, and B.A. Stephens, "An Infrared Link for Low-Cost Calculators and Printers," Hewlett-Packard journal, Vol. 38, no. 10, October 1987, pp. 16-21.

COPYRIGHT 1991 Hewlett Packard Company
COPYRIGHT 2004 Gale Group