Raspberry Pi Dumb Terminal
Intro: Raspberry Pi Dumb Terminal
Back in my day the internet was a dumb terminal connected at 300 baud through an acoustic coupler to a timeshare system, and we liked it!
Ok I'm not actually that old, but how amazing it must have been to be using telephones to connect up to the ARPANET before it was legal to even connect a modem directly to your phone line (yeah for real, direct modems were illegal)!
This time period was so magical! The computer industry and telecommunications industry were colliding like two galaxies, and no one had any idea how it would all pan out. I may not be old enough to have lived through it, but the tech that fueled this paradigm shift to a new age is still around, collecting dust in surplus stores and buried in boxes in our grandfather's basements.
I recently acquired an early 300 baud acoustic coupler (how modems worked before you were allowed to connect modems directly to a phone jack). Let's dust it off and build our own dumb terminal using an old phone, the coupler, a Raspberry Pi, some wires, a few capacitors, a serial transceiver chip, and some solder!
Get off my lawn with your newfangled 4G. Where did I leave my teeth? Here we go!
STEP 1: The Circuit
Modern devices like a Raspberry Pi generally use a 3.3v TTL UART for hardware serial communications. Vintage equipment (like the beautiful 300 baud acoustic coupler we are going to interface to) use +/-15v RS-232 for their hardware serial communications.
To get around this, we are going to use a special integrated circuit called a transceiver. This device only has one job, to translate back and forth between TTL and RS-232. The part I chose for the circuit is SP2322E a 'true +3.0v to +5.5v RS-232 Transceiver'. This part gets its power from the Raspberry Pi. The Raspberry Pi, however, does not have the ability to source +/-15v. Where do these voltages come from? The transceiver chip uses a set of external capacitors as part of its charge pump circuits. In other words, with a little help from its capacitive friends, the transceiver is capable of generating its own +/-15 rails. Fancy!
While this part is capable of two serial channels, we only require one for this job. Connected to the Raspberry Pi's GPIO UART are transceiver pins T1IN and R1OUT. Connected to the RS-232 cable are transceiver pins T1OUT, R1IN, and GPIO GND (need that ground reference, buddy).
So there we have it, a simple circuit that will allow our new-fangled Raspberry Pi to talk to 40 year old telecommunications equipment.
Let's build it!
STEP 2: Soldering
Instructables sent us a Perma-Proto Pi Hat board along with a Raspberry Pi 2 as part of the Raspberry Pi 2 Build Night earlier this year. I'm going to use this to make building my circuit onto the Raspberry Pi quick and easy.
I started by soldering a 16 pin dip socket onto the hat. Then I angled the pins on the IC properly and inserted it into the socket.
I soldered a blue jumper wire between the transceiver T1IN pin and Raspberry Pi GPIO TXD pin. Then a yellow jumper between the transceiver R1OUT pin and the Raspberry Pi GPIO RXD pin.
I scrounged around my junk boxes for a standard DB9 serial port. I soldered a green wire to pin 5, a blue wire to pin 3 and a yellow wire to pin 2. I soldered the green wire to the GND rail on the hat. I soldered the blue wire to the transceiver T1OUT pin. I soldered the yellow wire to the transceiver R1IN pin.
I soldered all of the capacitors in place.
I soldered a black jumper wire between the transceiver GND pin and the GND rail on the hat.
I soldered a red jumper wire between the transceiver VCC pin and the +3.3v rail on the hat.
I soldered the included female 2x20 header onto the hat, facing down.
Our transceiver hat is now complete, let's hook it up!
STEP 3: Connections
The antique Novation 300 baud acoustic coupler modem relies on a DB25 RS-232 cable for serial communications. So I connect a DB9 to DB25 adapter cable between the transceiver hat and the coupler.
I place a type G telephone handset into the acoustic coupler's cups.
The rest is monitor, keyboard, power, etc.
Let's get it working!
STEP 4: Configuration
Out of the box, a Raspbian installation assigns a process to handle everything that happens on the Raspberry Pi's GPIO UART serial port (ttyAMA0). This process is getty, and it allows you to log into your Raspberry Pi directly over the serial port at 115200 baud. Pretty cool, but absolutely in our way at the moment. We need that serial port to be open and unoccupied!
The first step to taking back the serial port is to stop the system from setting it up as a console in /boot/cmdline.txt
Let's start by backing up the file
sudo cp /boot/cmdline.txt /boot/cmdline_backup.txt
Alright, now to edit the file (I'm going to use vim for this)
sudo vim /boot/cmdline.txt
Remove these two settings (you may only find the first setting if you are on a NOOBS install):
- console=ttyAMA0,115200
- kgdboc=ttyAMA0,115200
Save the file.
Now we need to stop the system from using getty to handle data on the serial port. This handler is assigned to the serial port in another file: /etc/inittab. Let's edit the file.
sudo vim /etc/inittab
Comment out the serial port handler line by changing
2:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
To
#2:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
Save the file.
At this point the serial port will no longer be used by the system at bootup. Now we need a program that allows us to type into and read back from with the serial port directly. I'm going to use Picocom. Picocom is a very stripped down command line terminal emulator.
sudo apt-get install picocom
Once it is installed you can run it like this:
picocom -b 300 /dev/ttyAMA0
The -b sets the baud rate. This is the fastest rate my antique modem functions, so I'm going with that! And /dev/ttyAMA0 is our GPIO UART serial port, of course. With Picocom running, everything you type gets sent down the serial port, and everything sent up from the serial port gets printed directly on your screen. Old School!
You can now interface your ancient telecommunications equipment directly to a modern Raspberry Pi. This opens up all sorts of great project ideas. Let us know yours in the comments section.
---
You could stop there, but I want a REALLY dumb terminal. So I'm going to go a step further and make my Raspberry Pi boot directly into Picocom with no login. Time for hack-foo!
Create a bash script. This script clears the screen, prints a welcome message, then runs Picocom.
sudo vim /usr/bin/vterm
#!/bin/bash
clear
echo "Toymaker Television Terminal"
/usr/bin/picocom -b 300 /dev/ttyAMA0
Save the file.
Set the file to be executable
sudo chmod +x /usr/bin/vterm
Now for the deep magic. We're going to assign the handling of tty1 (the console you get attached to when the Raspberry Pi boots up, and that you usually log into) to our own script. In a normal world tty1 is handled by a getty process, but we're feeling adventurous so
sudo vim /etc/inittab
Change
1:2345:respawn:/sbin/getty --noclear 38400 tty1
To
1:2345:respawn:/usr/bin/vterm
Save the file.
So now, when the Raspberry Pi boots up, instead of asking you to login it is instead going to hand you over to our vterm script. Which clears the screen, prints a welcome message, and starts Picocom connected to the GPIO UART serial port (and our acoustic coupler). Note that 'respawn'. What that means is that if you exit Picocom (and the script ends) the system will respawn a new vterm script and hook you to it. Cool!
So you might think, well ok, but how the heck do I log back into my Raspberry Pi now? We've disabled the serial port login, and we've hijacked the tty1 login!
Don't worry, by default Raspbian starts a whole bunch of ttys (you may have noticed them while you were editing /etc/inittab). You can switch another tty by holding ALT on your keyboard along with one of the F keys (F1 = tty1, F2 = tty2, etc). If you switch to tty2, you'll get your usual Login: prompt, allowing you to get into your Raspberry Pi.
I hope you found this Instructable fun and informative. Thanks for taking the time out of your day!
7 Comments
LucaD60 6 years ago
Hi, how have you solved the item to connect the old clicking keyboard to the rsapberry usb? Did you use a ps2 to usb keyboard converter?
And what about the monocrome monitor? In what way did you connect it to the raspberry?
The olda monitor is a composite video type monitor? Or did hou have to use an adapter for the hdmi?
Many thanks!
Luca
gumby_kevbo 8 years ago
Hardware handshaking (RTS/CTR/DSR/DTR) was needed in the bad slow days. Then computers got faster, and we could mostly dispense with it. Then came windows 95, and with it the return to the need for hardware handshake. We can call these the bad fast days. Post Windows 95, it was no longer possible for an application program to determine when serial data might be sent or received. Windows buffers serial out data, and sends it when it feels like it. Windows also ignores serial interrupts if it is busy telling the user about unused icons on the desktop, or telling the user they didn't successfully enter the WiFi key the same way twice, or if it is a day ending in y. Seriously, without hardware handshaking you will never get reliable data transfer under windows....and that is pretty much the story on why serial ports on PCs have gone the way of the dodo. Well that and real RS-232 ports needed voltages that were inconvenient, even though port chips with onboard charge pumps to generate 9V levels from 5V supply are common.
There were just enough options on how to do hardware handshaking that it often took a guru with a breakout box to get it to function...that was me, by the way. Serial got a reputation for being hard to deal with...then USB got cheap and simple, and faster.... sinara '232.
RS-485 endures in the industrial control world. It is fast enough for plenty of things and you can get distance that USB can't touch. Ethernet is taking over though.
gtoal 8 years ago
Why is it you never ever see an RPi or arduino project using serial data that uses RTS/CTR or DTR/DSR any more? They were absolutely essential in the modem days or you would get data overruns and lost characters...
Tymkrs 8 years ago
In our case, they really did not matter at all. Like AlyssonR2 mentioned, the Raspberry Pi and the modem on the other side are so fast compared to the speed of the acoustic coupler that we simply did not have to interface to 'Clear to Send' or 'Data Set Read'y pins on the coupler.
Our first attempt at interfacing this modem involved using a five wire usb to rs232 cable but the manufacturer didn't design the charge pump properly. Their voltages were not swinging nearly far enough and it was causing the modem to essentially brownout with every bit that came in.
Also interesting to note, there is no controlling inside of this modem. It's all op-amps and a 555 timer. Pretty awesome old tech.
AlyssonR2 8 years ago
A very nice 'ible on the melding of vintage and modern hardware. Most modern users forget the origins of their serial communications ports as being based in the +/- 15V RS232C standard.
@ gtoal:
Modern systems run so fast that the FIFO buffers tend to not overrun any more - and where software allows, then the buffer size is simply expanded as required.
The last time I used equipment that actually usilised the RTS/STS DSR/DTR signals was a 1200/1200 baud modem back in the late 1970's - ever since then it has been XON/XOFF TRON/TROFF (software) flow control.
At 300 baud, the system at both ends spend a lot of its time simply waiting for data. Modern telephone systems don't suffer the amount of noise that the older network hardware exhibited, so a 300 baud signal is likely to pass without error first time, every time. Bad packets will be handled by software, these days, rather than the communication hardware.
This all makes RTS/CTR, DTR/DSR protocols redundant, and usually obviates the need for XON/XOFF as well.
gtoal 8 years ago
AlyssonR2 8 years ago
@ gtoal:
The overrun you have experienced is quite definitely an ouch!
Microcontroller
devices with slow data consumption and small buffers should always have
an XON/XOFF protocol written into their interfaces.
I have a couple of older FTDI USB to RS232(TTL) cables that have the 5-wire interface which is absent on the newer cables.
The
LC Studio RS232 breakouts utilising the MAX3232 ICs have the second
send/recieve pair brought out to a 0.1" header, ready for use as either a
second 3-wire port or for wiring onto the 9-pin D connector for
conversion to a 5-wire interface.
Sadly, the smart RS232C devices
with built-in FIFO and built-in HW/SW flow-control don't seem to have
made it down as far as the microcontroller hobbyist market - probably
because of the ubiquity of the dreaded USB interface.
I cannot
help but feel that the vanilla serial port with flow control
capabilities still has an enormous amount to offer, and I regret its
disappearance from our systems.