Glen Turner (vk5tu) wrote,

RS-232 over a RJ-45 connector

Cisco 2500-series RJ45

There used to be a variety of specifications for presenting a RS-232 signal on a RJ-45 socket. There is one predominant survivor: the pinout of the Aux socket of the cisco Systems 2500-series routers (from back when Cisco had no leading capital letter, being short for San Francisco).

The pinout of the socket is:

Pin

Name

Description (direction)

1

CTS

Clear to send (output)

2

DTR

Data terminal ready (output)

3

TxD

Transmit data (output)

4

Gnd

Signal ground

5

Gnd

Signal ground

6

RxD

Receive data (input)

7

DSR

Data set ready (input)

8

RTS

Request to send (input)

RTS and TxD are not valid until DTR is asserted: the device might be off and they may be floating. RTS indicates that there is enough buffer to receive more data. TxD is used to transmit data. Data is not sent until CTS is asserted. RxD and CTS are not valid until DSR is asserted.

The cabling is straightforward:

1 CTS ---- RTS 8
2 DTR ---- DSR 7
3 TxD ---- RxD 6
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 4
6 RxD ---- TxD 3
7 DSR ---- DTR 2
8 RTS ---- CTS 1

You can see that the presentation of signals to pins has been carefully thought out. By flipping over the RJ-45 plug at one end when crimping the RJ-45 patch lead we can connect one Aux interface to another Aux interface. Cisco call this transposition a "rolled" UTP cable.

This trick has one downside. You'll recall that a 568B UTP cable twists the wires 1,2; 3,6; 4,5; 7,8 and a 568A UTP cable twists the wires 1,2; 3,6; 4,5; 7,8. That is, the TxD and RxD signals are not carried on the same pair as the Gnd. That is going to affect performance. I think that is acceptable: if you want performance on unshielded twisted pair then that is why RS-422 exists.

The 2500-series of devices used a speed of 9600 bits per second. Each ASCII character used 1 start bit-time, 8 data bits, no parity bit, and 2 stop bit-times. Later devices used only 1 stop bit-times for greater compatibility with common settings.

The command line of early devices would clear the top bit of received ASCII characters, allowing 7 data bits and either odd or even parity to be understood by the command processor (the screen would show gibberish, but from a 7E1 terminal you could blindly type the commands to set 7E1 for the terminal setting and the display would then work. Although a useful hack at the time, today it means that international characters are best avoided when using the Cisco IOS command line.

Console ports do not do handshaking. They connect CTS to RTS. They pull up DTR to asserted as long as the chassis is powered. They ignore DSR.

IBM PC/AT DB-9

There is of course another popular presentation of RS-232 signals: the D-9 plug of a IBM PC/AT. The usual RS-232 connector is a D-25 socket, unfortunately the IBM PC used that for the Centronics parallel connector for a printer (the usual Centronics connector was too side for the IBM PC interface slots). So the IBM PC used a D-25 plug for the RS-232 connector to avoid cabling errors. The IBM PC/AT updated that to use a D-9 plug, allowing the serial and parallel interfaces to be presented using one slot (the "Super I/O" cards).

The pinout of the IBM PC/AT D-9 connector is:

Pin

Name

Description (direction)

1

DCD

Data carrier detect (input)

2

RxD

Receive data (input)

3

TxD

Transmit data (output)

4

DTR

Data terminal ready (output)

5

Gnd

Signal ground

6

DSR

Data set ready (input)

7

RTS

Request to send (output)

8

CTS

Clear to send (input)

9

RI

Ring indicator (input)

IBM PC to Cisco console

So how do we interface these two? There are obviously two choices: allowing for a standard patch lead and allowing for a rolled patch lead. Cisco chose to allow for a rolled patch lead. Thus a RB-9/RJ-45 backshell, a rolled cable, and another RB-9/RJ-45 backshell could be used to interconnect two IBM PC/AT.

1 CTS ---- CTS 8 ---- RTS 7
2 DTR ---- DSR 7 ---- DSR 4
3 TxD ---- RxD 6 ---- RxD 3
4 Gnd ---- Gnd 5 ---- Gnd 5
5 Gnd ---- Gnd 4 ---- Gnd 5
6 RxD ---- TxD 3 ---- TxD 2
7 DSR ---- DTR 2 ---- DTR 6
8 RTS ---- RTS 1 ---- CTS 8
                 nc-- DCD 1
                 nc-- RI  9

You can see that for this cable to work the application has to be configured to ignore Data Carrier Detect. If you make your own RJ45/DB9 backshells then you may wish to crimp DCD(1) and DSR(4) on the DB9 connector to DSR(7) on the RJ45 connector.

Avoiding the rolled cable

The rolled cable is key to a flexible system for interconnecting RS-232 devices. However the importance of RS-232 has faded. About the only thing it is used for these days is for the console of networking and embedded devices. Flexibility for other applications doesn't have the attraction it once did.

For connecting a computer to a console the rolled cable is painful: using a standard patch lead would be far superior. If you needed a longer cable you could simply use one from the stock of standard UTP cables.

This is the approach taken by Juniper Networks. They provide a backshell and a standard UTP cable. The pinout of the backshell is:

1 CTS ---- RTS 7
2 DTR ---- DSR 4
3 TxD ---- RxD 3
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 5
6 RxD ---- TxD 2
7 DSR ---- DTR 6
8 RTS ---- CTS 8
      nc-- DCD 1
      nc-- RI  9

Again, if I was constructing this myself I would pull up DCD if the far end is available. That would allow lines to clear down properly if the far end powers down.

1 CTS ---- RTS 7
2 DTR --+- DSR 4
        +- DCD 1
3 TxD ---- RxD 3
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 5
6 RxD ---- TxD 2
7 DSR ---- DTR 6
8 RTS ---- CTS 8
      nc-- RI  9

The USB console

Computers no longer come with RS-232 ports. Network engineers carry a RS-232/USB dongle. So why not provide a USB B connector which carries a Data Class Interface USB profile. Cisco Systems use a Mini B connector. This will appear as a /dev/ttyUSB… if connected to a Linux system.

I have yet to try it, but there shouldn't be anything preventing plugging a whole switch stack of USB consoles into a single USB hub. A small embedded computer like a Raspberry Pi can then used as a basic console server.

RS-232 will be with us in the embedded space for a long time. It is very easy to initialise a RS-232 UART and so it is an ideal way to output messages from very early in the boot process. For this application there is little justification for the high voltage levels of RS-232 and many boards present 5V or 3.3V levels (that is, they have the UART but not the MAX232 chip). Those signals can be run directly into the RS-232 inputs of a Prolific or similar RS-232/USB UART (again, lacking a MAX232 ship).

Tags: gear
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments