DIY Wireless Serial Adapter Speaks (True) RS-232

There is a gotcha lurking in wait for hackers who look at a piece of equipment, see a port labeled “Serial / RS-232”, and start to get ideas. The issue is the fact that the older the equipment, the more likely it is to be a bit old-fashioned about how it expects to speak RS-232. Vintage electronics may expect the serial data to be at bipolar voltage levels that are higher than what the typical microcontroller is used to slinging, and that was the situation [g3gg0] faced with some vintage benchtop equipment. Rather than deal with cables and wired adapters, [g3gg0] decided to design a wireless adapter with WiFi and Bluetooth on one end, and true RS-232 on the other.

The adapter features an ESP32 and is attached to a DB-9 plug, so it’s nice and small. It uses the ST3232 chip to communicate at 3 V logic levels on the microcontroller side, supports bipolar logic up to +/-13 V on the vintage hardware side, and a rudimentary web interface allows setting hardware parameters like baud rate. The nice thing about the ST3232 transceiver is that it is not only small, but can work from a 3 V supply with only four 0.1 uF capacitors needed for the internal charge pumps.

As for actually using the adapter, [g3gg0] says that the adapter’s serial port is exposed over TCP on port 23 (Telnet) which is supported by some programs and hardware. Alternately, one can connect an ESP32 to one’s computer over USB, and run firmware that bridges any serial data directly to the adapter on the other end.

Design files including schematic, bill of materials, and PCB design are shared online, and you can see a brief tour of the adapter in the video, embedded below.

Continue reading “DIY Wireless Serial Adapter Speaks (True) RS-232”

WebSerial: Browser Based Development For Your Boards And Electronic Badges

For years, one of the most accessible and simplest-to-implement methods of talking to a dev board has been to give it a serial port. Almost everything has serial in some form, so all that’s needed is to fire up a terminal. But even with that simplicity, there are still moments when the end user might find a terminal interface a little daunting. Think of a board aimed at kids for example, or an event badge which must be accessible to as many people as possible.

We’ve seen a very convenient solution to this problem in the form of WebUSB, but for devices without the appropriate USB hardware there’s WebSerial, an in-browser API for communicating with serial ports including USB-to-serial chips. [Tom Clement] argues that this could serve as the way forward for event badges. Best of all it can be a retro-fit to enable in-browser development for older badges or dev boards with a serial port.

The boards on which he demonstrates the technique are the series of event badges running the firmware platform including his own i-Pane from CampZone 2019 and going right back to the SHA 2017 badge, but there’s no reason why the same technique can’t be extended to other boards.

There’s a snag with all this though, sadly only browsers in the Chrome family support it at the time of writing, with no plans from Mozilla and apple, and silence from Microsoft. So things look likely to stay that way. It is however inevitable that in time there will be commercial products taking advantage of it via the use of cheap USB to serial chips, so perhaps the case to incorporate it will make itself.

Header: Mobius, Public domain.

Decoding The PS/2 Keyboard Protocol Using Good Old Fashioned Hardware

1987 was a glorious year.  It brought us the PS/2 keyboard standard that’s still present on many a motherboard back panel to this day. (It also marked the North America/Europe release of The Legend of Zelda but that’s another article.) Up until this point, peripherals were using DIN-5 and DE-9 (often mistakenly called DB9 and common for mice at the time) connectors or — gasp — non-standard proprietary connectors. So what was this new hotness all about? [Ben Eater] walks us through the PS/2 hall of fame by reverse-engineering the protocol.

The PS/2 connector in all its glory

This is a clocked data protocol, so a waveform is generated on the data pin for each key pressed that can be compared to the clock pin to establish the timing of each pulse. Every key sends a unique set of encoded pulses and voila, the whims of the user can quickly and easily be decoded by the machine.

This is where [Ben’s] dive really shines, we know he’s a breadboarding ninja so he reaches for some DIP chips. A shift register is an easy way to build up a parallel PS/2 interface for breaking out each data packet. There are a few quirks along the way, like the need to invert the clock signal so the shift register triggers on the correct edge. He also uses the propagation delay of a couple inverter gates to fire the 595 shift register’s latch pin slightly late, avoiding a race condition. A second 595 stores the output for display by a set of LEDs.

Beyond simply decoding the signal, [Ben] goes into how the packets are formatted. You don’t just get the key code, but you get normal serial interface error detection; start/stop bits and a parity bit as well. He even drills down into extended keys that send more than one packet, and a key-up action packet that’s sent by this particular keyboard.

This is the perfect low-level demo of how the protocol functions. On the practicality side, it feels a bit strange to be breaking out the serial to parallel when it would be very easy to monitor the two signal lines and decode them with a microcontroller. You might want to switch it up a bit, stick with the clock and data pins, but connect them to a Raspberry Pi using just a few passive components.

Continue reading “Decoding The PS/2 Keyboard Protocol Using Good Old Fashioned Hardware”

Linux Fu: Serial Untethered

Serial ports used to be everywhere. In a way, they still are since many things that appear to plug in as a USB device actually look like a serial port. The problem is that today, the world runs on the network. Sure, you can buy a terminal server that converts a serial port to an Ethernet port, but what fun is that? In this article, I’m going to show you how to stream serial ports over the network using some available Linux tools. It isn’t perfect, and it won’t work for every case, but when it works it works well.

Everything is a File, Until it Isn’t

At some point in the past, Unix — the progenitor of Linux — treated virtually everything as a file, and all files were created more or less equal. Programs didn’t care if a file was local, on the network, from a tape drive, or arriving over a named pipe.

But things started to change. Even though a serial port is just a file under Linux, it has some special attributes that let you set, for example, baud rates. Worse, some programs “know” too much about files and insist on certain naming conventions. So, in theory, you should be able to create a network socket, connect one end to a serial port and the other end to a program, and be done with it. In theory.

Continue reading “Linux Fu: Serial Untethered”

Modified Yost Tames Pinout Plethora

Every hacker has an assortment of USB to TTL-serial adapters kicking around in their lab, and we have all been annoyed that each one has a different pinout. You layout a PCB or breadboard for the Sparkfun flavor (GND, CTS, VCC, TXD, RXD, DTR), but when you begin troubleshooting all you can find is a CH340 board (GND, +5V, TXD, RXD, DTR, +3.3V). You have to jumper everything, and it becomes a mess. It wasn’t much better back in the days of RS-232 level signaling, either. While the pinouts were consistent, there were other headaches. Did the connection need a NULL modem adaptor? And if you were unlucky, you might need a DB-25 to DE-9 adaptor, and the really unlucky might need one or more gender changers. Surely there’s a better way.

It turns out there was a better way, although it didn’t seem to have become as popular as one might expect. Back in 1987 [Dave Yost] formalized an interconnection scheme using RJ45 plugs and jacks while at Berkeley.  The signals were arranged in a mirrored fashion so that each cable is always a crossover — just plug two cables back-to-back if you really need a straight thru connection.

Even though he was dealing with RS-232 serial, nothing prevents us from using this scheme for logic level signaling. For example, consider the following 1×10 header pinout, where the original 8-pins are expanded to 10 to allow for power:

This is an extreme example, and can obviously be shrunk depending on how much handshaking, if any, or power is desired. Such a pinout lets you switch between DCE and DTE by simply flipping the connector around. And if a Dupont-style header slips off too easily in your applications, you could always use an RJ connector. This still doesn’t solve the Tower of Babel pinout problem with the USB-TTL adaptors. But standardizing on a serial pinout such as this for your projects and making cables or kludging your TTL adaptors will make serial debugging less painful.

Yost to Sparkfun Adaptor Cable

Back when he released this scheme in 1987, [Dave] pontificated:

“Maybe one day before the year 2,000, the world will have a new, simple, high-speed, flow-controlled, standard type of connection for point-to-point applications currently using RS-232, with an adaptor available to talk to old, RS-232 equipment.”

Let us know your thoughts in the comments below.

A Portable Serial Terminal That Should Be From The 1970s

The humble standalone serial terminal might be long gone from the collective computing experience, but in the ghostly form of a software virtual terminal and a serial converter it remains the most basic fall-back and essential tool of the computer hardware hacker. [Mitsuru Yamada] has created the product that should have been made in the serial terminal’s heyday, a standalone handheld terminal using a 6809 microprocessor and vintage HP dot matrix LEDs. In a die-cast box with full push-button keyboard it’s entirely ready to roll up to a DB-25 wall socket and log into the PDP/11 in the basement.

Using today’s parts we might achieve the same feat with a single-chip microcontroller and a small LCD or OLED panel, but with an older microcomputer there is more system-building required. The 6809 is a wise choice from the 1970s arsenal because it has some on-board RAM, thus there’s no need for a RAM chip. Thus the whole thing is achieved with only a 2716 EPROM for the software, a 6850 UART with MAX232 driver  for the serial port, and a few 74 chips for glue logic, chip selects, and I/O ports to handle keyboard and display. There’s no battery in the case, but no doubt that could be easily accommodated. Also there’s not much information on the keyboard itself, but in the video below we catch a glimpse of its wiring as the box is opened.

The value in a terminal using vintage parts lies not only in because you can, but also in something that can’t easily be had with a modern microcontroller. These parts come from a time when a computer system had to be assembled as a series of peripherals round the microprocessor because it had few onboard, leading to a far more in-depth understanding of a computer system. It’s not that a 6809 is a sensible choice in 2020, more that it’s an interesting one.

By comparison, here’s a terminal using technology from today.

Continue reading “A Portable Serial Terminal That Should Be From The 1970s”

Discrete-Logic UART Keeps 8-Bit TTL Computer Connected

Pity the poor TTL computer aficionado. It’s an obsession, really — using discrete logic chips to scratch-build a computer that would probably compare unfavorably to an 80s era 8-bit machine in terms of performance. And yet they still forge ahead with their breadboards full of chips and tangles of wire. It’s really quite beautiful when you think about it.

[Duncan] at Shepherding Electrons has caught the TTL bug, and while building his 8-bit machine outfitted it with this discrete logic UART. The universal asynchronous receiver-transmitter is such a useful thing that single-chip versions of the device have been available since the early 1970s. [Duncan]’s version makes the magic of serial communications happen in just 12 chips, all from the 74LS logic family.

As if the feat of building a discrete logic UART weren’t enough, [Duncan] pulled this off without the aid of an oscilloscope. Debugging was a matter of substituting the 2.4576 MHz crystal oscillator clock with a simple 1 Hz 555 timer circuit; the reduced clock speed made it easier to check voltages and monitor the status of lines with LEDs. Once the circuit was working, the full-speed clock was substituted back in, allowing him to talk to his 8-bit computer at up to 38,400 bps. Color us impressed.

For more TTL computer goodness, and to see where [Duncan] got his inspiration, check out [Ben Eater]’s many discrete logic projects — his scratch-built 6502, a low-end video card, or even his take on serial communications.