The Glass Teletype application

One of the classic serial communications applications is the so-called glass teletype, whose heart is an algorithm structured round a tight loop. Programs of this type are commonly used as the basis of terminal emulators, but they don’t make efficient use of either modern communication hardware or modern operating systems. There are two main reasons why this is so.

• The tight loop hogs the processor making it unsuitable for use in multitasking operating systems, as the glass teletype consumes CPU resources even when it has nothing to do.

• One call is made to whatever comms API the operating system provides for each character that arrives. There are no economies of scale offered for use in situations where either blocks or packets of character are being received. Consequently, receiving multiple characters at the serial port is extremely inefficient.

Because of these considerations, the API doesn’t provide the primitive facilities suitable for writing terminal emulators which implement the algorithm. Instead, a more complex but richer range of features is made available. Taken together, they make it easy to write serial communications routines which can perform well at high speeds and can also guarantee optimum performance in a multitasking environment. In particular, the two problems mentioned above are avoided as follows:

• All communications input and output is handled using asynchronous requests. This enforces good practise, as it simply isn’t possible for busy waiting loops to be written in communications software. An understanding of the way that asynchronous services are handled is essential to using the API, and a knowledge of active objects is probably needed for any serious communications application.

• Descriptors are used as multi-byte buffers for all serial input and output functions rather than sending or receiving individual characters. This minimises the overheads involved both in buffer management and in calls to the communications server. Clearly, it would still be possible to send and receive single bytes (by using descriptors containing a single byte) but this no longer appears to be a natural way of doing things.

As well as the issues just addressed, there are a number of other features that need to be understood before beginning to use the serial communications API.

• Opening serial ports is sometimes more complex than in other operating systems.

• In addition to the usual serial port settings which control items such as data format and flow control, there are also specific configuration settings that can be used to control the way that the asynchronous calls in the API behave.

Example code for a working glass teletype running inside the text shell can be found in the GlassTerm example, which shows how to handle all the concerns addressed so far, and is the source for the code extracts found here.

Asynchronous Services