Tio Is A Serial Terminal For Us

With Linux and the serial port there is good news and there is bad news. The good news is that Linux has great support for serial hardware of all sorts and a host of tools for accessing the serial port. That’s important when you use a lot of serial-like devices like Arduinos with USB ports and the like. The bad news is that most of the terminal software is made to accommodate the days when a computer had real serial terminals and modems with people interacting with them. We bet that’s why [lundmar] developed tio, a serial device I/O tool for people like us.

Honestly, how many times have you needed Zmodem file transfers and recognition of the DCD signal to detect an incoming connection? Sure there are many other programs that will do the job, but tio brings a clean simplicity along with functionality that embedded developers need.

The software will support arbitrary devices, show statistics, and give you control of the RS232 lines. There’s support for delayed characters and lines, useful if you are dealing with a super simple device with no handshaking. There’s also hex support and many ways to log data and statistics. We especially like that it can automatically reconnect which is a great feature.

Of course, you want some terminal features and tio includes those. For example, you can elect to have local echo turned on or map characters so that, for example, a carriage return turns into a carriage return and a line feed. You can use command line options to set up most items including features like redirecting to a network socket. Other commands inside the program — by default, triggered by Control+T — let you do things like send a break, toggle handshaking lines, and more.

You might think the serial port is dead, but it really just transformed into a USB port.  Of course, like everything else these days, you can also get your terminal in the browser.

Serial Studio One Year On

Last year we wrote about [Alex Spataru]’s Serial Studio project, which started life as serial port data visualizer, like a souped-up version of the Arduino serial plotter. [Alex] has been actively improving the project ever since, adding a variety of new features, including

  • JSON editor for data formats
  • TCP, UDP, and Multicast
  • New and more flexible display widgets
  • Multi-signal plots
  • FFT and logarithmic plots
  • VT-100 emulation
  • Support for plugins and themes
  • Added MQTT support

[Alex] originally came up with Serial Studio because he was involved in ground station software for various CanSat projects, each one with similar yet slightly different data formats and display requirements. Rather than make several different programs, he decided to make Serial Studio which could be configured using JSON descriptor files.

The program is open-source and multi-platform. You can build it yourself or download pre-compiled binaries for Windows, Linux, and Mac. See the project GitHub repository for more details. In addition to English, it has also been translated into Spanish, Chinese, and German. What is your go-to tool for visualizing serial data telemetry these days? Let us know in the comments below.

MC68k SBC with a monitor, keyboard and mouse

Motorola 68000 SBC Runs Again With A Raspberry Pi On Top

Single-board computers have been around a long time: today you might be using a Raspberry Pi, an Arduino, or an ESP32, but three decades ago you might find yourself programming a KIM-1, an Intel SDK-85, or a Motorola 68000 Educational Computer Board. These kind of boards were usually made by processor manufacturers to show off their latest chips and to train engineers who might use these chips in their designs.

[Adam Podstawczyński] found himself trying to operate one of these Motorola ECBs from 1981. This board contains a 68000 CPU (as used in several Macintoshes and Amigas), 32 kB of RAM, and a ROM program called TUTOR. Lacking any keyboard or monitor connections, the only way to communicate with this system is a pair of serial ports. [Adam] decided to make the board more accessible by adding a Raspberry Pi extended with an RS232 Hat. This add-on board comes with two serial ports supporting the +/- 12 V signal levels used in older equipment.

It took several hours of experimenting, debugging, and reading the extensive ECB documentation to set up a reliable connection; as it turns out, the serial ports can operate in different modes depending on the state of the handshake lines. When the Pi’s serial ports were finally set up in the right mode, the old computer started to respond to commands entered in the terminal window. The audio interface, meant for recording programs on tape, proved more difficult to operate reliably, possibly due to deteriorating capacitors. This was not a great issue, because the ECB’s second serial port could also be used to save and load programs directly into its memory.

With the serial connections working, [Adam] then turned to the aesthetics of his setup and decided to make a simple case out of laser-cut acrylic and metal spacers. Custom ribbon cables for the serial ports and an ATX break-out board for power connections completed the project, and the 40-year-old educational computer is now ready to educate its new owner on all the finer points of 68000 programming. In the video (embedded after the break) he shows the whole process of getting the ECB up and running.

[Adam] made a similarly clever setup with a Commodore 64 and an Arduino earlier. [Jeff Tranter] recreated a similar 68000 development board from scratch. And a few years ago we even featured our own custom-built 68k computer.

Continue reading “Motorola 68000 SBC Runs Again With A Raspberry Pi On Top”

DOOM On A Desk Phone Is Just The Tip Of The Iceberg

These days we expect even the cheapest of burner smartphones to feature a multi-core processor, at least a gigabyte of RAM, and a Linux-based operating system. But obviously those sort of specs are unnecessary for an old school POTS desktop phone. Well, that’s what we thought. Then [Josh Max] wrote in to tell us about his adventures in hacking the CaptionCall, and now we’re eager to see what the community can do with root access on a surprisingly powerful Linux phone.

As the names implies, the CaptionCall is a desk phone with an LCD above the keypad that shows real-time captions. Anyone in the United States with hearing loss can get one of these phones for free from the government, so naturally they sell for peanuts on the second hand market. Well, at least they did. Then [Josh] had to go ahead and crack the root password for the ARMv7 i.MX6 powered phone, started poking around inside of its 4 GB of onboard NAND, and got the thing running DOOM.

Tapping into the serial port.

If you’re interested in the technical details, [Josh] has done a great job taking us step by step through his process. It’s a story that will be at least somewhat familiar to anyone who’s played around with embedded Linux devices, and unsurprisingly, starts with locating a serial port header on the PCB.

Finding the environment variables to pretty tightly locked down, he took the slow-route and dumped the phone’s firmware 80 characters at a time with U-Boot’s “memory display” command. Passing the recovered firmware image through binwalk and a password cracker got him the root credentials in short order, and from there, that serial port got a whole lot more useful.

[Josh] kicked the phone’s original UI to the curb, set up an ARM Debian Jessie chroot, and started working his way towards a fully functional Linux environment. With audio, video, and even keypad support secured, he was ready to boot up everyone’s favorite 1993 shooter. He’s been kind enough to share his work in a GitHub repository, and while it might not be a turn-key experience, all the pieces are here to fully bend the hardware to your will.

Historically, running DOOM on a new piece of hardware has been the harbinger of bigger and better things to come. With unfettered access to its Linux operating system up for grabs, we predict the CaptionCall is going to become a popular hacking target going forward, and we can’t wait to see it.

Roomba Gets Alexa Support With An ESP8266 Stowaway

The modern home is filled with plenty of “smart” devices, but unfortunately, they don’t always speak the same language. The coffee maker and the TV might both be able to talk to your phone through their respective apps, but that doesn’t necessarily mean the two appliances can work together to better coordinate your morning routine. Which is a shame, since if more of these devices could communicate with each other, we’d be a lot closer to living that Jetsons life we were promised.

Luckily, as hardware hackers we can help get our devices better acquainted with one another. A recent post by [MyHomeThings] shows how the ESP8266 can bridge the gap between a Roomba and Amazon’s Alexa assistant. This not only allows you to cheaply and easily add voice control to the robotic vacuum, but makes it compatible with the Amazon’s popular home automation framework. This makes it possible to chain devices together into complex conditional routines, such as turning off the lights and activating the vacuum at a certain time each night.

The hack depends on the so-called Roomba Open Interface, a seven pin Mini-DIN connector that can be accessed by partially disassembling the bot. This connector provides power from the Roomba’s onboard batteries as well as a two-way serial communications bus to the controller.

By connecting a MP1584EN DC-DC converter and ESP8266 to this connector, it’s possible to send commands directly to the hardware. Add a little glue code to combine this capability with a library that emulates a Belkin Wemo device, and now Alexa is able to stop and start the robot at will.

We’ve seen this sort of trick used a few times before to add backdoor Alexa support to various gadgets, and it’s always interesting to see what kind of unusual hardware folks are looking to make an integral part of their smart home.

Apple II Talks To 3D Printer With A Little Modern Help

Controlling most desktop 3D printers is as easy as sending them G-code commands over a serial connection. As you might expect, it takes a relatively quick machine to fire off the commands fast enough for a good-quality print. But what if you weren’t so picky? If speed isn’t a concern, what’s the practical limit on the type of computer you could use?

In an effort to answer that question, [Max Piantoni] set out to control his Ender 3 printer with an authentic Apple IIc. Things were made a bit easier by the fact that he really only wanted to use the printer as a 2D plotter, so he could ignore the third dimension in his code. All he needed to do was come up with a BASIC program that let him create some simple geometric artwork on the Apple and convert it into commands that could be sent out over the computer’s serial port.

Unity controlling the Ender 3

Unfortunately, [Max] ran into something of a language barrier. While the Apple had no problem generating G-code the Ender’s controller would understand, both devices couldn’t agree on a data rate that worked for both of them. The 3D printer likes to zip along at 115,200 baud, while the Apple was plodding ahead at 300. Clearly, something would have to stand in as an interpreter.

The solution [Max] came up with certainly wouldn’t be our first choice, but there’s something to be said for working with what you know. He quickly whipped up a program in Unity on his Macbook that would accept incoming commands from the Apple II at 300 baud, build up a healthy buffer, and then send them off to the Ender 3. As you can see in the video after the break, this Mac-in-the-middle approach got these unlikely friends talking at last.

We’re reminded of a project from a few years back that aimed to build a fully functional 3D printer with 1980s technology. It was to be controlled by a Commodore PET from the 1980s, which also struggled to communicate quickly enough with the printer’s electronics. Bringing a modern laptop into the mix is probably cheating a bit, but at least it shows the concept is sound.

Continue reading “Apple II Talks To 3D Printer With A Little Modern Help”

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”