The information retrieved between two devices is always encoded in bytes. RS-232 makes use of different conventions for transmission

By default the settings for reading and writing from a serial communication link are to use data packages with 8 bits, no parity and 1 stop bit, as well as no handshake control

Nowadays serial devices come with a default speed of 19200 bps, in the past the standard was 9600 bps. Bps stands for "bits per second", therefore 19200 bps are 2400 bytes per second

(in the picture, yet another experiment in wireless transmission)

 

 

Imagine you want to transmit information between your wiring board and another device, let's say a computer, another board, a small external screen, etc. You could try to do this sending all the information encoded in bits, since it is possible to encode everything in a sequence of bits. Can you imagine the complexity that such a program would have?

Therefore, standards for communication have been developed in an attempt of simplifying how data is transferred from one device to the next. Here we focus in how to transmit information between two devices, a case of one-to-one communication. For such a situation, a very suitable standard is the serial port communication, very extended in the form of the so-called RS-232 standard. What the convention establishes is a way for grouping the information in bytes (groups of seven or eight bits) and send it over a connection of some kind to the next device. There exist many other standards depending on issues like wired vs. wireless, one-to-one vs. one-to-many vs. many-to-many, short vs. long distance, etc. Anyway the two most relevant for us are RS-232, and RS-485. The later will not be explained in here, but it may be relevant to look at it at some point

Before we enter to discuss about the way the RS-232 works, it may be convenient to introduce a couple of definitions that will surely show up in different documents you may use to add more information to the one you could find here. The first thing to consider is the communication modes: simplex, duplex, and full-duplex

Simplex Communication

We talk about simplex communication when we establish a uni-directional link between two devices. A very easy example of this is a lamp. We can send the command to turn it on or off, but the lamp cannot answer over the same communication line we use to send the order. There is only one way the information flows, and therefore we call it simplex (word that resembles the English term "simple"). Another case of this type of transmission is when information is broadcasted: contemporary TV and radio are using simplex as a transmission method

For us a typical example of simplex communication would be if we wanted to send information to a display. In this case we don't need to get anything back. We just send data for the display to show, but there is no feedback. Then it is not needed to create a complex information transfer between our device and the display, just a simplex channel is more than enough

Duplex Communication

This term stands for communication channels that can handle bidirectional transmission, but not at the same time. Again if we think about how we have conversations in-between people, this is an example of duplex communication. During a civilized talk, we take turns and let the others finish their part before we start our argumentation. We could of course talk all at once, but that would reduce the quality of the transmission

We will not find this case in our work with the i/o board, even if we could. But it should maybe be mentioned that there are typical examples of duplex information exchanges in contemporary communication systems. Just think about IP-telephony, messenger voice communication, etc. There you can send information in both directions, but just once at the time. The funny example is of course the tin can phone

Full-duplex Communication

This is the kind of communication we will choose if we are willing to be able of sending as well as receiving information simultaneously. It is characteristic of systems that have more than one channel to transmit the information. Using the example of the tin can phone, a duplex system would be one where two systems are used, one for listening and one for sending

RS-232

Taken from CamiResearch.com:

“In the early 1960s, a standards committee, today known as the Electronic Industries Association, developed a common interface standard for data communications equipment. At that time, data communications was thought to mean digital data exchange between a centrally located mainframe computer and a remote computer terminal, or possibly between two terminals without a computer involved. These devices were linked by telephone voice lines, and consequently required a modem at each end for signal translation. While simple in concept, the many opportunities for data error that occur when transmitting data through an analog channel require a relatively complex design. It was thought that a standard was needed first to ensure reliable communication, and second to enable the interconnection of equipment produced by different manufacturers, thereby fostering the benefits of mass production and competition. From these ideas, the RS232 standard was born. It specified signal voltages, signal timing, signal function, a protocol for information exchange, and mechanical connectors.”

What interests us is the fact that we can make use of basically two cables for establishing a full-duplex communication between two devices, and just one wire for a simplex one. The information will be encoded in the form of PWM pulses that are very robust to long distances. This allows having RS-232 connections of about 100 meters between devices, what can be very useful for e.g. hiding the computer controlling a certain prototype at a different room.

Figure 1 : a tin can phone, picture taken from laundrylist.org

Here we have to introduce a new concept again: the Uart that stands for universal asynchronous receiver/transmitter, in the wiring board is an internal peripheral that takes care of encoding the information for sending it over an RS-232 connection, and decoding it once at the other side. The microprocessor on the wiring board includes two serial peripherals on-chip, but so far we can only make use of one; future releases of the software should allow the use of the second port.