tio - A simple serial device I/O tool for linux - Page 1
Forum section: electronics / general

author: lundmar
author_rank: Frequent Contributor
timestamp: September 26, 2017, 05:46:58 pm
content: Hi guys,If you are using Linux and you are looking for a nice clean cut serial device tool to connect to your embedded target then you should give tio a try:http://tio.github.io"tio" is a simple serial device I/O tool which features a straightforward command-line and configuration file interface to easily connect to TTY devices for basic input/output.Consider it a simpler alternative to minicom/picocom/screen etc. with less focus on classic terminal/modem features and more focus on the needs of embedded developers and hackers.

author: hermit
author_rank: Frequent Contributor
timestamp: September 27, 2017, 06:29:58 pm
content: The older I get the more loath I am to start adding packages that aren't in the official repos. Things get very ugly very fast sometimes.

author: lundmar
author_rank: Frequent Contributor
timestamp: September 27, 2017, 07:36:43 pm
content: Quote from: hermit on September 27, 2017, 06:29:58 pmFYI - tio is included in the official Debian repos so if you are using Ubuntu/Debian you are in luck as you don't need to break your old habits.

author: hermit
author_rank: Frequent Contributor
timestamp: September 28, 2017, 02:40:29 am
content: I was posting a little more for 'bumps sake' to be honest.

author: Wirehead
author_rank: Regular Contributor
timestamp: September 28, 2017, 05:34:41 am
content: try to get it inhttps://brew.sh/as well.. Would be great on OSX as well, instead of the bloated old minicom..

author: lundmar
author_rank: Frequent Contributor
timestamp: September 28, 2017, 07:11:18 am
content: Quote from: Wirehead on September 28, 2017, 05:34:41 amWell, I don't use mac but I'm looking for package maintainer volunteers so ....

author: lundmar
author_rank: Frequent Contributor
timestamp: September 28, 2017, 08:55:25 am
content: Quote from: hermit on September 28, 2017, 02:40:29 amThere is nothing wrong in doing that

author: lundmar
author_rank: Frequent Contributor
timestamp: September 28, 2017, 11:04:20 am
content: Quote from: cleaningOut on September 28, 2017, 10:03:46 amActually, you could just typeCode:tio -b 115200 /dev/ttyUSB0And in case of 115200 8n1, even shorterCode:tio /dev/ttyUSB0Also, for users that use tmux it seems silly to start screen under a tmux session to access serial. Consider tmux + tio a more modern alternative to screen.I'm saying this as long time screen user myself.

author: HoracioDos
author_rank: Frequent Contributor
timestamp: September 28, 2017, 12:18:14 pm
content: Quote from: lundmar on September 26, 2017, 05:46:58 pmHiI had to compile it because it's not available for 16.04 LTS (Xenial Xerus). Size is very small (70.5 Kb). I love simple and tiny software. I'll try to test it today. How does it compare to screen command or why did you write it?Thanks!

author: lundmar
author_rank: Frequent Contributor
timestamp: September 28, 2017, 01:10:04 pm
content: Quote from: HoracioDos on September 28, 2017, 12:18:14 pmActually, if you strip the binary its only about 23 kbI'm sorry but binary packages for tio is only supported for recent/new Ubuntu/Debian distributions. Luckily it's easy to install manually, like you did, in case you need it.I'm a professional embedded developer and I use serial on linux almost on a daily basis to connect to various embedded boards and I've found myself wanting something more straightforward and simpler than existing tools like minicom, picocom, cutecom, putty, etc.. These tools all work fine but all suffer from somewhat cumbersome interfaces or includes features that i have never had a need for. So I decided to create tio as a small and simpler alternative that would fit my work flow better. I used to use screen for everything but now that I've switched permanently to using tmux I find it silly to use screen in tmux sessions just to do serial stuff. Also, tio includes various useful key commands and features such as an autoconnect mechanism that is very useful when you disconnect and connect your usb-serial cables.

author: HoracioDos
author_rank: Frequent Contributor
timestamp: September 28, 2017, 01:43:52 pm
content: Quote from: lundmar on September 28, 2017, 01:10:04 pmYeap! Only 23.4 KbQuote from: lundmar on September 28, 2017, 01:10:04 pmIt's not an issue. It's a good opportunity to learn how build .deb files. Always wanted to create a PPA to backport software like yours to LTS release.Quote from: lundmar on September 28, 2017, 01:10:04 pmThat's a good feature!

author: ebclr
author_rank: Super Contributor
timestamp: September 28, 2017, 01:52:51 pm
content: For windows guys, I highly recommend this amazing toolhttps://mobaxterm.mobatek.net/

author: lundmar
author_rank: Frequent Contributor
timestamp: September 28, 2017, 02:15:25 pm
content: Quote from: HoracioDos on September 28, 2017, 01:43:52 pmIf you do end up successfully creating a PPA for older distribution releases let me know. I'll be happy to put a reference to it onhttp://tio.github.io

author: hermit
author_rank: Frequent Contributor
timestamp: September 28, 2017, 04:13:45 pm
content: Quote from: lundmar on September 28, 2017, 08:55:25 amEspecially when it works.

author: lundmar
author_rank: Frequent Contributor
timestamp: September 28, 2017, 04:32:01 pm
content: Some kind folks from Debian pushed me some typo fixes so I just pushed a new release of tio.Who knew hexadecimal is not spelled hexidecimalSometimes my danish ancestry makes me spell wrong in subtle ways ha ha

author: hermit
author_rank: Frequent Contributor
timestamp: September 30, 2017, 02:31:59 am
content: Blame the spell checker.

author: lundmar
author_rank: Frequent Contributor
timestamp: September 30, 2017, 07:43:12 pm
content: FYI - I've just pushed a new release with some minor documentation updates here:http://tio.github.io

author: janoc
author_rank: Super Contributor
timestamp: September 30, 2017, 08:46:06 pm
content: Nice birthday gift for meI have been looking for a sane terminal emulator for MCU work for a while now.I have been mostly using minicom, but the BBS/modem features get in the way. Screen is not bad - except when the device loses connection and/or you need to quit it. I don't like having to use various Vulcan nerve pinch combos to get out of programs.There are a few more programs I have tried (cutecom, gtkterm, ssterm ...) but each has some warts that were driving me nuts.EDIT Bug in your build script:If I set prefix with configure --prefix=/opt/tio-1.23, make install has no business trying to write to /usr, that's a no-no:make: Entering directory '/home/janoc/Downloads/tio-1.23/src'/bin/mkdir -p '/opt/tio-1.23/bin'/bin/install -c tio '/opt/tio-1.23/bin'/bin/mkdir -p '/usr/share/bash-completion/completions'/bin/install -c -m 644 bash-completion/tio '/usr/share/bash-completion/completions'/bin/install: cannot create regular file '/usr/share/bash-completion/completions/tio': Permission deniedMakefile:408: recipe for target 'install-bashcompletionDATA' failedThat will also prevent getting the software properly packaged for many distros - building packages often redirects the install into a different directory.

author: lundmar
author_rank: Frequent Contributor
timestamp: September 30, 2017, 09:12:58 pm
content: Quote from: janoc on September 30, 2017, 08:46:06 pmYou pretty much sum up the very reasons why I created tio. I have had the same experience with various tty programs. In the end I ended up using screen but even that has its annoying quirks as you point out and it was driving me crazy so I decided to create tio - a simple no nonsense tty application that doesn't get in the way.I hope you will find tio useful as I do.Quote from: janoc on September 30, 2017, 08:46:06 pmThanks - I actually forgot about this issue but I will fix it in the next release. For now, to bypass it, you can use the '--with-bash-completion-dir=' configure option.

author: mib
author_rank: Contributor
timestamp: September 30, 2017, 09:38:44 pm
content: It's quite surprising how trivial a serial terminal program is if you remove all the extraneous stuff like modem support that no one uses anymore. I may actually switch to this from cu and screen if I can ever train my fingers to type a different command.A few suggestions:If you get a failure opening the tty do some simple checks and give a more useful error message. Check for idiots logged in as root, and give a suitable error - root isn't allowed to open serial ports by default for obvious (although now largely historical) reasons.Also check if the user is a member of the correct group to access the tty and provide a helpful message if not. You should really read the group for the tty file etc, etc. Those are two serial port access error I get asked about frequently.Make ctrl-t ctrl-t send a ctrl-t. That's a little easier to type reliably than taking a finger of ctrl.Linux does have an interface for selecting arbitrary baud rates in addition to the standard ones. It is very occasionally useful to be able to use them.Oh, and why the call the system("clear"); rather than just doing it inline? And the 'weird shit' with the status variable in the function? Other than that, nice clean code.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 01, 2017, 09:03:55 am
content: Quote from: mib on September 30, 2017, 09:38:44 pmI know the feeling - sometimes it can take a long time time to un-train those finger moves that we get so used toQuote from: mib on September 30, 2017, 09:38:44 pmI think at best I can add a warning when you run as root because I really don't want to dictate policy. If you want to run as root I won't prevent you. We also have to keep in mind that tio is actually being used on embedded devices with very simple filesystems where root is still the normal user state. Regarding tty groups, I don't want to walk down the road of maintaining checks for specific groups since those can vary across distributions and over time.Quote from: mib on September 30, 2017, 09:38:44 pmI know what you are saying but in this case I really prefer to keep the same type of key code sequence for all key commands to keep it consequential, simple and clean. Besides, the need for sending the raw ctrl-t key code is such a rare event that the vast majority of user fingers out there will never be affected by this non-standard Vulcan death gripQuote from: mib on September 30, 2017, 09:38:44 pmActually I did implement part of that feature but I didn't have a serial device that supported arbitrary baud rates so I couldn't test it. Either way, only a very few Linux serial device drivers support arbitrary baud rates so I ended up deciding against it and stick with what can be done through the standard c library API just to keep the code simple across all platforms (tio is also used on non-linux platforms). However, I might revisit that decision in the future if there becomes a big enough demand for it.Quote from: mib on September 30, 2017, 09:38:44 pmAdmittedly, it was a lazy quick way of doing it because I didn't find the correct ANSI/VT100 code for it at the time. Fixed inhttps://github.com/tio/tio/commit/07255c94b94f2b9e40766757450f5b73745a9086Quote from: mib on September 30, 2017, 09:38:44 pmThanks.Actually the 'status' thing is not weirdThink about it. A function returns a value that represents its status code. Hence I prefer 'status' over any of the less meaningful shorthand abbreviations 'r', 'ret', 'retval' etc.. Anyway, by the end of the day it's just a matter of coding style - generally I prefer not keeping everything super abbreviated just to save a few characters and in the process muddle the expressed semantics

author: nctnico
author_rank: Super Contributor
timestamp: October 01, 2017, 10:23:52 am
content: What I'm missing on Linux is Hyperterminal. What I want is a terminal program which allows to open/close/changing the serial port using a button/menu instead of shutting the entire program down/restarting it. tio seems more like Putty (which I hate because you have to shut it down to change anything). With the serial port closed you should be able to scroll back and forth through the history. Hyperterminal does all that so I'm still using it through a VM because there simply isn't a Linux alternative.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 01, 2017, 10:52:36 am
content: Quote from: nctnico on October 01, 2017, 10:23:52 amTio is a different beast, it's made for those commandline driven Linux hackers. What you are looking for is a GUI application and for that I can recommend to you: cutecom.

author: janoc
author_rank: Super Contributor
timestamp: October 01, 2017, 12:51:30 pm
content: Quote from: lundmar on October 01, 2017, 10:52:36 amOr GTKTerm or the venerable minicom.

author: nctnico
author_rank: Super Contributor
timestamp: October 01, 2017, 01:08:54 pm
content: Quote from: lundmar on October 01, 2017, 10:52:36 amI've tried all (including cutecom) but none are as good and complete as Hyperterminal even when taking into account how prone Hyperterminal is to crashing.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 01, 2017, 01:11:28 pm
content: @janoc , Btw. there is a new tio release which includes the fixed configure scripthttps://github.com/tio/tio/releases

author: Karel
author_rank: Super Contributor
timestamp: October 01, 2017, 01:46:19 pm
content: Code:guv@cetriolo:/data/karel/software/tio> git clone https://github.com/tio/tio.gitCloning into 'tio'...remote: Counting objects: 1143, done.remote: Compressing objects: 100% (73/73), done.remote: Total 1143 (delta 50), reused 62 (delta 22), pack-reused 1047Receiving objects: 100% (1143/1143), 200.50 KiB | 0 bytes/s, done.Resolving deltas: 100% (686/686), done.guv@cetriolo:/data/karel/software/tio> cd tio/guv@cetriolo:/data/karel/software/tio/tio> ./configurebash: ./configure: No such file or directoryguv@cetriolo:/data/karel/software/tio/tio> autoconfconfigure.ac:4: error: possibly undefined macro: AM_INIT_AUTOMAKEIf this token and others are legitimate, please use m4_pattern_allow.See the Autoconf documentation.configure.ac:5: error: possibly undefined macro: AM_SILENT_RULESconfigure.ac:25: error: possibly undefined macro: AM_CONDITIONALguv@cetriolo:/data/karel/software/tio/tio> makemake: *** No targets specified and no makefile found. Stop.guv@cetriolo:/data/karel/software/tio/tio> uname -aLinux cetriolo.suse 4.4.87-18.29-default #1 SMP Wed Sep 13 07:07:43 UTC 2017 (3e35b20) x86_64 x86_64 x86_64 GNU/Linuxguv@cetriolo:/data/karel/software/tio/tio> cat /etc/os-releaseNAME="openSUSE Leap"VERSION="42.2"ID=opensuseID_LIKE="suse"VERSION_ID="42.2"PRETTY_NAME="openSUSE Leap 42.2"ANSI_COLOR="0;32"CPE_NAME="cpe:/o:opensuse:leap:42.2"BUG_REPORT_URL="https://bugs.opensuse.org"HOME_URL="https://www.opensuse.org/"guv@cetriolo:/data/karel/software/tio/tio>

author: lundmar
author_rank: Frequent Contributor
timestamp: October 01, 2017, 02:00:49 pm
content: Quote from: Karel on October 01, 2017, 01:46:19 pmMay I suggest you download and use the official release tarball:https://github.com/tio/tio/releases/download/v1.24/tio-1.24.tar.xzIf you do insist on using the git source tree you will have to run the more or less conventional ./autogen.sh script first which will generate the configure script etc..

author: janoc
author_rank: Super Contributor
timestamp: October 01, 2017, 02:27:17 pm
content: Quote from: lundmar on October 01, 2017, 01:11:28 pmWorks a treat now, thanks!

author: Karel
author_rank: Super Contributor
timestamp: October 01, 2017, 02:28:59 pm
content: Quote from: lundmar on October 01, 2017, 02:00:49 pmI wasn't aware of that. Using the tarbal it compiles and runs fine on openSuse. Thanks!

author: mib
author_rank: Contributor
timestamp: October 01, 2017, 03:37:28 pm
content: Quote from: lundmar on October 01, 2017, 09:03:55 amI'm really only asking for better error messages on failure to open the serial port. When you get EACCESS, check the uid for root and report that. Checking the group is a little harder, you'd have to look at the group of the tty device you're trying to open. But it's not that hard. Certainly don't do a hard coded group name.Something like:"Failed to open tty: did you mean to run this as root"or"Failed to open tty: you need to be in the 'dialout' group"Rather than just the unhelpful "Permission denied" error. Which people usually respond to by running the same command again as root, and get the same error (for a different reason). Then I have to explain yet again that yes, it is meant to work like that, it's not a bug, I know, it's not like windows etc. etc.Quote from: lundmar on October 01, 2017, 09:03:55 amActually it's something I use quite a bit. I often have the situation where I'm connecting to a device through a serial console, then using it to connect to another serial console. Basically a management interface that allows access to a lot of other serial ports. Then I want to send a break to one of those ports. That's ctrl-t t b. And I often find I don't release the ctrl key quick enough. I'd add it as an extra, not in place of just using 't'.Quote from: lundmar on October 01, 2017, 09:03:55 amCalling a status variable 'status' isn't weird. Declaring it with attribute(unused), then assigning a value to it then never checking that value is weird. It just stood out as odd compared to the rest of the code. I see you've removed most of that now but the unused variable is still there.

author: donmr
author_rank: Regular Contributor
timestamp: October 01, 2017, 04:41:40 pm
content: My standard tool for this is miniterm.py which comes as part of the Python Serial package on Debian based distros.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 01, 2017, 05:27:48 pm
content: Quote from: mib on October 01, 2017, 03:37:28 pmWell, I guess we could raise the bar from the standard error messages we are used to. Nothing wrong in helping the user along. I'll add it to my TODO list.Quote from: mib on October 01, 2017, 03:37:28 pmOh, I got ya. Yeah, it was a stale code line - I just removed it. It escaped me because it was defined as unused to suppress an older version of gcc complaining unnecessarily because there was one code path that didn't use it.Btw. tio is fully open source so code contributions via github are welcome

author: lundmar
author_rank: Frequent Contributor
timestamp: October 01, 2017, 05:49:55 pm
content: Quote from: donmr on October 01, 2017, 04:41:40 pmI'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

author: janoc
author_rank: Super Contributor
timestamp: October 01, 2017, 07:35:49 pm
content: Quote from: lundmar on October 01, 2017, 05:49:55 pmIf you want your app to be first class citizen then you learn to use the tools properly and none of the above will be an issue.I guess you have never heard about "freezing", building binaries and/or installers with Python if you don't want to or can't rely on the platform Python installation. CPU overhead in a terminal app? Ehm ... You can write heavy computer vision stuff in Python - with real time performance. Just need to know how. And long winded error messages? I guess someone has never heard about error handling ...(writing commercial Python applications is part of my day job)

author: Monkeh
author_rank: Super Contributor
timestamp: October 01, 2017, 07:41:19 pm
content: Quote from: mib on September 30, 2017, 09:38:44 pmWhat dain bramage is this?

author: janoc
author_rank: Super Contributor
timestamp: October 01, 2017, 07:45:28 pm
content: Quote from: Monkeh on October 01, 2017, 07:41:19 pmThat's wrong, I think the author has been a bit confused. That would be really bad if the root user was unable to open a serial port. Root certainly is allowed to open any device they want (now whether it is a good idea is another story).Running the application as root is a bad idea for another reason, though - any security hole or bug in it means a potential system compromise.The proper way, at least in Linux, is to add the normal non-privileged user to the group allowed to use serial ports. E.g. on my machine it is the "dialout" group. For USB devices (the various UART-to-USB converters like FT232 and such) it may be required to add an UDEV rule granting the permissions to the currently logged in user. However, most popular desktop Linux distributions have this preconfigured and there is no need to hack anything like that for a regular user.

author: Monkeh
author_rank: Super Contributor
timestamp: October 01, 2017, 07:46:03 pm
content: Quote from: janoc on October 01, 2017, 07:45:28 pmOr he's using one very warped distro.

author: janoc
author_rank: Super Contributor
timestamp: October 01, 2017, 07:58:35 pm
content: Quote from: Monkeh on October 01, 2017, 07:46:03 pmThat would have to be explicitly forbidden by some security mechanism like GRSecurity or something - definitely not standard. Otherwise nobody could open the device - all demons like UDEV that grant permissions to the devices in Linux run as root ...

author: lundmar
author_rank: Frequent Contributor
timestamp: October 01, 2017, 09:14:32 pm
content: Quote from: janoc on October 01, 2017, 07:35:49 pmSure, I know how Python works but for tools like this there is simply no tolerance for binary installers - it must be compilable from source across various different platforms and this is where you hit all the well known issues with the variation of various Python installations. These issues becomes even worse in a cross compilation scenario. Sure, things has become more stable with Python 3.x but it is still a bit of a mess.Of course CPU overhead is not an issue in a terminal tool but from a general perspective pure Python will always be much slower than what can be done in C/C++, regardless of the Python code being scripted or compiled. Sure, Python can make do for some real time performance applications if your computer is fast enough. However, if you care about performance and need to make maximum use of your available CPU cycles and memory resources then Python is simply not a good option.And you are right, if you write proper error handling in Python then you won't see the nasty standard exception messages with long winded call stacks. Unfortunately, many Python script kiddies don't do that.And then there is the whole discussion on whether one thinks Python is a beautiful script language or not - personally I can't stand how it uses indentation to delimit code blocks but that is very much a personal opinion.

author: janoc
author_rank: Super Contributor
timestamp: October 02, 2017, 09:00:27 am
content: Quote from: lundmar on October 01, 2017, 09:14:32 pmIn Linux this only matters for distro packagers. If a regular user downloads a source package instead of precompiled one from their distro's repository, any dependencies are just "pip install xxx" away and then they should know how to build the software anyway.And for Windows and Mac? You have to be kidding. If you don't provide prebuilt binaries, nobody will bother because building software on Windows is such a pain, especially if there are other utilities fulfilling the same function available. You claim to want to be cross-platform compatible - and then you use the autoconf build system which is notoriously difficult to make work in Windows and pain in the butt on Mac (now, your code may not even work in Windows at all due to the API differences, but that's another subject). So your argument kinda flies out of the window there unless by "cross-platform" you mean the Microsoft kind of cross-platform - "it is cross-platform as long as the platform is Windows", only for Linux distributions instead.Quote from: lundmar on October 01, 2017, 09:14:32 pmThat argument can be trivially debunked too. What you don't realize is that in most cases Python acts only as a sort-of "glue", putting together calls to native C/C++/Fortran/GPU/etc. libraries. Of course, if your benchmark is how fast I can run a loop printing numbers, C is likely going to be faster. But that is not a realistic benchmark at all because that's not how Python is commonly used.For example, a well written Numpy numerical simulation code will run circles about a naive C/C++ implementation, because Numpy does things like code vectorization for you and has tons of heavily optimized algorithms behind the scenes. And I am not even talking about libraries like Numba, that generate optimized code using the llvm backend. You can see for yourself in this article:https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=enQuote from: lundmar on October 01, 2017, 09:14:32 pmTrue. However, we are talking about professional developers, not script kiddies? A "kiddy" developer will be hard pressed to do proper error handling in any language.Quote from: lundmar on October 01, 2017, 09:14:32 pmThat's pretty much a subjective issue. It used to bug me too but one gets used to it quickly because the indentation falls exactly where you would indent code in C/C++ as well, so you don't think about it after a while. Just don't mix spaces and tabs in one file, that's a pain in the butt.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 02, 2017, 01:05:53 pm
content: Quote from: janoc on October 02, 2017, 09:00:27 amWell, I understand you don't care much about the packager and end user experience. I'm not going to subject my package maintainers to the pains of maintaining any Python dependencies for my software. And end users having to pip install anything is causing them unnecessary pains not the mention the problems of which major python version they need to pick. I simply will not go down that road.Quote from: janoc on October 02, 2017, 09:00:27 amYes, my focus is mostly GNU/Linux systems and when I said cross platform I mean for example Linux vs BSD vs Hurd vs odd GNU distributions etc.. However, adding Windows to the mix does not make it easier to distribute applications with dependency on Python. In Windows you don't have package managers the same way we have in Linux so users end up having to sort out dependencies themselves and make sure to install the correct major version of Python to make things work and after that install any missing Python modules whatever they might be. Normal Windows users can run into all sorts of trouble with these things and some do. You can dismiss it if you like but that is reality for you.I would never choose such solution for a professional application but that is my opinion.Quote from: janoc on October 02, 2017, 09:00:27 amPlease notice that I said that _pure_ Python will always be much slower than C/C++. Yes, Python can make use of all sorts of precompiled support libraries/modules and then become faster that way but that, in my opinion, goes against the point of using a scripting language for writing an application. Then I would much rather write it all in C/C++ and not bother with any of the downsides of Python. Also, with Python binary modules you can run into the problem of them not being precompiled and available on various platforms and then you will have to compile and install them yourself. This of course does not apply to jit Python modules but here you pay a performance cost at runtime instead.One specific Numpy numerical calculation performance test is not very convincing and the use case for Numpy is very limited to scientific computing. There are numerous benchmarks available online that show how C/C++ is generally a factor or more faster in most scenarios. Even with clever jit technologies like Numba it is, in general, nowhere near as fast as C/C++. Sure, in some very specific benchmarks it can get close but in general use no. In the end Python/cython/numba/numpy etc. can't beat the fact that in C/C++ you have full control of cache lines and memory layout and with these mechanism you can achieve the best possible performance.I'm the kind of developer that cares about performance in any context and I'm not going to compromise my performance by writing my applications in Python and then have to depend on various Python modules to minimize the performance gap. That is my opinion, and in professional context I feel even stronger about this.Quote from: janoc on October 02, 2017, 09:00:27 amYet, many Python applications you find still crash with the default Python type stack trace - it's not pretty.Quote from: janoc on October 02, 2017, 09:00:27 amYes, very subjective. However, I really care about syntax and I find the lack of braces a poor language design choice. Also, never use tabs, only spacesAnyway, I think we simply have to agree to disagree on this topic. This thread is supposed to be all about tio

author: janoc
author_rank: Super Contributor
timestamp: October 02, 2017, 08:12:57 pm
content: Quote from: lundmar on October 02, 2017, 01:05:53 pmI am not asking you to - re-writing your terminal emulator in Python just for the sake of it would be obviously silly.I am not sure how did you determine that "I don't care about the packager or end user experience". Python packages and software are routinely packaged for distros with no issues. If the package has proper build using distutils, it is no problem whatsoever. E.g. my Mageia 6 has over 1000 Python packages listed in the repository, including major software like GnuRadio, the entire Numpy/Scipy stack, etc. Packaging Python applications is no different from packaging C/C++ - you have to handle dependencies there as well.And end-users arenotsupposed to build from source (even if it is not difficult at all), I think I have been rather explicit about it.Quote from: lundmar on October 02, 2017, 01:05:53 pmWhether I like it or not is beside the point (btw, I am a Linux user since 1994). If you deal with software for business, you will have to deal with Windows too, that's just a fact of life. I had to deal with various Unix systems over time, but yet have to see anyone using a Hurd. So it is cool you are thinking about portability to it (seriously, your Unix/Linux TTY apis are going to work on Hurd? Ehm ...)Just this week I had to actually prepare some software for a Mac, even. Some clients use even that.Re package management - pip & anaconda work just fine in Windows. Anyhow, you are missing the point again - you don't distribute your application as just source code for Windows but build a binary so that the user doesn't need to build it themselves. Yes, that is possible with Python. Then you have a normal, self-contained exe file.I am not dismissing anything, my point is that you are making a portability argument - and use an ancient build system that is pretty much making cross-platform (porting from one Linux to another Linux is not really cross-platform in my book) portability impossible. If you were using something like CMake it would be more believable.Quote from: janoc on October 02, 2017, 09:00:27 amWhat? That's a bit like saying using the standard C library goes against the point of using a C language for writing an application ... I didn't know that only writing everything from scratch is the acceptable form.Quote from: lundmar on October 02, 2017, 01:05:53 pmRight. So go tell that to folks like Google or Facebook that are building most of the deep-learning stuff using this. Or to financial analysts building investment plans using tools like Numpy & Pandas, etc. Or people doing any sort of data mining (practically everyone today - Numpy is free and much faster than Matlab which used to be the tool of choice).Quote from: lundmar on October 02, 2017, 01:05:53 pmThe problem is that what you are saying is relevant if you are writing close to the metal application (btw, I do wonder how you perform a "full control of cache lines" - you can at best ask for continuous memory allocation and certain alignment). None of this is at all relevant for an application which is spending 99.9% of its time waiting for a character to appear on a file descriptor - such as a terminal emulator. Or pretty much any application that has an UI.What matters a lot, though, is developer's productivity, because it is directly related to how costly (or not) is the project for the company. The entire time is money etc. thing. Once your job becomes writing complex algorithms that involve a lot of math, networking or anything else not covered by the standard C/C++ libraries you will start to appreciate stuff like a good set of libraries and an expressive programming language (be it Python, Julia, Haskell, C# or whatever else).Why do you think Java and C# became so popular? They have large runtimes, Java is terribly verbose and both are horrible for anything system level. However, both have enormous libraries of code available that make handling common tasks a breeze in them. Try to do e.g. any sensible (aka complex) networking in C/C++ without e.g. Boost or something like 0MQ or ACE and then do the same in C# only using standard libraries and you will see what I am talking about.I have nothing against C or C++ and I still write tons of code in them but treating them as a sort of holy grail that nothing ever comes close to is totally counterproductive. I could spend a week or two writing an embedded web server in C++ for an application. Or I can write 5 lines of Python and be done in 30 minutes and move on to solving actual problems that the client actually pays me money for.If I have learned something over my career, it was not becoming an expert in a programming language. A much more important skill is using the right tool for the job and keeping eyes open to new things instead of being stuck on incorrect assumptions because you have seen something in the past and didn't like it.Quote from: lundmar on October 02, 2017, 01:05:53 pmYes and a lot of C/C++ applications crash with the segmentation fault error or a bus error. That is even less pretty because nobody has any clue why. But perhaps it is more acceptable because users are used to applications just closing on them? That's really a silly point to make, IMO.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 03, 2017, 03:15:46 pm
content: Quote from: janoc on October 02, 2017, 08:12:57 pmOf course not - that would indeed be very silly.Quote from: janoc on October 02, 2017, 08:12:57 pmI'm not saying end users should build from source. I meant for package maintainers it is important and they will have to deal with missing or out of date dependencies. From a package maintainers point of view, having lived through the painful years of the migration from Python 2.x to 3.x, there have been many distribution and stability issues. But things hare clearly stabilized today with Python 3.x and that is good - I'm just still not a fan.Of course there are no issues for end users if distributed well. On Linux there are rarely issues if users make use of their systems native package manager as it will take care of all dependencies and these dependencies will be shared among applications so you can keep your package smallest possible in size. However, on Windows you will have to bundle all your dependencies or rely on eg. setuptools to download your python dependencies to make the end user experience a good one and even then you have to make the decision to bundle/download a full Python installation or rely on the end user installing the correct up-to-date version of Python/Anaconda (2.x vs 3.x). That's fine, it's just not the stuff I prefer to deal with when distributing applications.Quote from: janoc on October 02, 2017, 08:12:57 pmGreat, and I've been a Linux hacker since 1995 and have been working with embedded Linux professionally for many years but that is irrelevant for this discussion. The point is cross-platform can be more than just Windows vs. Linux vs Mac.. And yes, eventually I plan to make tio also work with GNU Hurd. Hurd is an interesting OS and good work is being put into it by the GNU people and others. It's microkernel design is superior to Linux in important ways but that is an entirely different discussion we don't need to engage here.Quote from: janoc on October 02, 2017, 08:12:57 pmYou keep misrepresenting what I'm saying. Of course you don't distribute source code to end users, especially not on Windows. And yes, for Windows, I certainly prefer to distribute applications as a self-contained exe with no external dependencies. Of course I know, you can do that for Python applications too but as I mentioned above you will have to decide whether the end user will have to bother with installing Python 2.x or 3.x as a separate installation or if you will bundle a potentially duplicate installed Python which will increase installation size or you will have to compile all your python into executable so that it does not depend on Python at runtime. I'm simply not a fan of any of these mechanisms.Quote from: janoc on October 02, 2017, 08:12:57 pmNo, you are missing my point. What I'm saying is that if I'm going to write a professional self-contained application with performance in mind then my preferred choice is to write it in eg. C/C++ from the get go and reap the performance gains immediately across my entire application. And of course never write everything from scratch. There are so many high quality and well abstracted C/C++ libraries available out there that even doing complex stuff has become trivial. Sure, it takes a little longer to write a C/C++ application but not as much as people think. This is my professional preference. Of course, if I'm putting something together quickly and performance is not first priority then yes I use Python or whatever other higher level language that fits the job.Quote from: janoc on October 02, 2017, 08:12:57 pmAnd I think that is great - it's an improvement. It used to be that scientists preferred using good ol' antiquated Matlab in combination with optimized computational libraries typically written in C/C++ to gain better performance to this way avoid waiting weeks for their computations. Now, instead, they get to use Python, Lua etc. in combination with optimized computational libraries typically written in C/C++ to gain better performance. I mean, it is no coincidence that the core of Numpy is written in C.Quote from: janoc on October 02, 2017, 08:12:57 pmNot full control in the literal sense of course, but as good as it gets. There are many more tricks you can do with the C/C++ compiler, linker, and language constructs to make sure your most performance critical code can align and fit within the cache lines of your CPU and to maximize the chance it will be picked up by the cache mechanisms. Even moving code blocks around in the memory layout to trick the cache prefetcher includes surprising gains. It's almost an art form. This is one of the reasons optimized libraries are often written in C/C++.Quote from: janoc on October 02, 2017, 08:12:57 pmI'm not saying C/C++ is the one and only way. I think you should pick the right tool for the right job and I think we agree on that point. However, in case of C++ there are so many good libraries and UI toolkits available that helps a lot to speed up development to the point where you can justify its use.In C++ it does not really matter that much if you use Boost or standard libraries. Fun fact, stuff conceived in Boost often end up in the standard libraries.Quote from: janoc on October 02, 2017, 08:12:57 pmAgain we agree, the right tool for the right job. However, I will say that becoming an expert in a specific language does carry a lot of merit for many jobs but I think it is more important to simply be an expert programmer that is familiar with various programming paradigms and techniques because that makes it possible to quickly adapt and use new languages fitting the job at hand.Quote from: janoc on October 02, 2017, 08:12:57 pmIt does require some level of discipline to introduce sensible error handling in either language. I just wish Python wasn't so noisy in its default verbosity.

author: HoracioDos
author_rank: Frequent Contributor
timestamp: October 07, 2017, 01:11:15 pm
content: Hi.Until now I was used to cu and screen. Now I'm trying Tio. For Gui: CuteCom, Moserial and CoolTerm work fine. For terminal: Tilix

author: lundmar
author_rank: Frequent Contributor
timestamp: October 07, 2017, 08:04:13 pm
content: Quote from: HoracioDos on October 07, 2017, 01:11:15 pmYou have mentioned that your current GNU/Linux distribution is Mint.I've talked to the Debian package maintainer of tio and he will soon upgrade it to latest version. Since Mint is a Debian derivative you should soon get access to the latest version via your package manager.

author: HoracioDos
author_rank: Frequent Contributor
timestamp: October 07, 2017, 08:38:09 pm
content: Quote from: lundmar on October 07, 2017, 08:04:13 pmDouble. Mint has a debian edition.Quote from: lundmar on October 07, 2017, 08:04:13 pmMint is an Ubuntu derivative mainly. Ubuntu and Debian package maintainers teams and repos are different. I don't know how they talk to each other.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 07, 2017, 08:57:38 pm
content: Quote from: HoracioDos on October 07, 2017, 08:38:09 pmTrue, they are not exactly the same. Mint is a derivative of Ubuntu. Ubuntu is a derivative of Debian. They all pick and choose and customize as they need. That being said, they are all generally the same - mainly a Debian derivative. Changes/additions in Debian usually trickle down to the other derivatives after some time.

author: radar_macgyver
author_rank: Frequent Contributor
timestamp: October 07, 2017, 09:18:04 pm
content: Thanks for this, handling USB to serial adapter disconnects smoothly is an option that helps a lot when dealing with embedded targets that need reboots.Quote from: nctnico on October 01, 2017, 10:23:52 amI've used picocom in the past, and when you quit, you can use your terminal emulator's scrollback buffer to view what came out of the serial port. I'm guessing tio does the same.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 07, 2017, 11:05:23 pm
content: Quote from: radar_macgyver on October 07, 2017, 09:18:04 pmI think it is a useful feature, especially if you are connecting/disconnecting various boards during the day in your work or hacking sessions. You simply start tio for your serial device and leave it there for the rest of the day watching it automatically connect and reconnect. Most other terminal tools require some sort of restart for this scenario.NOTE: Make sure to use a serial tty device found in /dev/serial/by-id/ otherwise it might pop up as a different tty device file when reconnected and then tio will not find it again.Quote from: radar_macgyver on October 07, 2017, 09:18:04 pmAbsolutely, tio is intentionally made so it does not get in your way by messing with your terminal using fancy ncurses features and buffers etc.. When you quit tio you can use your terminals scroll buffer to view all your history only limited by your terminals scroll buffer size.If one does not want to use scroll buffers then tio also supports logging to a file.Btw, Mac Gyver forever!

author: lundmar
author_rank: Frequent Contributor
timestamp: October 16, 2017, 08:01:54 am
content: 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

author: lundmar
author_rank: Frequent Contributor
timestamp: March 09, 2018, 06:22:31 pm
content: There have been quite a few tio releases since this thread was last active:https://github.com/tio/tio/releasesNew 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:$ snap install tio

author: lundmar
author_rank: Frequent Contributor
timestamp: June 12, 2022, 03:17:29 pm
content: 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/releasesRecently 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: June 17, 2022, 10:28:34 am
content: tio v1.40 has been released.

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 17, 2022, 12:50:59 pm
content: Quote from: lundmar on October 01, 2017, 05:49:55 pmA 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/110I 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: June 17, 2022, 03:11:03 pm
content: Quote from: NiHaoMike on June 17, 2022, 12:50:59 pmYes, 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.

author: janoc
author_rank: Super Contributor
timestamp: June 17, 2022, 05:52:50 pm
content: NiHaoMike, you do realize you started to argue about a 5 years old post, right?

author: lundmar
author_rank: Frequent Contributor
timestamp: July 04, 2022, 10:25:40 pm
content: tio v1.42 has been released.Seehttps://github.com/tio/tio/releases

author: Benta
author_rank: Super Contributor
timestamp: July 04, 2022, 11:59:17 pm
content: Yes, tio is wonderful. And?

author: eti
author_rank: Super Contributor
timestamp: July 05, 2022, 12:17:23 am
content: "screen", "minicom" etc suffice just well and good. This is the issue with Linux - too many ways to achieve exactly the same thing.

author: lundmar
author_rank: Frequent Contributor
timestamp: July 05, 2022, 10:30:56 am
content: Quote from: eti on July 05, 2022, 12:17:23 am"putty", "hyperterminal" etc suffice just well and good. This is the issue with Windows - too many ways to achieve exactly the same thing.

author: lundmar
author_rank: Frequent Contributor
timestamp: July 09, 2022, 02:27:49 pm
content: tio v1.43 releasedSeehttps://github.com/tio/tio/releases/tag/v1.43This 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: July 17, 2022, 09:56:12 am
content: 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

author: DiTBho
author_rank: Super Contributor
timestamp: July 17, 2022, 10:30:27 am
content: Not bad at all, I have already prepared an Overlay for stage4-2008 MIPS32LE for my router.tiosources don't have special requirements, that's nice to see

author: DiTBho
author_rank: Super Contributor
timestamp: July 17, 2022, 10:32:28 am
content: Quote from: lundmar on June 12, 2022, 03:17:29 pmyup, this is helpful for me

author: lundmar
author_rank: Frequent Contributor
timestamp: July 17, 2022, 10:56:09 am
content: Quote from: DiTBho on July 17, 2022, 10:32:28 amYeah, 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 inhttps://github.com/tio/tio/blob/master/TODO

author: DiTBho
author_rank: Super Contributor
timestamp: July 17, 2022, 04:47:51 pm
content: 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: July 19, 2022, 04:03:22 pm
content: Quote from: DiTBho on July 17, 2022, 04:47:51 pmIn 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

author: lundmar
author_rank: Frequent Contributor
timestamp: September 11, 2022, 12:55:38 pm
content: tio v2.0 is now available here:https://github.com/tio/tio/releases/tag/v2.0It 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:$ echo "*IDN?" | tio /dev/ttyACM0 --response-waitKORAD KD3305P V4.2 SN:32475045It 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 14, 2022, 11:10:44 pm
content: tio v2.1 released - full release note available here:https://github.com/tio/tio/releases/tag/v2.1

author: eti
author_rank: Super Contributor
timestamp: October 16, 2022, 10:43:33 pm
content: How does this differ from "screen" or "minicom"? Unless there's a significant benefit, why is there a need for it?

author: lundmar
author_rank: Frequent Contributor
timestamp: October 17, 2022, 10:15:16 am
content: Quote from: eti on October 16, 2022, 10:43:33 pmWell, if you take a quick look at the feature list herehttps://github.com/tio/tioyou 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:QuoteHe is right. With tio it will just work:Code:tio /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6009HU3-if00-port0With minicom:Code:minicom -o -D /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A6009HU3-if00-port0After 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.

author: lundmar
author_rank: Frequent Contributor
timestamp: October 19, 2022, 08:24:47 am
content: 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

author: lundmar
author_rank: Frequent Contributor
timestamp: May 03, 2024, 05:29:42 pm
content: tio v3.1 has been released - seehttps://github.com/tio/tio/releasesfor 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 newOr to connect to the latest registered serial device:$ tio --auto-connect latestThese auto connect strategies come handy when plugging/unplugging your embedded targets via USB serial ports.To list available serial devices do:$ tio --listDevice 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 CtrlBy-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-if02By-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.2Configuration profiles (/home/lundmar/.config/tio/config)--------------------------------------------------------------------------------rpi3 stm32 esp32 am64-evmimx8mp-evk nucleo-h743zi2 usb-devicesWith tio you can define your own configuration profiles in the configuration file. Your typical configuration file may look like this:baudrate = 115200databits = 8parity = nonestopbits = 1color = 10device = /dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTGQVXBL-if00-port0no-reconnect = truelog = truelog-file = rpi3.logcolor = 11device = /dev/serial/by-id/usb-FTDI_TTL232R-3V3_FTCHUV56-if00-port0baudrate = 9600script = expect("login: "); send("root\n"); expect("Password: "); send("root\n")color = 12device = /dev/serial/by-id/usb-0403_6014-if00-port0script = set{DTR=high,RTS=low}; msleep(100); set{DTR=low,RTS=high}; msleep(100); set{RTS=low}script-run = oncecolor = 13[usb-devices]pattern = ^usb([0-9]*)device = /dev/ttyUSB%m1color = 14To connect to one of the profiles simply do e.g.:$ tio esp32To connect to profile via its pattern do e.g.:$ tio usb12Which 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-if022a 2a 2a 20 42 6f 6f 74 69 6e 67 20 5a 65 70 6879 72 20 4f 53 20 62 75 69 6c 64 20 7a 65 70 6879 72 2d 76 33 2e 34 2e 30 2d 33 39 31 35 2d 6737 63 33 63 35 33 66 36 66 63 31 30 20 2a 2a 2a0d 0a 6c 78 69 2d 67 70 69 62 20 64 72 69 76 6572 20 74 65 73 74 20 76 30 2e 31 0d 0a[19:09:53.382] DisconnectedOr 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 0aThis 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.Seehttps://github.com/tio/tiofor more details.