Add a simple line response feature to make it possible to send e.g. a
command string to your serial device and easily receive and parse a line
response.
This is a convenience feature for simple request/response interaction
based on lines. For more advanced interaction the socket feature should
be used instead.
The line response feature is detailed via the following options:
-r, --response-wait
Wait for line response then quit. A line is considered any string ending
with either CR or NL character. If no line is received tio will quit
after response timeout.
Any tio text is automatically muted when piping a string to tio while in
response mode to make it easy to parse the response.
--response-timeout <ms>
Set timeout [ms] of line response (default: 100).
Example:
Sending a string (SCPI command) to a test instrument (Korad PSU) and
print line response:
$ echo "*IDN?" | tio /dev/ttyACM0 --response-wait
KORAD KD3305P V4.2 SN:32477045
When piping to tio it will automatically enter "non-interactive" mode
which means it will not react to any input key sequences but simple read
the input stream and write it to the tty device.
This also means that ctrl-t q can not be used to quit and so tio would
hang forever when used in non-interactive mode.
This change allows to send the standard termination signal by pressing
ctrl-c on tio in non-interactive mode to make it quit.
Make it possible to remap the prefix key (default: ctrl-t) by setting
the prefix-ctrl-key variable in the configuration file.
Allowed values are in the range a..z.
Example, to set the prefix key to ctrl-a simply do:
prefix-ctrl-key = a
Clean up so that only the following error related printing functions are
used: tio_error_printf(), tio_error_printf_silent(),
tio_warning_printf().
A session mode switch is introduced for error printing so that it will
print error messages with better formatting depending on in or out of
session.
Add support for a non interactive mode which allows other application to
pipe data to tio which then forwards the data to the connected serial
device.
Non ineractive means that tio does not react to interactive key commands
in the incoming stream. This allows users to pipe binary data directly
to the connected serial device.
Example use:
$ cat commands.txt | tio /dev/ttyUSB0
Allow user to add options on both sides of the provided config argument.
For example:
$ tio -b 9600 am64-evm -e
Before, tio only allowed adding arguments after the config argument.
Implemented as simple as possible by introducing two stage option parsing.
Rework the color option to support setting ANSI color code values
ranging from 0..255 or "none" for no color or "list" to print a list of
available ANSI colors codes.
Also, disables color when piping.
This feature allows an external program to inject output into and
listen to input from a serial port via a Unix domain socket (path
specified via the -S/--socket command line flag, or the socket
config file option) while tio is running. This is useful for ad-hoc
scripting of serial port interactions while still permitting manual
control. Since many serial devices (at least on Linux) get confused
when opened by multiple processes, and most commands do not know
how to correctly open a serial device, this allows a more convenient
usage model than directly writing to the device node from an external
program.
Any input from clients connected to the socket is sent on the serial
port as if entered at the terminal where tio is running (except that
ctrl-t sequences are not recognized), and any input from the serial
port is multiplexed to the terminal and all connected clients.
Sockets remain open while the serial port is disconnected, and writes
will block.
Example usage 1 (issue a command):
echo command | nc -UN /path/to/socket > /dev/null
Example usage 2 (use the expect command to script an interaction):
#!/usr/bin/expect -f
set timeout -1
log_user 0
spawn nc -UN /path/to/socket
set uart $spawn_id
send -i $uart "command1\n"
expect -i $uart "prompt> "
send -i $uart "command2\n"
expect -i $uart "prompt> "
Renamed to "tio" because it is shorter and this new name also more
precisely reflects what the program is - a simple TTY terminal I/O
application.
"tio" can be considered short for terminal I/O or TTY I/O or a
combination of the two, whichever you prefer.
Also, wanted to avoid naming conflicts with other projects.
