http://www.techradar.com/pro/linux May 2019LXF249 59
Debug serial comms TuTorialS
Putty’s screen layout
isn’t necessarily the
samein different OSes.theLostart
Before starting the terminal session configured in
Putty, let’s create a physical connection (technically, a
short) between pins 2 and 3 on the nine-pin serial
connector. Refer to the DB9 connector details on the
diagram: pins 2 and 3 are the serial transmit/receive
pins. By connecting the pins together, we are
redirecting the output on the transmit pin back to
the input on the receive pin.
When the Putty session is activated you will be taken
to a blank, black terminal-style window. Now select a
character on the keyboard. The keyboard character
selected should appear on the screen. If the character
appears, Putty has transmitted the character data
serially out of the transmit pin and, with the short in
place, routed the transmission back to the receive pin,
to be displayed on the screen.
The real thing
Now that we have confirmed Putty can transmit and
receive over the USB-to-serial cable/interface, we can
replace it with our unknown serial application. The
application will no doubt require the configuration
details (COM port) used to setup the Putty session.
If the cable/adapter worked with Putty it should work
with the application, provided the communication
details set up are correct. If not, you have isolated
the problem to the application.
The serial application will need to be configured with
the serial communication protocol details. The COM
port identifier is one piece of information. It is important
in serial communication that the transmission rate and
the framing of the serial message be compatible
between sender and receiver. For Putty, we relied on
the default serial options, 8N1.
Serial communication relies on both the transmitting
end and receiving ends agreeing on how they will frame
data for communication. Here is an analogy: two people
want to communicate. One speaks French, the other
English. Without establishing a language requirement,
both parties can transmit, but neither can understand
what is received. The same concept applies to serial
communication setup.
The serial device manufacturer’s documentation
should provide the details required to set up the
application. The Putty serial screen is an example of
the values that should be found in the serial device
documentation. The application needs to know the
speed and bit configuration in order to communicate.
You discovered the COM port by looking in the OS. It
can take a lot of trial and error to work through the
combination to get the serial protocol correct.
Remember that pins 2 and 3 on the serial connector
are ‘transmit’ and ‘receive’. When the cable is plugged
into the serial device, how does the serial device’s
manufacturer take care of ensuring the transmit data
pin is connected to the serial device’s receive data pin?
It would be handy if this requirement is provided in the
documentation; if not, it’s back to our troubleshooting.
There are two methods to achieve the connection
goal. The serial device’s manufacturer may cross the
transmit and receive pins on the serial device end by
switching the position of pins 2 and 3 on the connector,
or assume that the user has
sufficient knowledge to use the
option of installing a null modem.
If the two pins are switched in the
serial device, transmit and receive
pairing will match. Otherwise, a null
modem cable will need to be
installed to take care of moving the
transmit and receive connections.
Refer to the diagram for null modem
cable details.
Let’s summarise the
troubleshooting process we’ve just
developed, to really get it into our
minds. First we confirmed the USB-
to-serial cable/adapter was
supported in the host PC by
checking that it was registered in
Linux. Next we confirmed that the
computer could transmit and
receive over the USB-to-serial
cable/adapter using Putty. We
shorted pins 2 and 3 on the cable/
adapter’s connector, so that the
‘transmit’ and ‘receive’ were
connected, then transmitted a character and watched it
appear on the screen.
Putty was then replaced with the computer
application we want to actually test, and the application
was configured with the required serial port and
communication protocol requirements (rate and
framing details) given by the manufacturer.
Finally, the PC was connected with the USB-to-serial
cable/interface to the serial device, with the knowledge
that transmit and receive was taken care of by the
manufacturer’s design, or a null modem cable needed
to be installed to complete the communication path.
When you experience serial communication
problems, what’s most important is to determine if the
infrastructure for serial communication actually works,
without all the overhead of the new applications and
devices. Once that is determined you can substitute the
known for the unknown, and should be able to isolate
what is not working.You would think that the knowledge that a straight-through
connection, or a null modem connection, is required for a bit of kit to
work would be provided in the documentation. It’s my experience
that this knowledge, more often that not, is lacking, however.
With the demise of COM ports as computer hardware, a lot of
knowledge about serial communications has been misplaced. The
belief now seems to be “Just hook it up and it’ll work!” We need to
restore the lost knowledge to troubleshoot connection issues.
One caveat to keep in mind is not to apply both connection
methods at the same time. If the manufacture has switched the pins
and a null modem cable is installed, two rights in this case make a
wrong. Think about it: pins 2 and 3 are switched by the manufacture,
and then again by the null modem cable.get yourFiLLoF seriaL Subscribe now at http://bit.ly/LinuxFormat
youcanfind
simontatham’s
puttyrepository
atwww.chiark.
greenend.org.
uk/~sgtatham/
putty.