Serial communications is just talking to the right “/dev/WhateverSerialDevice#”, e.g., serial console is “/dev/ttyS0”, directly attached console during boot is “/dev/tty0” (these are assigned in “/boot/extlinux/extlinux.conf” as an argument passed to the kernel). Each “/dev” tty file is really the interface to a driver. It just happens that by default “/dev/ttyTHS2” is the driver attached to the 6-pin serial UART header. If you have a single USB serial UART plugged into the Jetson, then it would probably produce “/dev/ttyUSB0” (and it would go away when the USB device is unplugged).
A simple example is that on the Jetson you can plug in a USB serial UART (preferably FTDI chipset since these just always work), and the 6-pin TTL level (3.3V) end goes to the 6-pin header (note that a DB-9 serial header has a number of valid voltage ranges, but serial console and the 6-pin header both demand exactly 3.3V TTL logic level…others will fail or cause damage by using the wrong voltage). You could then open two serial console programs, e.g., minicom or gtkterm, point one at “/dev/ttyUSB0”, and the other at “/dev/ttyTHS2”, and if you type into one terminal, the text appears on the other. This is the Jetson talking to itself, but each end could actually be on different computers.
In that example it assumes serial ports and serial console programs are all set to the same speed and compatible in any other setting, e.g., parity (not doing this means either not seeing any output, or seeing garbage output). Some of those settings are for hardware, others are for the program interpreting the hardware. IOCTL commands are used if programming directly in C language. Some utility programs are able to query or set things as well, e.g., setserial. Do note though that serial devices are not plug-n-play, so they cannot actually be queried for their settings most of the time…what’s usually being queried is the driver, so it is possible to see a setting which does not actually function despite appearances.
Serial console and many programs will operate at speed 115200, 8 bits, 1 stop bit, no parity. If more than 3 wires are used, then flow control would be CTS/DTS; if only 3 wires are used, then flow control would be software. minicom and gtkterm allow setting these through their interfaces.
In terms of “/dev” naming conventions, any “/dev/ttyNumber” is a directly attached serial device; “/dev/ttyUSBNumber” would be a serial device via a USB serial UART; “/dev/pts/Number” would be a pseudo terminal (not associated with hardware, but instead a child of another terminal, e.g., in X11 GUI a terminal is a pty instead of tty); any “/dev/ttyTHSNumber” would be the same as a “/dev/ttyNumber”, except that the driver is nVidia’s driver and offers some DMA performance advantages.
There are a lot of examples and tutorials out on the internet. Just look for information on serial port programming under Linux (it happens to be a POSIX standard, so mostly it is portable across various flavors of *NIX). You’ll find it is divided into opening/closing the device like a file, controlling settings via ioctl calls, and actually transferring data.