Wording might become a bit confusing, so I’m going to make a distinction here before I go on…
Every serial UART is a piece of hardware. A console is a text mode login shell for end users to talk to the operating system (a “login” is key). A serial console is a console (keyboard input and display of output) over a UART. When I say serial console I mean much more than when I say UART. If I say a serial console program, I’m talking about a program which can talk to a serial UART by connecting the keyboard to write to the UART and having an output area to show what the UART has sent to you…but whether or not this is a login session is actually unrelated. You need a serial console program (like gtkterm) to talk to a serial login, but a serial console program can also be used with more than a serial login…two people could type remote messages to each other without the shell interpreting it as Linux commands. An old fashioned telephone modem could serialize data, turn it into tones at one end, and then turn tones back into characters at the other end (each end has a UART). Loopback is you talking to yourself, serial console login is you talking to the operating system. J17 (/dev/ttyTHS2) is wide open and not bound to anything…it is free to use.
Don’t use “/dev/ttyS0” or “/dev/ttyTHS0” (same hardware, different driver): This already has software talking to it. You could connect another serial UART to the J21 TX and RX and talk to the TX2 as if you are logged in locally there. You’d use a serial UART on your host PC, not locally.
There are three issues to consider:
In terms of permissions, if your user name is “ubuntu”, then you can add a supplemental membership for group “dialout” to user “ubuntu” via this:
sudo usermod <b>-a -G dialout</b> ubuntu
Although there might conceivably be a reason to add a developer to group “tty”, in this case such an addition would be a mistake sense you don’t want to randomly send commands to a UART which is already bound to a function.
Incidentally, using the GPU requires being root or being in group “video”. Regular users using CUDA would be added in the same way by making those users a member of group “video”. To see current members:
grep video /etc/group
Note that an Arduino is no different than a serial console program, except it isn’t someone typing messages…some program is running. If the previous three conditions are met, then communications should work. Sometimes people don’t realize the wiring matters though, and long wires, lack of twisted pair and shielding, so on, can cause failure (short wires typically don’t care, but I like using ethernet cable for anything more than a few inches since it is quality twisted pair). Above speed 115200 you will need two stop bits, not one. I’m not sure if the Arduino would allow setting two stop bits or not.
When you echo correctly in loopback mode, then you validate the port is operating correctly at those settings, and if another UART is mated to the connector at the same settings, then it should work. The other UART would have to also use the same 3.3V TTL logic level…other levels might cause damage or simply not work. Generally you won’t get damage by using 3.3V with 1.8V, but it also won’t work.
Any C program on the TX2 would open “/dev/ttyTHS2” for read/write. Any special settings would be via IOCTL calls. The loopback testing verifies if the port is able to operate with those specific settings.
C programming examples for a serial UART are very common on google searches since UARTs have been around longer than the PC. Just a general search:
This is one I’ve used before:
You’ll find mention of different tools for setting a serial port speed, but mostly you won’t need to use those. You’d use those to set values on command line from boot software, but your C program will probably be setting things up instead (e.g., speed). Note that some of those tools won’t show what you expect, and you have to make a distinction that UARTs are not plug-n-play devices…there is no way for drivers to actually query most serial UARTs for their settings. When you use a command to make or query a setting, then you are asking the driver what it is doing, and if the UART doesn’t work with those settings, then the driver won’t know. Loopback tests if the driver actually works with those settings. The command line parameters used with gtkterm result in IOCTL calls to set the port settings prior to data being sent/received. Your program can make similar calls.
There are other serial UARTs, but some may be bound to a function, e.g., talking to the bluetooth or routed to the M.2 slot. Others may not be used, but also might not have any kind of external wiring available without using a different carrier board. I couldn’t tell you what all of the other UARTs are connecting to.