|
[20150717]
|
Making my RPI serial console work, or: fixing a hardware problem in software
Some time ago I get a Raspberry Pi, but never really got it working:
I don't have a HDMI display, and wanted to use the serial console.
Unfortunately the "official" RPI-serial-to-USB cable had an annoying
effect for me: while I saw output just fine, I wasn't able to type
anything! Funny enough, this was not only in NetBSD but also Debian.
Which took the blame from NetBSD :)
Picture 1 shows the cabling.
So the blame was on the RPI-USB-to-serial cable, and I looked into making
my own. I have a standard USB-to-serial adapter, but that one cannot
be connected pin-by-pin to the RPI, as they use different voltage
levels. While the "standard" serial UART protocol (RS-323) encodes 0s and 1s as
5V and -5V, the RPI uses TTL voltage between 0 and 3.3V - a simple 1:1
connection sounds like a bad idea. Converters like the MAX3232 are
available: it connects the TX and RX lines and adjusts the voltage
levels. To operate, power and ground are provided by the RPI. After
frobbing this together (see picture 2)
I found out that - surprise - the problem was not in the cable either,
as my home-made cable also did not work for input, only for output.
After some detour (frobbing the image-build process to make me an
image that not only has working DHCP and SSH, but that actually let's
me log in), I got the crucial hint what was going on:
Having lines for sending and receiving data is nice, but what if one
end's receiver is full and wants to signal that? This is called "flow
control", and apparently with no lines for that, hardware
flow control is not an option. In theory there is a software
solution (sending XON/XOFF bytes), which requires equal settings on
both sides. Apparently the RPI doesn't do that either, and with the
default settings on my NetBSD host to wait for an XON before sending
data, things didn't match up - no XON from the RPI, no data going to
it. Plain and simple - if you know what's going on.
The fix was easy, and thanks go to
Jean-Baka
Domelevo Entfellner for the hint: disable flow control in my
terminal program (kermit). So with a simple "set flow none", things
work like a charm now. Voila, another hardware problem fixed in
software! :)
How to look at serial interface parameters from NetBSD? Use the
stty(1)
command. Here's the default output for my USB-to-serial interface
attached to ttyU0:
# stty -f /dev/ttyU0
ispeed 0 baud; ospeed 9600 baud;
lflags: echoe echoke echoctl
oflags: onocr onlret
cflags: cs8 -parenb
The difference is obvious when running the same command while kermit
runs with proper settings in a different window:
# stty -f /dev/ttyU0
speed 115200 baud;
lflags: -icanon -isig -iexten -echo echoe echoke echoctl
iflags: -icrnl -ixon -ixany ignbrk ignpar
oflags: -opost onocr onlret
cflags: cs8 -parenb clocal
Not only is the speed different, but most important "-ixon" tells the
interface to not wait for an XON on input (iflags) before transmitting
data.
For reference sake, here is my .kermitrc that I use:
# cat .kermrc
# Raspberry PI
set carrier-watch off
set line /dev/ttyU0
set flow none # disable hardware flow control
set speed 115200
#set speed 9600
#connect
Picture 1: The standard RPI-USB-to-serial cable (click to enlarge)
Picture 2: My own USB-to-serial adapter using a MAX3232 chip (click to enlarge)
[Tags: hardware, hubertf, max3232, raspberrypi, rs323, serial, stty, tty, ucom, usb]
|
