tio - A simple serial device I/O tool for linux

[lundmar]

A new version of tio is released which fixes a bug when running on Fedora, RHEL etc.: https://github.com/tio/tio/releases/tag/v1.25

[lundmar]

There have been quite a few tio releases since this thread was last active:

https://github.com/tio/tio/releases

New features have been added such as support for setting arbitrary baud rates and remapping of special characters to support more embedded targets.

Also, latest tio is now available as a snap:

Code: [Select]

$ snap install tio


[lundmar]

A lot of new features and bug fixes have been added since tio was last mentioned in this forum.

If you are a Linux user and need a simple but powerful tool to connect to the serial device of your embedded target, then you should definitely give tio a try.

tio v1.39 has just been released and the updated version will be available on various platforms soon:

https://github.com/tio/tio/releases

Recently tio gained configuration file support and support for redirecting I/O to a file or network socket which can come handy if you need to interact with embedded targets via scripts. Color support and support for easily listing available serial devices have also been added.

[lundmar]

tio v1.40 has been released.

[NiHaoMike]

I'm sorry but if you want your application to be a first class citizen then you simply don't write a tool like this in Python. I mean, it is okay if you accept (i don't) the usual problems with Python version incompatibilities, missing package dependencies, bigger CPU execution overhead, and the horribly long winded list of error messages facing a user when even a simple exception occurs. Thanks but no thanks

A serial terminal app is going to be I/O bound, CPU is not going to bottleneck even on something as slow as a Raspberry Pi Zero. Of which, the way I/O is currently done in tio can use a big improvement: https://github.com/tio/tio/issues/110

I suppose someone who really wants to benchmark terminal apps could use an Atomic Pi in OTG mode to create a USB3 serial port, just a bit silly since serial over USB wasn't really designed for maximum throughput.

[lundmar]

A serial terminal app is going to be I/O bound, CPU is not going to bottleneck even on something as slow as a Raspberry Pi Zero. Of which, the way I/O is currently done in tio can use a big improvement: https://github.com/tio/tio/issues/110

Yes, I'm fully aware of that and it is so deliberately. Until now the priority have been to keep the implementation simple and adding features so optimization to solve this specific issue have taken a back seat. That will change soon now that a long list of pending contributed PRs have recently been resolved.

[janoc]

NiHaoMike, you do realize you started to argue about a 5 years old post, right?

[lundmar]

tio v1.42 has been released.

See https://github.com/tio/tio/releases

[Benta]

Yes, tio is wonderful. And?

[eti]

"screen", "minicom" etc suffice just well and good. This is the issue with Linux - too many ways to achieve exactly the same thing.

[lundmar]

"screen", "minicom" etc suffice just well and good. This is the issue with Linux - too many ways to achieve exactly the same thing.

"putty", "hyperterminal" etc suffice just well and good. This is the issue with Windows - too many ways to achieve exactly the same thing.

[lundmar]

tio v1.43 released

See https://github.com/tio/tio/releases/tag/v1.43

This release introduces a key command to easily pulse the serial port DTR line. This is useful for resetting ESP32 MCU targets.

Also new is a "24hour-delta" timestamp format which makes it easier to identify which command takes the most time etc.

[lundmar]

The latest tio now features output line delay which is sometimes needed for dealing with slower embedded targets. Also added is support for space and mark parity.

https://github.com/tio/tio/releases

[DiTBho]

Not bad at all, I have already prepared an Overlay for stage4-2008 MIPS32LE for my router.
tio sources don't have special requirements, that's nice to see 

[DiTBho]

support for redirecting I/O to a file or network socket

yup, this is helpful for me

[lundmar]

support for redirecting I/O to a file or network socket

yup, this is helpful for me

Yeah, it is a pretty useful feature for scripting or sharing the same tty device. This file socket feature was originally contributed by an engineer from Google. Since then I have extended it to support both ipv4 and ipv6 network sockets.

Recently tio was featured on Hackaday (https://hackaday.com/2022/07/13/tio-is-a-serial-terminal-for-us) and here someone mentioned that tio should support split I/O.

I plan to support that by allowing to split the input and output on independent socket ports and socket files. The idea is detailed in https://github.com/tio/tio/blob/master/TODO

[DiTBho]

Great!

I Also appreciate the Pulse DTR command! It's very useful for me since I use the DTR pulse everywhere, from 68hc11, 683xx, to ESP32.

Two years ago, I had to * hack * the Linux kernel / device / char / serial to "remove" the automatic DTR pulse function (I don't know if USB serial kernel modules have it), otherwise every time I ran Minicom, the kernel driver sent out a DTR pulse (because associated with the "fopen device") and my target received a reset pulse.

Very annoying, especially if you use a program to send the code to the target, and Minicom to communicate.

I ended up removing all the lines causing it. 

[lundmar]

I Also appreciate the Pulse DTR command! It's very useful for me since I use the DTR pulse everywhere, from 68hc11, 683xx, to ESP32.

In the latest tio version I have reworked the toggle and pulse feature so you can now toggle or pulse any serial line (DTR, RTS, CTS, DSR, DCD, RI) which will come handy if an embedded target reacts to other lines. However, not all serial device hardware or drivers support toggling all lines but tio will attempt toggle either way. The pulse duration for each line can now be configured.

The details are described here: https://github.com/tio/tio/releases/tag/v1.46

[lundmar]

tio v2.0 is now available here: https://github.com/tio/tio/releases/tag/v2.0

It includes a few new features which embedded people may find useful, such as RS-485 support and a new convenience feature which makes it easy to communicate with test instruments via serial port.

For example, to send a SCPI command and read response simply do:

Code: [Select]

$ echo "*IDN?" | tio /dev/ttyACM0 --response-wait
KORAD KD3305P V4.2 SN:32475045

It will take a while before the various Linux/BSD/Mac distributions catch up to v2.0 but until then the snap is readily available.

Also, tio v2.0 will soon be available as a MSYS2 package for Windows.

[lundmar]

tio v2.1 released - full release note available here: https://github.com/tio/tio/releases/tag/v2.1

[eti]

How does this differ from "screen" or "minicom"? Unless there's a significant benefit, why is there a need for it?

[lundmar]

How does this differ from "screen" or "minicom"? Unless there's a significant benefit, why is there a need for it?

Well, if you take a quick look at the feature list here https://github.com/tio/tio you will see a lot of features that neither screen nor minicom have.

That being said, screen is not a serial tool but a screen manager so you will end up short quickly if you are looking for serial related features and most annoyingly screen does not handle disconnecting serial ports. On the other end of the spectrum, minicom has a lot of classic serial/modem features but it offers it all via a somewhat cumbersome interface which will require you to do work to connect to even the simplest of serial ports (disable modem init, not easy to set flow control, gui menu navigation, etc.). Additionally, minicom uses the text graphical ncurses library which causes problems when you use it within screen managers such as screen or tmux. Compared, tio offers a more straightforward interface for both command-line and configuration file and it does not conflict with neither screen nor tmux because it does not use ncurses.

Also, Minicom haven't been maintained for 10 years now and it shows. As GlowInTheDark said in the Raspberry Pi forum:

"But the overriding point is that, as I've said many times in the past - whenever the name "minicom" is mentioned - I've never met a program that tried so hard to (and succeeded so well at) being hard to use."

He is right. With tio it will just work:

Code: [Select]

tio /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6009HU3-if00-port0

With minicom:

Code: [Select]

minicom -o -D /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6009HU3-if00-port0

After that you have to navigate deep into the minicom graphical menu to disable hardware flow control so that input will work with the rpi3 device. Hardware flow control can not be disabled via the command line. It is also silly you have to confirm to exit etc. In short, minicom requires too many key strokes to do anything. These are details that amount to the bad user experience that the forum user stressed.

Sometimes it is the little details that matter, especially if you use tools like these on the daily. You should give tio a try - the difference will be obvious.

[lundmar]

tio v2.2 released - a quick follow up release that adds support for shell auto-completion of sub-configuration names. A useful feature requested by a user.

https://github.com/tio/tio/releases/tag/v2.2

[lundmar]

tio v3.1 has been released - see https://github.com/tio/tio/releases for release notes.

It's been a while sine my last tio release announcement in this forum but a lot has happened to tio since then. Over the years tio has evolved from a very simple serial device tool into a really great command line serial device tool for embedded developers and hackers to connect to their embedded targets.

The recently released v3.x series offers scripting support and new ways to manage serial devices.

For example, to connect to the first new appearing serial device simply do:

$ tio --auto-connect new

Or to connect to the latest registered serial device:

$ tio --auto-connect latest

These auto connect strategies come handy when plugging/unplugging your embedded targets via USB serial ports.

To list available serial devices do:

$ tio --list
Device            TID     Uptime (s) Driver           Description
----------------- ---- ------------- ---------------- --------------------------
/dev/ttyS4        BaaB     19526.576 port             16550A UART
/dev/ttyS5        eV0Z     19525.845 port             16550A UART
/dev/ttyUSB1      bCC2      1023.274 ftdi_sio         TTL232R-3V3
/dev/ttyUSB0      SPpw       978.527 ftdi_sio         TTL232RG-VREG3V3
/dev/ttyACM0      i5q4         2.079 cdc_acm          ST-Link VCP Ctrl

By-id
--------------------------------------------------------------------------------
/dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTCHUV56-if00-port0
/dev/serial/by-id/usb-FTDI_TTL232RG-VREG3V3_FT1NELUB-if00-port0
/dev/serial/by-id/usb-STMicroelectronics_STLINK-V3_004900343438510234313939-if02

By-path
--------------------------------------------------------------------------------
/dev/serial/by-path/pci-0000:00:14.0-usb-0:8.1.3.1.4:1.0-port0
/dev/serial/by-path/pci-0000:00:14.0-usbv2-0:8.1.3.1.4:1.0-port0
/dev/serial/by-path/pci-0000:00:14.0-usbv2-0:6.4:1.0-port0
/dev/serial/by-path/pci-0000:00:14.0-usb-0:6.4:1.0-port0
/dev/serial/by-path/pci-0000:00:14.0-usbv2-0:6.3:1.2
/dev/serial/by-path/pci-0000:00:14.0-usb-0:6.3:1.2

Configuration profiles (/home/lundmar/.config/tio/config)
--------------------------------------------------------------------------------
rpi3                stm32               esp32               am64-evm
imx8mp-evk          nucleo-h743zi2      usb-devices

With tio you can define your own configuration profiles in the configuration file. Your typical configuration file may look like this:

[default]
baudrate = 115200
databits = 8
parity = none
stopbits = 1
color = 10

[rpi3]
device = /dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTGQVXBL-if00-port0
no-reconnect = true
log = true
log-file = rpi3.log
color = 11

[svf2]
device = /dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTCHUV56-if00-port0
baudrate = 9600
script = expect("login: "); send("root\n"); expect("Password: "); send("root\n")
color = 12

[esp32]
device = /dev/serial/by-id/usb-0403_6014-if00-port0
script = set{DTR=high,RTS=low}; msleep(100); set{DTR=low,RTS=high}; msleep(100); set{RTS=low}
script-run = once
color = 13

[usb-devices]
pattern = ^usb([0-9]*)
device = /dev/ttyUSB%m1
color = 14

To connect to one of the profiles simply do e.g.:

$ tio esp32

To connect to profile via its pattern do e.g.:

$ tio usb12

Which will match and connect to /dev/ttyUSB12.

Now it is also possible to set independent input and output modes. For example:

$ tio /dev/ttyUSB0 --output-mode hex16
[19:09:48.061] tio v3.1
[19:09:48.061] Press ctrl-t q to quit
[19:09:48.062] Connected to /dev/serial/by-id/usb-STMicroelectronics_STLINK-V3_004900343438510234313939-if02
2a 2a 2a 20 42 6f 6f 74 69 6e 67 20 5a 65 70 68
79 72 20 4f 53 20 62 75 69 6c 64 20 7a 65 70 68
79 72 2d 76 33 2e 34 2e 30 2d 33 39 31 35 2d 67
37 63 33 63 35 33 66 36 66 63 31 30 20 2a 2a 2a
0d 0a 6c 78 69 2d 67 70 69 62 20 64 72 69 76 65
72 20 74 65 73 74 20 76 30 2e 31 0d 0a
[19:09:53.382] Disconnected

Or you can output in hex mode with timeout based timestamps:

$ tio /dev/ttyUSB0 --output-mode hex --timestamp --timestamp-timeout 200
[19:11:06.133] tio v3.1
[19:11:06.133] Press ctrl-t q to quit
[19:11:06.133] Connected to /dev/serial/by-id/usb-STMicroelectronics_STLINK-V3_004900343438510234313939-if02
[19:11:11.033] 2a 2a 2a 20 42 6f 6f 74 69 6e 67 20
[19:11:13.633] 20 4f 53 20 62 75 69 6c
[19:11:14.104] 2a 2a 2a 20 42 6f 6f 74 69 6e 67 20 5a 65 70 68 79 72 20 4f 53 20 62 75 69
[19:11:21.263] 49 76 65 72 20 74 65 73 74 20 76 30 2e 31 0d 0a 2a 2a 2a 20 42 6f 6f 74 69 6e 67 20
[19:11:23.199] 65 73 74 20 76 30 2e 31 0d 0a

This way received data will get a new timestamp if no data has been received for 200 ms. This is very useful when debugging and inspecting e.g. protocol data from a device.

Give tio v3.1 a try - it may help make it easier to manage connections to your embedded devices.

See https://github.com/tio/tio for more details.