University of Essex

School of Computer Science and

Electronic Engineering

CE162 Digital Electronic Systems

Asynchronous Serial Data Transmission

CONTENTS

Design and simulation using MultiSim

Hardware Implementation

Assessment

1
Introduction

The assignment is an open-ended design exercise to implement the Transmit part of the RS232
serial data transmission process that was formerly the main method of computer communication,
both machine to machine and machine to user. It is still available in the form of the COM ports of
most PCs, and can be implemented on those where the ports are absent by inserting a USB
interface unit. Unlike more recent developments in serial data transmission to and from
computers, like USB and FireWire, RS232 is relatively uncomplicated, and hence straightforward
to implement in a hardware laboratory or simulator environment.

The details of the signal format are discussed in the CE162 lecture notes, Section 1 starting at
page 1.26, to which you should refer.

This document is not an instruction manual on how to implement the system, but gives advice on
possible ways of doing it using standard logic devices, like gates, counters and multiplexers. You
should also research the Internet where complete designs are likely to be found (this is a fairly
popular design exercise in university Engineering departments!) However, these should be treated
with extreme caution: past experience suggests that some of the 'designs' are not all they seem,
and after detailed examination can be shown not to work as intended. Any external sources that
you do eventually use in your design should, of course, be acknowledged and referenced in the
usual way, and you should explain how it works in your report.

In the first three sessions, weeks 19-21, you are asked to design and implement a system using
the CAD package MultiSim. In weeks 23-25 there is a laboratory exercise where you can
implement the same (or modified) system in hardware. This can use the standard logic boards at
each bench position in the Hardware Laboratory, but you are free to use actual TTL devices and
plug-in breadboards if you wish (see the lab staff or Tony de Roy, the laboratory technician).
Output of the hardware implementation needs a slight modification to the TTL electrical signal to
make it compatible with RS232 and a PC COM port, but having done so it should then be possible
to visualise characters being sent from your hardware by using a terminal emulator program, like
PuTTY or TeraTerm. For this to be possible, the test characters must, of course, be from the
printable ASCII range.

Staff and a postgraduate demonstrator will be available in scheduled lab. sessions, but you can, of
course, work at any other time. Out-of-session queries can be emailed to Tim Dennis; where
appropriate a response will be copied to all members of the CE162 group.

Taking it a bit further?

1. A possible extension to the basic hardware system is to provide an 'exerciser' in the form of
an 8-bit counter that generates the full 8 bit binary sequence 0000 0000 – 1111 1111. Fed to
the terminal emulator you should at some stages of the count see 'sensible' character
sequences, at other times random graphic characters or nothing. Terminal emulators usually
offer a 'data capture' or 'log' mode which records raw binary input to a serial port; this can
subsequently be examined using a file probing utility like 'od' on a Linux system.

2. Investigate how to do the Receive part of the process, i.e. detect the Start Bit and generate
the appropriate clock waveform to capture the serial input sequence onto a parallel 8 bit
register.

2
Suggested Methods

The illustration below reproduces the RS232 signal example from the lecture notes – note that the
output polarity is negative (-4 V) for a Logic 1.

The system is essentially a parallel to serial converter, and can work in the following sequence.

1. Capture data byte to be transmitted onto an 8 bit register

2. Output one start bit.

3. Output data bits 0 to 7 (in that order, i.e. LSB first)

4. Output one (or more) stop bits – this is the RS232 quiescent or 'resting' state.

5. Done.

There are two possible implementations.

1. Shift Register

A 10-bit parallel-in, serial-out shift register is loaded with the data byte in parallel to bits 1 to 8. Bit
0 is always loaded with Logic 0 and bit 9 is always loaded with Logic 1 (by hardwiring the inputs).

The shift register is set to serial output mode, and is assumed to output bit 0 first. A counter
generates a sequence of 10 clock pulses. The shift register's serial output is inverted and level-
shifted to RS232 to form the output signal in the correct format.

3
2. Multiplexer* (recommended method!)

1. Load data into a parallel-in, parallel-out shift register.

2. A 10 to 1 multiplexer (more likely 16 to 1. Last 6 bits unused) has input 0 connected to logic
0 (start bit), bits 1 to 8 connected to the shift register and bit 9 connected to logic 1 (stop bit).
Remaining (spare) bits also connected to logic 1.

3. Multiplexer output is inverted and level shifted to fit the RS232 format.

4. To transmit a character, a trigger pulse resets a counter to zero, which then generates the
output sequence 0000, 0001, 0010,...,1001, i.e. 0 to 9. It stops counting on 1001, and
remains in that state until reset to zero. The counter clock runs at the selected Baud rate,
e.g. 9600 Hz.

5. The counter trigger pulse needs to be synchronous with the main timing clock.

6. Counter outputs feed the multiplexer Select inputs.

7. Retiming of the multiplexer output with a D-type flip-flop may be necessary to eliminate
'glitches' at bit transitions. (Where might these come from?)

In the Multisim implementation you can use any available TTL-family devices, but the hardware
version will have to be confined to those available on the Logic Boards.

The 'count to 9 and stop' element (4 above) is probably the heart of the system, followed by the
multiplexer. The counter should be designed and tested first. The multiplexer can be tested
separately, with its Select inputs coming initially from bit patterns stored in the Word Generator.
The Logic Analyser should monitor the serial output to confirm that the bit sequence is correct.

Assessment

The CAD and Hardware Lab components of the assignment are worth 10% and 15% of the marks
for the module respectively (successfully completing the MultiSim introduction exercises accounts
for a further 5%). Your CAD work must be seen (demonstrated) and checked-off by a member of
the laboratory staff during or before the lab session in Week 21 – see the final page of this
document for the CAD assessment sheet. A written report, which should include both the
hardware design and results (waveforms) and discussion of the CAD work (e.g. circuits and Logic
Analyser output images) is due in Week 30.

T J Dennis
January 2011

*A manufacturer's datasheet for sixteen to one and eight to one TTL multiplexer devices is
attached to this document.
4
5
6
CE162 CAD Assignment Assessment Form

Your name: Registration Number:

Mark: %

Comments

Assessor:

Date: