Re: serial, basic stuff

On 2024-04-20 21:55:49 (+0200), Dag-Erling Smørgrav wrote:
> Jon Clausen <freebsd-questions@ymmv.dk> writes:
> > In practical terms, for my use case, as described above, should I be
> > using the tty* or the cua* device to initiate the connection?
> 
> cu / tip / screen / minicom whatever on the client side uses /dev/cuaU*,
> getty on the server uses /dev/ttyU*.

Thanks - I did suspect this, but it's not obvious (at least to me) even
after going through https://docs.freebsd.org/en/books/handbook/serialcomms/


In the meantime I realised that there is at least one complication with my
idea of "the simple setup" (where jh05:port0 <-> jh06:port0)

On both systems getty is already 'listening' on ttyu0.

So connecting those, gets me this:

root@jh05:~ # cu -l /dev/cuau0 -s 115200
/dev/cuau0: Device busy
link down
root@jh05:~ #

`screen` does seem to connect, there's just a lot of stuff flying through
the terminal. Scrolling back, however, reveals that it is actually the login
prompt from jh05 itself.


So I decided to move the experimentations to the onboard 'header' ports
instead.

Pinout is:
1: 3V
2: TX
3: RX
4: GND
5: 5V

dmesg has the same on both systems:
root@jh05:~ # dmesg | grep uart
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
root@jh05:~ #

stty says that cuau* settings are identical, on both ports, on both machines
stty says that ttyu* settings are identical, on both ports, on both machines


I thought it might be as easy as:
* connect the ports (pins 2/3 crossed, GND connected for good measure)
* run getty on ttyu1 on one system
* connect using cuau1 on the other system

...it wasn't.

root@jh06:~ # /usr/libexec/getty 3wire ttyu1
root@jh06:~ # ps a | grep ttyu
1314 u0  Is+  0:00.00 /usr/libexec/getty 3wire ttyu0
1342 u1  Is+  0:00.00 /usr/libexec/getty 3wire ttyu1
1362  0  S+   0:00.00 grep ttyu
root@jh06:~ #

root@jh05:~ # cu -l /dev/cuau1 -s 9600
Connected


As this stage, the terminal just hangs there. Neither system seems to be
doing anything


So:
I presume that this is where I should be looking into the flags/parameters.
At least it seems fairly obvious that the lack of connections for the
hardware handshakes/clear to send/receive/etc might call for some
modification to the defaults:

root@jh05:~ # stty -a -f /dev/cuau1.init
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
	-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
	brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
	-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
	lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
	status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
root@jh05:~ #

root@jh06:~ # stty -a -f /dev/ttyu1.init
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
	-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
	-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
	brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
	-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
	eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
	lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
	status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
root@jh06:~ #


I thought turning off 'rtsdtr' might help, but

root@jh06:~ # stty -f /dev/ttyu1.init -rtsdtr

followed by restarting getty on the device didn't make any apparent
difference.


So it appears I could still use some help understanding this...

br
/jon

-- 
YMMV