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.
If given together with **--noreset**, picocom will not reset the serial
port to it's original settings on exit, but it *will* clear the modem
control lines (typically DTR and RTS) to signal a modem hangup. Without
the **--noreset** option (explicitly given, or implied by extiting with
the "Quit" command) **--hangup** has no effect (without **--noreset**
picocom always clears the modem control lines on exit, anyway).
