If picocom is compiled *with* custom-baudrate support (USE_CUSTOM_BAUD)
for Linux, then it uses a new set of ioctl's (TCGETS2 vs TCGETS, etc) to
access the serial ports. This patch allows the custom baudrate support
to be disabled at runtime (without recompiling), and picocom to switch
to using the old ioctl's.
To disable custom baudrate support (and switch back to the "old" ioctls)
simply define the environment variable NO_CUSTOM_BAUD, before starting
picocom.
This applies only to Linux and, obviously, only when picocom has been
compiled with custom baudrate support (USE_CUSTOM_BAUD).
Call flock(fd, LOCK_UN) explicitly for managed file at term_exitfunc().
This should, normally, not be necessary. Normally, exiting the program
should take care of unlocking the file. Unfortuntelly, it has been
observed that, on some systems, exiting or closing an flock(2)'ed tty fd
has peculiar side effects (like not reseting the modem-control lines,
even if HUPCL is set).
For some systems (OSes, versions, architectures) custom-baudrate
support is enabled by default.
For others, support may work, but must be enabled by defining
USE_CUSTOM_BAUD in the Makefile
You can also disable custom baudrate support altogether (even for
systems where it's enabled by default), by defining NO_CUSTOM_BAUD in
the Makefile
Introduced `#define HAS_CUSTOM_BAUD` for platforms which have appropriate implementation.
Moving that `#if defined(__linux__) && defined(USE_CUSTOM_BAUD)` ... stuff out of `term.c`and put it to `termios2.h` / `custbaud_bsd.h` headers.
Moving that platform specific `#ifdefs` to the platform specific headers helps removing duplicate complex `#ifdef` constructs.
The both platform specific headers then do `#define HAS_CUSTOM_BAUD` to signal that custom baudrate support is implemented for the target platform.
I'd tested all above mentioned platforms with both USE_CUSTOM_BAUD unset and set to check if that refactoring don't raises unexpected issues.
- Made functions term_[raise/lower]_dtr() work *only* by using the
respective ioctl, not by setting the baudrate to 0. In case the ioctl
is not supported for a system, the functions fail. Function
term_pulse_dtr() still works by setting the baudrate to zero, if the
ioctl is not supported. As a result, for systems without support for
ioctls that set / clear the modem-control lines, DTR can only be
pulsed, not toggled.
- When using tcsetattr() to pulse the DTR line (i.e. on systems where
ioctls for setting / clearing the modem control lines are not
supported), set only the output speed to B0, not both input and output
speed.
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.
Picocom will always set the HUPCL control bit of the serial port,
according to the --noreset option. If --noreset is given, then
HUPCL for the port is cleared, and will remain so after exiting
picocom. If --noreset is *not* given, then HUPCL is set for the
port, and will remain so after exiting picocom. This is true, regardless
of the way picocom terminates (command, read zero-bytes from standard
input, killed by signal, etc), and regardless of the --noinit
option. If picocom exits with the "Quit" command, then --noreset is
assumed given. Almost always this is the most DWIM behavior.
Fixes#72
Some BSDs (and possibly other systems too) have no mark / space parity
support, and they don't define CMSPAR. Define a dummy (zero) CMSPAR in
these cases. If the user tries to set P_MARK or P_SPACE he will get
P_EVEN or P_ODD instead.
CMSPAR is defined by bits/termios.h, and glibc has two flavours of it: a
generic one and an architecture-specific one. glibc will install the
architecture-specific one if it exists, otherwise it will install the
generic one. Only Alpha, MIPS, PPC and Sparc have their own
bits/termios.h.
The generic bits/termios.h, as well as the Alpha, PPC and Sparc flavours
do define CMSPAR. However, the MIPS flavour does not define it.
Define CMSPAR to the value from the generic value, which is also the
value known to the Linux kernel for MIPS.
Patch inspired by:
http://git.buildroot.net/buildroot/commit/?id=78cd32631e959e04b1a2f18be7b0757e21482438
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
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.
In term_exitfunc() (which is called via atexit(3)) and
term_lib_init() (which resets ALL managed terminals to their original
attributes), if tcsetattr(3) fails with EINTR, try again.
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.
