term_flush() does not work with some drivers. If we try to drain or even
close the port while there are still data in it's output buffers *and*
flow-control is enabled, we may block forever. So we "fake" a flush, by
temporarily setting f/c to none, waiting for any data in the output
buffer to drain, and then reseting f/c to it's original setting.
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.
Added functions to read and decode settings (baudrate, databits, parity,
flow-control) from the "currtermios" structure of a managed port.
Added support for "mark" and "space" parity (CMSPAR bit).
After applying settings to a terminal device, in functions term_reset(),
term_replace(), and term_apply(), re-read the setting from the device in
order to update "currtermios", "nexttermios", and "origtermios" as
required. Do not assume that the settings applied are the ones
effectively set to the device (some of them may be ignored, or changed
by the kernel or the driver).
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.
