Just some partial information…a lot, but generic to understand working with serial UARTs…actually working with UARTs is simple. Assuming you know almost nothing about UARTs.
You will find that what Windows calls a “COM” port is in general called a serial UART (a UART is hardware, a port is a software interface to the hardware). I’m not sure how many serial UARTs are available on your Nano (in part it would depend on whether this is a dev kit using SD card, or whether it is a commercial eMMC model with a third party carrier board). One UART will be set up for serial console, and not available for your use unless you disable serial console. There should be another serial UART which is available for any use you choose. If you need the serial console you can arrange to disable console, but this is usually a bad idea if it isn’t mandatory.
On the Linux side you will see “device special files” in directory “/dev” (I am assuming you know how to get around in the Linux filesystem to look at files and directories). These are not “real” files in the sense that they do not exist on the hard drive the way a real file would. These are “pseudo” files, and actually exist only in RAM (pretending to be a file). The creator of those files are drivers and features of the Linux kernel. When you use one of these files you are talking to a driver or feature using ordinary file read/write tools.
If you run command “ls -l /dev/tty*”, then you’ll notice each line starts with a “c”, which means a character serial device. You’ll also see that the “owner” is usually “root”, but the “group” can change. Generally speaking most of these will be a serial UART, and if the group is “tty”, then a terminal program is using that device. If the group is “dialout”, then you’ve found what you want, and this device is free for you to use.
To further limit which device you want to look at, devices of this naming convention are an older driver interfacing a serial UART: “/dev/ttyS#”, where the “#” could be any number, e.g., “ttyS0”. The UARTs intended for a Jetson end user could be one of those file name conventions or it could be name convention “ttyTHS#”, e.g., “ttyTHS0”. The driver which creates the file is how the file gets its name. You won’t find a file with name format ttyTHS# on a desktop PC, this is only on a Jetson, and this is because the driver can use DMA (which is more efficient) for the UART, whereas the ttyS# format does not have DMA available.
Take a look at the narrower list of serial files:
ls -l /dev/ttyS* /dev/ttyTHS*
…then consider only devices with group “dialout”. Group “tty” will be already in use by serial console software.
The Jetson serial UART is capable of using either the legacy ttyS# driver or the “Tegra High Speed” driver, the ttyTHS#. You should not use both at the same time for a give # since this is the same physical hardware UART. Using only one driver at a time, don’t intermix use of two drivers on the same hardware at the same time.
Incidentally, if you have a USB serial UART cable (if you don’t have a convenient UART on your PC you’d probably use a USB version), then the naming convention will depend on chipset manufacturer. For example, an FTDI chipset, at the USB end on a PC, probably has a name like “ttyUSB0”. Other manufacturers will use another naming convention for the USB side. As a contrived example the Jetson side “/dev/ttyTHS1” might talk to the PC’s “/dev/ttyUSB0”. Simply by reading or writing bytes of data (read on one side, write on the other as if it were just an ordinary file).
Serial console will be quite useful to you for working with a Jetson, but the serial UART associated with this shouldn’t be used for your purposes without disabling the console. See:
https://www.jetsonhacks.com/2019/04/19/jetson-nano-serial-console/
A serial UART is a “serial” device. It takes bytes of data and sends or receives this one byte at a time in the proper order if and only if the two sides have been correct set to matching parameters, e.g., speeds must match (UARTs have no way to query another UART so you might need to set this up yourself if defaults are not what you want). Thus you would normally use two serial UARTs, one at each side, where one sends (over the TX wire) and the other receives (over the RX wire). Each serial UART has both a TX (send) and RX (receive) wire, so each end can both send and receive. You can connect a UART’s TX and RX to its own wires, and this is useful for testing, and is referred to as “loopback” mode. In loopback mode writing to a TX wire simply echos back on the RX wire (consider that a single UART will never disagree with itself on settings, but when you have two UARTs talking to each other, then it is possible for errors due to mismatched settings).
A default UART setting which will run out of the box on a Jetson is “115200 8N1”. This is a speed of 115200 baud (basically bits per second), translating 8 bits to a byte, with no (“N”) parity bit, and 1 stop bit. Serial console works with that setting. One of the default “/dev/ttyTHS#” which is not currently in use will have that same setting unless you change it. Many serial devices on the PC end will likely “just work” at that setting when talking to a Jetson’s serial UART.
Setting speed and other parameters is probably a bad idea before you know a bit more. For example, there are also wires for hardware flow control (which is optional) using the Clear To Send (“CTS”) wire and Request To Send (“RTS”) wire. This is not normally enabled.
Many people with drones want the serial UART to talk faster than speed 115200. If you use the Jetson’s integrated serial UARTs, then you probably need to set two stop bits instead of the default single stop bit once you get the speed a bit higher. Don’t try this unless you have speed 115200 working first. If 115200 works, and then you go faster, but start seeing data corruption or dropped bits, then you probably have to go to using two stop bits instead of one. The need for two stop bits some time after exceeding speed 115200 is a limitation of the hardware.
FYI, many drones have a serial UART which has no method available to tell it to use two stop bits. In that case you might need an add on USB serial UART on the Jetson and skip using the integrated version.
There are a lot of Linux serial UART programming guides, and any of them will show you that this is really simple. Here is a good URL to look at:
https://elinux.org/Serial_port_programming
There are variations of the information at the above URL using different programming languages. If the serial UARTs are using the correct settings though, then this is almost entirely just a case of knowing how to read or write a file.