So the question for all you out there thinking about using the Raspberry Pi to connect to an RS-232 peripheral is this: if you could have a tidy single-board serial port that would plug onto the GPIO of the Raspberry Pi, would you want it to plug directly onto the GPIO pins or would you want it led off the Raspberry Pi’s board with a ribbon cable? Reply to this post to let me know!

Cabling can be like spaghetti

When two pieces of Data Terminal Equipment (terminals, or DTEs) need to be connected to each other, or two pieces of Data Circuit-terminating Equipment (modems, or DCEs) need to be connected to each other, a serial crossover or null modem cable is used. These cables align incoming signals with the corresponding outgoing signals on the other side of the connection. At a minimum, the Transmit Data (TD) line of a serial link needs to be paired with the corresponding Receive Data (RD) line on the other device.

Why would one need such a cable?

1. It can be a way of connecting two PCs without networking interfaces such as Ethernet, making direct file transfers between systems possible.
2. It can be a method for technically-minded users to debug systems with minimal software overhead (that is, as little code and as few drivers as possible).
3. It can provide access to a serial console when problems make the local monitor and keyboard of a computer unavailable, or when a computer is being remotely operated or operated “headless” (that is, without a monitor, keyboard and mouse).

Not all null modem cables are the same however, and some cables will not work in specific applications. The three standard types of null modem cables are described here, for DB-9 to DB-9 and DB-25 to DB-25 connections, making six variations. I haven’t shown the three DB-9 to DB-25 versions, which in any case are just the DB-9 side at one end and the DB-25 side at the other (see below, “9-Pin to 25-Pin Connection”). The bottom line is: there are nine variants of RS-232 crossover cables.

The first, “No Handshaking,” swaps the complementary data transmit and receive lines. This is the minimum needed for a crossover connection. This cable will work as a crossover cable when control lines are not needed for the link. It cannot be used when hardware handshaking is required. It can be used when hardware flow control has been turned off on the serial ports involved, but doing so will simply bypass the control lines regardless of their state.

Crossover cable with no handshaking (click to enlarge)

The second, “Full Handshaking,” swaps the data lines as well as the control lines needed for handshaking/flow control. The pairs of lines needed for handshaking are DTR/DSR and RTS/CTS This cable crosses these pairs between the two ends of the cable. This cable will work as a crossover cable when control lines are not needed for the link, or when hardware handshaking is required. It can be used when hardware flow control has been turned off on the serial ports involved, but doing so will simply bypass the control lines regardless of their state.

Crossover cable with full handshaking (click to enlarge)

The third, “Loopback Handshaking,” swaps the data transmit and receive lines, but the DTR/DSR and RTS/CTS pairs are not swapped with their complements.  Instead, the DTR line on one side of the link is looped back to the DSR line on the same side of the link, and the RTS line on one side of the link is looped back to the CTS on the same side of the link. This cable will work as a crossover cable when control lines are not needed for the link. It can be used regardless of the on/off state of hardware flow control on the serial ports involved, but will “fool” the link into accepting that hardware handshaking has been completed. It cannot be used when true hardware handshaking is required.

Crossover cable with loopback handshaking (click to enlarge)

If one side of a serial crossover cable uses a 9-pin connector and the other side uses a 25-pin connector, the lines map between these two connectors as follows:

9 pin to 25 pin connection (click to enlarge)

Aside: Payment Processing Terminals and Serial Crossover (Null Modem) Cables

LAVA’s experience connecting modem-based payment terminals with serial device servers is relevant to this discussion of crossover cables. This scenario uses a null modem cable between the serial device server and the payment terminal. While some payment terminals require only RX and TX lines, LAVA recommends using a “Full Handshaking” cable with the line signaling unless you are certain that control signals are not used. LAVA does NOT recommend a cable that uses “Loopback Handshaking”. Care should be taken when purchasing null modem cables as not all packages indicate clearly what type of null modem cable is being sold.

Controlink DNC software and LAVA serial card

Controlink Systems software meshes nicely with LAVA’s serial interfaces, whether PCI, PCIe, or Ethernet-to-Serial device servers.

Tiba Restaurant Equipment products

Tiba’s metal cutting designs are created on a computer that has patterns and templates,  and specialized software for ductwork design. When Tiba is ready to cut material, these designs are sent to Tiba’s Cybermation plasma cutting table, where much of their metal cutting is carried out. The connection between computer and cutting table is RS-232 serial, handled by a LAVA SSerial-PCI card.

Cybermation plasma cutter

Their metal cutting capability is critical to Tiba’s business, and the reliability that comes with a LAVA card is key to their success.

LAVA PoE Ether-Serial Links

For these PoE Ether-Serial Links to operate, they will need to be attached to a network supplying power over Ethernet, and that’s about it. That power is added to the Ethernet by either a “PoE  endspan” or a “PoE midspan” — switches or other devices designed to inject the appropriate power into the network cabling. The cabling used is standard network cabling (assuming it has the usual complement of wires),  and no additional software is required to make a working PoE system.

These PoE serial device servers also come with a connector that can be used to supply conventional power through an AC to DC wall adapter, supplied separately.

PoE ESL Ethernet end cap

Details on Power over Ethernet endspans, midspans, cabling, signal, and standards can be found here.

A PDF specification sheet for the PoE ESLs can be found here.

All LAVA PCIe serial ports are engineered to provide a near-full voltage signalling range on their serial port pins. Specifically, LAVA serial ports comply fully to serial port requirements by generating a voltage range of at least +12V to -12V.

This is important when your serial data rate is high, your cable runs are long, or there is a greater than ideal amount of electrical “noise” in the area. It also matters when the serial peripheral attached makes a draw on the serial port. In those situations the added voltage differential can make the difference between a connection that works and one that doesn’t — just as with a car, you need a little more horsepower when you start to pull a trailer.

PCI and PCIe serial port add-in cards draw their power from the bus on which they are attached. In the case of PCI, there is enough voltage range on the bus to allow a serial port adapter card to operate within the specified voltage range; in the case of PCIe, there is not.

Induction coil

You can see, on all LAVA PCIe boards with serial ports, the little copper induction coil that contributes to this capability. Check out other companies’ products on the web and you’ll see that they have cut corners here: they are in many cases not generating the -12V signal — is the risk to the reliability of your connection really worth it?

Taking the Raspberry Pi as an example, we have a device that has a UART, but note: having a UART is not the same as having an RS-232 COM port, for several reasons. First, the RS-232 COM port has a reasonably well-defined connector; second, the RS-232 COM port offers specific control lines beyond TX, RX, and GND that may or may not be implemented in a given UART’s design; and third, an RS-232 COM port operates at signal specific voltages that are not necessarily the signal voltages of a given UART.

So, although the Raspberry Pi has lines that are documented as TxD, RxD, and GND, these are not actually RS-232 serial lines until, at the very least, they have been made to match the voltages RS-232 defines.

And what are those voltages? RS-232′s data signalling voltages, consisting of a sequence of logical “ones” and “zeros”, are the voltages that correspond to those logical values. The region from +3 volts to +15 volts is defined as a logical “zero”, and the region -3 volts to -15 volts is defined as a logical “one”. The middle region between these two regions is essentially a no man’s land, as far as RS-232 is concerned. For the RS-232 control lines (DTR, DCD, DSR, RI, RTS, CTS) these designations are reversed: a logical “zero” is in the negative range and a logical “1″ is in the positive.

RS-232 voltages

But since the circuitry of the Raspberry Pi (as well as that of many other electronic devices) is actually operating in the range of 0 to +3 volts, circuitry to translate those logical values to the signalling voltages of RS-232 is needed. A word of advice here to tinkerers who think they can simply connect the TxD of their computer’s RS-232 port to the RxD line of their Raspberry Pi (or similar device) and vice versa: DON’T. You will quite possibly cook the device’s internal electronics.

The converse is also true: the voltages output from some electronics (even those sometimes called “RS-232″) are not automatically enough to do the job, depending on cabling runs, the data rates, and the specifics of the serial peripheral involved.

That’s where LAVA pays particular attention in its RS-232 designs: they take care to supply the full voltage required by all RS-232 peripherals; not all competitors do the same.

Finally, while are are talking about voltages, there is the ground line in RS-232. Along with the transmit and receive lines it’s by definition always there, and when speaking of plus or minus amounts of voltages as we have been doing, we are implicitly referring to some standard. In the case of RS-232, this standard is the ground line, which is assumed to be 0 volts. That’s great, but the 0 voltage of the ground line is expected to be the same zero at both ends of a serial connection. For that reason, RS-232 connections share a common ground (unlike the differential signalling of RS-422 or RS-485, to mention a couple of other serial standards). There is good news and bad news in using a common ground as the reference. The good news: only three lines are required for RS-232 transmission. On the down side: RS-232 has a relatively short reliable cable length compared to methods requiring at least four lines, like RS-422 and RS-485, or USB 3.0 for that matter. More on those technologies can be found here (RS-422 and RS-485) and here (USB 3.0).

DSerial-PCIe/LP FHB

The features of this new card include:

• Form factor: 1x. Will fit into any PCIe slot.
• Form factor: Full-height PCIe card.
• Bracket: Full height [FH]
• Cable: Two port RS-232 DB-9 fan-out
• Driver support: Standard
• Serial support: RS-232, 115.2 kbps, 16550 UART
• LAVA Lifetime Warranty

You can read the details in our press release.

Of course, for those intending to use the Raspberry Pi as an embedded SBC more serial ports might be desirable. In that case, they could be added using the USB connector and and USB-to-serial adapter.

However, the Raspberry Pi has serial ports of its own. The first serial port, the “Mini UART,” was discussed in the last Raspberry Pi blog post, and it can basically be seen as a console port for access to the Raspberry Pi.

The second serial port is a more fully-implemented version of the 16C550/16C650, with more hardware lines available and with greater configurability for buffers and flow control. It is a version of the ARM PrimeCell PL011 UART. The details of the two ports are shown in the following table:

Raspberry Pi serial ports compared

The PL011 UART varies from the industry-standard 16C650 UART device as follows:

•   Receive FIFO trigger levels are 1/8, 1/4, 1/2, 3/4, and 7/8
•  Transmit FIFO trigger levels are 1/8, 1/4, 1/2, 3/4, and 7/8
•  The internal register map address space, and the bit function of each register differ
• The deltas of the modem status signals are not available.

The following 16C650 UART features are not supported:
•  1.5 stop bits (1 or 2 stop bits only are supported)
•   Independent receive clock.

The following functionality of the ARM PrimeCell UART (PL011) is not supported in the Raspberry Pi implementation:
•  Infrared Data Association (IrDA)
•  Serial InfraRed (SIR) protocol Encoder/Decoder (ENDEC)
• Direct Memory Access (DMA).

In most applications these differences will not matter, as the largest part of serial peripherals do not use all the signalling implemented on full-blown serial ports.

GPIO voltages

Hooking up a serial port on the Raspberry Pi’s GPIO has one complication that needs to be borne in mind: the voltages on the GPIO pins are not in the range of those required for conventional RS-232, RS-422, or RS-485. Specifically, the GPIO pins supply “logic level” signalling, at about 0v to 3.3v.

Since RS-232 looks for levels of -5v to -15v for a logical “1,” and +5v to +15v for a logical “0,” the outputs from the Raspberry Pi would also need a level shifter circuitry (like the MAX232 chip) to generate the appropriate voltages.

If you wish to generate RS-422 or RS-485 signalling, then a line driver like the SP3485 is required.

GPIO pin assignments

The serial I/O on the Raspberry Pi pin header is as follows:

Raspberry Pi GPIO serial pin assignments

 Sources:

CM2835 ARM Peripherals specification sheet (Broadcom BCM 2835 specification sheet: the core of the Raspberry Pi)
PrimeCell® UART (PL011) Revision: r1p4 Technical Reference Manual (PrimeCell UART (PL011): the UART in the Broadcom BCM 2935)
http://www.raspberrypi.org/forum/general-discussion/gpio-pinouts-confirmed/page-3 Raspberry Pi forum discussion on serial implementation for the Raspberry Pi)

Raspberry Pi production build schematics (NOTE: GPIO pin assignments have varied in the pre-release history of the Raspberry PI. Please confirm current pinouts before implementing serial I/O on the Raspberry Pi.)

A USB-to-TTL solution to level shifting on the Raspberry Pi

An interesting description of software (Debian Linux) access to use the mini-UART serial port in non-console mode

A beginner’s level discussion of serial interfacing on the Raspberry Pi

Farnell has a Quickstart Guide that discusses serial connection to the Raspberry Pi (NOTE: Take care when connecting that you are not sending a higher voltage into the Raspberry Pi than it can handle; this Quickstart Guide is not explicit on this point)

LAVA Ether-Serial Links can play a role in either eliminating the need for a computer near the weather station, or can make it possible to eliminate phone line/modem connectivity, or costly cellular modems.

The usual arrangement is having the weather station connect to a computer, either directly on serial, USB, Ethernet, or through a modem. An Ether-Serial Link (or other serial device server) can cost-effectively streamline the process, eliminating the modem/phone line connection, or even eliminating the computer itself.

Weather station setup w ESL

LAVA has written an application note that takes the users of Davis Instruments weather stations through the steps of getting those devices on the Internet; the overall concepts apply to other manufacturers’ weather stations as well.

Once online, your weather station can contribute to the many individually operated weather stations feeding data in to systems like the Weather Underground.