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.

31 thoughts on “Tio Is A Serial Terminal For Us

  1. My first job out of college was on the team that designed the Data General D200 serial terminal, so I’m getting a kick out of this. Thanks for developing this. The serial interface is probably the simplest to build into a project, both from a hardware and firmware viewpoint.

    I have fond memories of XMODEM and my favorite serial terminal program, CROSSTALK XVI.

  2. Can this paste a text file, like a BASIC listing for your average Z80 SBC or “that obscure format”(TM) that U-Boot can use in a pinch, with delays between characters? An important feature when dealing with such devices.

    1. Me too. Or at least give some video controls so I could pause it, read the article, and then come back and finish the video without having to worry about waiting on it to loop.

      1. @Frankel said: “Am I the only one who would prefer static screenshots over infinitely scrolling gifs to demo a project?”

        Just download the .gif and step through it frame-by-frame in an image viewer app. Frame stepping is by default usually controlled with the space bar.

          1. Hi guys, sorry about the fast running gif. I recently edited the original gif in GIMP and that resulted in all gif wait states being truncated to 100 ms so it started running a lot quicker than normal and I didn’t notice. I’ve now fixed it so it runs slower again.

            Unfortunately making it an embedded video is not easily possible because github markdown does not support videos.

            Anyway, the gif is only meant as a quick showcase demo. If you want more details you can see the rest of the github README or browse the tio man page here: https://github.com/tio/tio/blob/master/man/tio.1.txt

  3. I found this tool a few months ago and really like it! nice with the recent updates to be able to connect to a socket to be able to interact with multiple scripts and such.
    mostly been using screen previoulsy but never liked it, also been trying different *term*’s but tio is much nicer, thanks for featuring it here with an article, hope it ends mentioned in the pod on friday also!

  4. “You might think the serial port is dead,”

    I don’t get that.

    “Back in the day” when common peripherals like mice, printers and modems actually used serial ports they were usually an accessory. They lived on a separate expansion card, maybe it was the same card as the hard drive and floppy controller or maybe it was it’s own card.

    Now, when serial ports are supposedly dead they come built into most motherboards. If you are on a desktop check the little panel in the back where the motherboard’s built in connectors are. There is probably one or two serial ports there. If not then I bet there’s a header on your motherboard somewhere that just needs hooked up. Even a parallel port header isn’t exactly hard to find.

    I just checked the back of this little Dell office box I am typing on. Surely this wasn’t marketed for any use that would require a serial port but there it is!

    I get why consumer peripherals don’t have much use for a serial port. More expensive cable, people don’t want to have to learn which connector goes to what, USB supplies power, etc…

    I am surprised I don’t see real serial ports used in more of the sorts of projects we see here though. There’s something to be said for plugging in and knowing your device is TTYS0 or COM1 every time. Is this new USB toy ttyUSB0, or ttyACM0? Why isn’t my sketch uploading? Oh, for some reason my microcontroler just became ttyUSB1 instead of 0. That’s annoying!

    I guess once you know your way around /dev and the setup area of whatever software you are using it isn’t the end of the world. But (IMHOP) those ever-renumbering USB serial ports just make things seem cheap and unfinished.

    Unless you want to write udev rules for every device…

    1. Serial ports still live on as virtual devices, too.
      Like virtual null-modem cables, to connect an APRS program (Ui-view32, Xastir) to a software-based KISS TNC (MixW2, direwolf).

      Most modern amateur radio equipment does contain an USB-Serial Converter chip, also.

      That’s necessary, because things like fancy USB sound card interfaces must still be controllable via RTS/DTR pins.
      Even recent software on macOS, Linus and Windows still use the control lines to enable transmitt (PTT), simulate a morse key et cetera.

      That way, both old an new ports can be utilized the same way.
      Heck, even DOS era programs in an emulator or VM can be mapped to USB serial converters.
      That’s really cool, I think. 😎👍

  5. screen was a revolution coming from the minicom configuration nightmare:

    $ screen /dev/ttyUSB0 115200

    Battled a lot with pppconfig and minicom in the nineties to try to get dialup internet working.

    Now tio seems to detect the baudrate, curious to see how they do that…

    1. \o/ Screen! \o/

      It only lacks SIXEL support. If that surfaces (exists only for an older version) I’ll mark that day as holiday in my calendar.

    2. screen is the way.

      Whether serial, working over ssh, or simply working with multiple terminals locally, screen is the way. One of previous gigs was working with a large distributed architecture consisting of over 20 classes of server, all with redundancies. I usually needed to watch or view logs from several of these simultaneously. I had several screenrc files setup that I could select depending on which servers I needed to monitor. Each would spawn the required number of terminal sessions, set titles with the servers’ names and sit in wait loops for me to hit enter to spawn each ssh connection to view the logs. (5 minute ssh timeouts everywhere – those loops were useful). I could then easily trace events through the architecture. Screen usefully allows for multiple incoming connections too. That allowed a second and third monitor to have terminals connection to the same screen session so I could view multiple logs simultaneously in full screen (big stacktraces don’t always fit as well into screens ‘split’ functionality. Most of the time I worked with one monitor for a browser (Jira and manipulating the webapp) and email, and two for screen connections.

      As another bonus, when I locked my computer and left for the night, those screen sessions would remain open, so when I decided to work from home the next day and tunneled my ssh connection into it, I could reconnect to that session and pickup pretty much where I had left off. Everything looked the same everywhere.

      The only thing I don’t like about screen is the Ctrl-a default Command key binding. I use that a lot in bash shells, so my screenrcs always rebind.

      1. screen is the way… but tmux + tio is the future :)

        Actually, I was a long time screen user myself until the rise of tmux which I now use on the daily instead. I consider tmux a modern and better alternative to screen. However, it started to seem a bit silly to start screen inside a tmux session just for it to connect to a serial port and so I decided to create tio as a simple replacement. Since then tio has grown to accommodate the needs of embedded developers and hackers but it is still simple at its core.

        1. @lundmar said: “screen is the way… but tmux + tio is the future :)”

          Nah… TIO does not seem to have split transmit/receive lines, something I consider mandatory for a serial terminal application. For example, a serial device is constantly outputting data, NMEA-0183 sentences from a GPS receiver let’s say. While that is happening you need to simultaneously input a complex GPS configuration command line interactively. That is almost impossible to accomplish without split transmit/receive lines or windows in the same terminal session.

          That’s a shame, especially given split CLI windows are easily implemented with ncurses(3).[1][2][3] Note, having split transmit/receive lines in a single serial terminal is NOT the same as terminal splitting or multiplexing (e.g. using tmux(1), screen(1), etc.)[4]

          1. man ncurses(3)


          2. NCURSES Programming HOWTO


          3. Best ncurses linux console programs (just for fun)


          4. 5 ways to split your Linux terminal


          1. Oh yes, split I/O is a great feature. I’m putting that on the TODO list for tio. Thank you for the feature suggestion.

            That being said, it will not be ncurses based. tio is specifically designed not to use ncurses so that the scroll buffer will be managed by whatever terminal program that you prefer to use (tmux, screen, gnome-terminal, tilix, Konsole, putty, etc.). I will implement the split I/O feature so that you can redirect input and output independently to any terminal via the socket feature. This will be a very flexible solution as it will allow you to e.g. redirect to any tmux pane or window, or other terminal of your choice.

  6. tio is great! I’ve used to read the output from my cable modem because the cable modem CPU was pegged trying to connect. Serial port output is a hell of a lot more informative than the web interface that doesn’t have any CPU to actually serve the pages.

    1. Cool, I’m still using terminal.exe from the Windows 2.03 days. Has line echo option and VT52 emulation. It’s a wonderfully generic terminal emulator that also was made with a Host-Host connection in mind. It doesn’t assume a Hayes modem. I’ve also used it on the then new Windows 3.1..

  7. As an embedded dev, tio is useful to connect to devices that provide virtual com ports via USB as soon as they are ready. Normally, screen, minicom, etc. won’t connect until /dev/ttyACM0 is ready. tio waits and connects instantly, so I don’t miss any start up messages. Nice.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.