Don't read a single byte at a time from the serial port. Read
multiple (up to TTY_RD_SZ = 128) bytes with a single read(2) call. Also
write multiple bytes to the terminal (STO) with a single write(2) call.
In all cases the pattern was tcflush(fd, TCIOFLUSH) followed by
tcsetattr(fd, TCSAFLUSH, ...). The problem was that, for some drivers,
tcflush() was apparently doing nothing, so tcsetattr() might hang
forever waiting for the output buffers to drain (possible if flow
control is enabled). Replaced tcflush(fd, TCSAFLUSH), with tcsetattr(fd,
TCSANOW) which, after a tcflush() should anyway be equivalent.
If the requested baudrate is not a custom one (i.e. does not match one
of the Bxxx macros), then the cfsetospeed_custom() and
cfsetispeed_custom() are called to configure the "nexttermios" structure
with the requested non-standard baudrate. Same thing for reading the
baudrate: If cfgetospeed() and / or cfgetispeed() return a value that is
not among the Bxxx macros, cfgetospeed_custom() and cfgetispeed_custom()
are called, to read (and decode) the non-standard baudrate from the
"nexttermios" structure.
Currently the cf[set|get][i|o]speed_custom functions are only
implemented for Linux, and work only with non-ancient kernels (>2.6). So
in effect, custom baud-rate support is currently only supported for
Linux.
Function fd_readline() now displays non-printable and non-ascii
characters as hex codes (e.g \x12). These characters can be deleted
correctly using the [Backspace] or [DEL] key. This is applicable only
when picocom is compiled without linenoise support.
Picocom no longer uses /bin/sh to run external commands for
file-transfer operations. Parsing the command line and spliting it into
arguments is now performed internally by picocom, using quoting rules
very similar to those of the Unix shell. Hopefully, this makes it
impossible to inject shell-commands when supplying filenames or
extra arguments to the send- and receive-file commands.
Recent GCC / GLIBC combinations warn you when you call write(2) without
checking its return value. Casting the function to void, doesn't help
either. See: warn_unused_result.
If you define a large TTY_Q_SZ (which is quite useful for reliable
copy/paste) then write(2) would send large chucks to the tty in a single
gulp. On slow (very slow) baud rates this would make the tty fd buffers
take forever to drain on exit or when tcsetattrs() is
called. Unfortunatelly calling tcflush() doesn't really help (not on
linux, not with my serial driver).
So we limit the amount of data write(2) can send to the tty on a single
call, based on the port's baud rate (current setting baud-rate / 10
bytes, i.e. approx. one second worth of data). On my system (Linux) this
seems to be adequate: the fd does not become write-ready until most of
the data are sent through, so no huge buffers (with respect to the
baud-rate) are not accumulated and they don't take forever to drain.
- Don't call exit(3) from signal handler. Set a flag and let loop()
check it.
- Don't use system(3). Still uses /bin/sh to run the external
command. This should be fixed.
- Better signal disposition preparation for child process.
- Whenever a port setting is changed (baud-rate, parity, flow-control,
etc) by a command, the serial port attributes are re-read, and if
different from the requested value, both values are displayed (first
the requested, then the actual in parenthesis).
- The show-status command ([C-v]) also re-reads the actual terminal
attributes and displays both: the requested values and the actual
terminal settings (if they differ). This way [C-v] is able to "see"
changes made to the port outside of picocom (or changes made from
within picocom but silently ignored by the serial port driver---which
happens).
DEL key now behaves like backspace when entering filenames for "send"
and "receive" commands. Applicable only if picocom is compiled without
linenoise support.
http://code.google.com/p/picocom/issues/detail?id=25
This should also fix issue:
http://code.google.com/p/picocom/issues/detail?id=17
The following baud-rates are now supported:
Standard:
0, 50, 75, 110, 134, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600,
19200, 38400, 57600, 115200,
HIGH_BAUD:
230400, 460800, 500000, 576000, 921600, 1000000, 1152000, 1500000,
2000000, 2500000, 3000000, 3500000, 4000000,
Now every baudrate above 115200 is compiled-in only if the respective
macros are defined in the system header files. This should allow
picocom with HIGH_BAUD support to compile cleanly for more systems.
and path completion when entering filenames for receive- and send-
file operations. Support can be compiled-out if you wish. See Makefile.
- When entering a filename for receive- or send- file operations,
pressing C-c cancels the operation.
This works regardless of whether linenoise support (see above) has
been compiled in or not
- Use debian's xmltoman to convert manual page form xml to man.
