hubertf's NetBSD Blog
Send interesting links to hubert at feyrer dot de!
 
[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: , , , , , , , , , ]


Disclaimer: All opinion expressed here is purely my own. No responsibility is taken for anything.

Access count: 34936278
Copyright (c) Hubert Feyrer