Re: serial, basic stuff
- Reply: Dag-Erling_Smørgrav : "Re: serial, basic stuff"
- In reply to: Dag-Erling_Smørgrav : "Re: serial, basic stuff"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 21 Apr 2024 09:06:38 UTC
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