Serial Communications – An Overview
Within the more general software development world communications programming is often
considered as something of a black art, with many practitioners observed solemnly reciting
the book of the dead over a hapless PC in their efforts to initiate or restore communications.
In fact, the situation is not so bad in reality, but is often not particularly well documented.
Let’s consider the Windows environment as this is likely to represent the platform of choice
for the majority of developers and users.
You will have noticed in your PC documentation and indeed within Windows itself,
reference to a little guy named UART (NS16550). His full name is Universal Asynchronous
Receiver / Transmitter and he is the chip inside your PC which handles the sending and
receiving of data via your com ports. When we speak about PC communications we usually
mean asynchronous serial communications. Asynchronous means that the data stream we
send includes start and
stop bits to mark the beginning and end of each character in the stream (in synchronous
communication clocks at either end of the data link maintain synchronisation between
devices). Serial means that the data bits are transmitted one at a time over a single wire (in
parallel transmission bits are sent in parallel over several wires). The objective in each case
being the transfer of data between applications and devices.
Anyway, back to Mr. UART. He has a collection of registers, eight in fact, which enable him
to communicate with your application via the Windows communications driver and the
User.exe library. These registers are a little like pigeon holes and he uses them dynamically
in order to note information about line parameters, interrupts, line status and so on. He also
has a pretty young lady assistant called FIFO, whose full name is First In, First Out. She
collects
incoming information into a small (16 byte) buffer until it can be retrieved by your
application, ensuring that you do not lose any of those pesky little bits flying up and down the
line. As you can imagine, UART and FIFO have their work cut out for them when there is
active communication going on and it is important that they know how things are supposed to
be set up, which brings us on to line parameters.
You may have noticed strange inscriptions like “9600.N.8.1” cropping up in some of your
communications programs. These are referring to line parameters such as baud rate (usually
interpreted as bits per second but actually means events per second), parity (a bit checking
scheme which adds up the bits within a byte and then adds a final bit called the parity bit to
ensure that the sum of all bits is either odd or even, as specified), data bits (a byte can contain
5, 6, 7 or 8 bits, usually 7 for text data or 8 for binary data), and stop bits (follows the data
bits to mark the end of each byte, value either 1 or 2).
Naturally it is important that the line parameters are set the same for equipment either end of
the line if error free communication is to take place. Mr.UART and his associate at the other
end of the link will calculate the value of the parity bit (if parity is used) for you and tell you
if the two values don’t match, which probably means you have corrupt data. UART and FIFO
work alongside a char lady named Flo(w) Control. Flo natters away with her counterpart in
the other device to ensure that data is not sent along too quickly for UART and FIFO to
handle. If there is a traffic jam brewing, she tells her friend to stop transmitting for a while (I
think the technical phrase she uses is “put a sock in it”) until the backlog is cleared. Flo is
quite happy to work in either hardware or software mode, providing you pay her full union
rates.
Lets take a look at how we get data from the com ports on the PC into our program. These
days, it is probably safe to say that the majority of Windows based programs for industry are
written using the popular visual development environments such as Visual C++, Delphi,
Visual Basic, JBuilder etc.. Many of these development tools are object based, using
components which encapsulate the properties, procedures and functions of a particular
activity (a button, field or form for example). Given this paradigm, it would make sense to
have a ‘com’ component that can handle the interface between your application and the
RS232 ports on your computer. Fortunately, there are many third party component developers
out there who have provided just such a component for use with your chosen development
tool. These are often referred to as com ‘libraries’ and usually offer other functions as well.
Popular examples are Greenleaf and the excellent Async Pro from Turbopower. Of course,
you could write all the low level code yourself if you particularly wanted to, but there would
seem little point given the ready availability of commercial coms libraries.
Having chosen your development tools, we now need to get data to and from the software
application in question. Lets look at incoming data first. How do you know when your PC has
received a data stream at the com port? Obviously we shall have to constantly monitor the
com port for any sign of activity. Our com component can help us here by providing a
‘trigger’ every time it detects something happening at the com port (remember the discussion
about
UART and FIFO?). We shall then have to tell our software application exactly what to do
each time it sees this trigger. For example, we might be expecting a particular data stream
with required information at different positions within the stream. A transaction stream from
a biometric device or network master might have a start character, reader address, user
number, result flag, tamper flag, other condition flag and so on, all at predefined positions
within the main stream. If we wish to grab the user number and transaction result from this
stream, we must first know exactly where they are. Within a standard ASCII character
stream, we would usually do this by counting the characters from the first received character
and then parsing (dividing up) the stream into the required sections. Our application can then
take this information and act upon it according to our previously written instructions. This
will usually
include displaying a message on screen to advise the operator of the transaction and writing
the details of the transaction into a database for subsequent analysis. We shall also have
occasion to send information back out of the PC to our network of readers. For example, we
may be remotely adjusting a parameter on a reader or perhaps placing a reader into enrol
mode, or querying its internal database. In a similar fashion, we shall send a data stream out
of our com port and down the line to our reader network. This stream will probably have start
and stop characters, a reader address and a set of characters or ‘flags’ to execute our required
command. It may also be encrypted in some way in the interests of data security and include
some sort of error checking methodology with respect to data integrity.
But how do we know that our little family of readers are still alive and well and living on the
network? This is usually achieved by polling the network at regular intervals in order to
check that all is well. In effect, our application is saying “reader number 9, are you still there
and are you still operating correctly? - oh, and by the way is anything happening transaction
wise?” Reader number 9 answers back “Yes, I am still here, but nothing is happening at the
moment - when it does I will let you know”. This conversation may take place several times
each second, between the host (your PC) and every reader on the network.