This looks pretty sensible. I spent a lot of time fighting serial ports on
early PCs and Apple IIs back in the eighties, and you seem to be covering most
of the usual problems. You should probably:
Make hardware flow control compulsory, since software flow control will not be
practical, and with no flow control things are unlikely to work in any useful
way.
Decide how high a baud rate you want to permit: 115.2Kbps is often the
practical limit on genuine serial cables.
Create default settings for client and server that are compatible, so that most
people don't have to fiddle with them.
I have not used LLDB over any kind of wire, but I have used GDB that way, over
USB between Linux and Android. That sometimes needs to download debug data or
binaries from the device to the Linux machine. Over USB 2.0 or faster, this
isn't a problem, but over 115.2kbps serial, it could take quite a while. You
should consider giving the user a chance to avoid locking up their session
while that happens.
Best,
John
> -Original Message-
> From: lldb-dev On Behalf Of Michal Górny
> via lldb-dev
> Sent: 05 October 2021 10:21
> To: lldb-dev@lists.llvm.org
> Subject: [lldb-dev] Serial port support in LLDB
>
> Hi, everyone.
>
> I'm working on improving LLDB's feature parity with GDB. As part of this, I'm
> working on bettering LLDB's serial port support. Since serial ports are not
> that common these days, I've been asked to explain a bit what I'd like to do.
>
>
> At this point, LLDB (client) has minimal support for serial port debugging.
> You
> can use a command like:
>
> process connect file:///dev/ttyS0
>
> to connect via the GDB Remote Protocol over a serial port. However, the
> client hardcodes serial transmission parameters (I'll explain below). I
> haven't
> been able to find an option to bind lldb-server to a serial port.
>
> I'd like to fix the both limitations, i.e. make it possible to configure
> serial port
> parameters and add support for serial port in lldb-server.
>
>
> The RS-232 standard is quite open ended, so I'm going to focus on 8250-
> compatible serial port with DB-9 connector below (i.e. the kind found in
> home PCs). However, I'm going to skip the gory details and just focus on the
> high-level problem.
>
> The exact protocol used to transmit data over the serial port is configurable
> to some degree. However, there is no support for autoconfiguration, so
> both ends have to be configured the same.
> The synchronization support is also minimal.
>
> The important hardware parameters that can be configured are:
>
> - baud rate, i.e. data transmission speed that implies the sampling
> rate. The higher the baud rate, the shorter individual bits are
> in the transmitted signal. If baud rate is missynced, then
> the receiver will get wrong bit sequences.
>
> - number of data bits (5-8) in the frame, lower values meaning that
> the characters sent are being truncated. For binary data transfers,
> 8 data bits must be used.
>
> - parity used to verify frame correctness. The parity bit is optional,
> and can be configured to use odd or even parity. Additionally, Linux
> supports sending constant 0 or 1 as parity bit.
>
> - number of stop bits (1 or 1.5/2) in the frame. The use of more than
> one stop bit is apparently a relict that was supposed to give
> the receiver more time for processing. I think this one isn't
> strictly necessary nowadays.
>
> - flow control (none, software, hardware). This is basically used by
> the receiver to inform the sender that it's got its buffer full
> and the sender must stop transmitting. Software flow control used
> in-band signaling, so it's not suitable for binary protocols.
> Hardware flow control uses control lines.
>
> Of course, there is more to serial ports than just that but for LLDB's
> purposes,
> this should be sufficient.
>
>
> The POSIX and win32 API for serial ports are quite similar in design.
> In the POSIX API, you have to open a character device corresponding to the
> serial port, while in win32 API a special path \\.\COMn. In both cases, reads
> and writes effect the transmission. Both systems also have a dedicated API
> to configure the serial transmission parameters (ioctl/termios on POSIX [1],
> DCB on win32 [2]). Note that I haven't tried the win32 API, just looked it
> up.
>
> The POSIX serial ports are a teletype (tty) devices just like virtual consoles
> used by terminal emulators. This makes it easy to use a serial port as a
> remote terminal for other system. This also adds a bunch of configuration
> options related to input/output processing and special behavior. When a
> serial port is going to be used for non-console purposes, these flags have to
> be disabled (i.e. the tty is set to 'raw'
> mode).
>
>
> The rough idea is that after opening the serial port, we need to set its
> parameters to match the other end. For this to work, I need to replace
> LLDB's hardwired
