Serial comm with orbitty

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

I am trying to make a serial communication between tx2 and MCU. I use orbitty carrier board with tx2.
I don’t know if Jetson’s uart port and Orbitty carrier’s uart port are what I know.

https://drive.google.com/file/d/1cdKdezLaqaqzatBb0qEImrXix3LjjFl4/view?usp=sharing
This is jetson’s port

https://drive.google.com/file/d/1E4i1c_Ua5-GyfOkbOtH_xDvuMLxUNwfd/view?usp=sharing
This is orbitty carrier board’s pin

Does the red mark mean the same thing?

2

UART0 would be one UART, and UART1 would be another UART. The TX and RX exist for each UART. You’d use TX of UART0 and RX of UART0, or you would use TX/RX of UART1, but you would not mix them as UART0 and UART1 know nothing about each other. I do not know about the Orbitty, so I cannot say which “/dev/tty” belongs to UART0, nor which belongs to UART1. I also do not know if one of those is used as a serial console.

In terms of naming convention, you will see several “/dev/ttyS#” format file names, and several “/dev/ttyTHS#” file names. /dev/ttyS0 is the same hardware as /dev/ttyTHS0, but uses different drivers. Similarly, /dev/ttyS1 is the same hardware as /dev/ttyTHS1, but a different driver. Avoid using both at the same time. Drivers needed during boot prior to Linux running will always use the “/dev/ttyS#” syntax, which uses a standard driver. The “/dev/ttyTHS#” is for the “Tegra High Speed” driver, and this driver includes DMA support, so typically you would use the “/dev/ttyTHS#” file once in Linux. Serial console is a special case because it must run both before and after Linux runs without loss of continuity of service, thus it always uses “/dev/ttyS#”.

You can test which device special file belongs to a given physical pin set, but I’d first start by examining permissions of the “/dev/ttyS#” files. When used as a console the group ownership is “tty”. When a UART is available for general use (and not as a console), then the group will be “dialout”. You would not want to loopback test a serial console (I doubt it would harm anything, but all terminal output would feed to the terminal input and there is no telling what might happen, e.g., infinite error loop). What follows is therefor for the “ls -l /dev/ttyTHS#” files with group “dialout”…

  1. Make sure that if you do not use “sudo”, that you add your user to group “dialout”:
    sudo usermod -a -G dialout your_user_name
  2. Wire the TX to the RX of a given UART.
  3. You can then use any serial program, I prefer gtkterm (“sudo apt-get install gtkterm”). The following is an example for ttyTHS2 since I know on the dev kit this is available via J17:
    gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyTHS2
  4. Type into the terminal. Text will echo if you have the jumper on TX to RX of the correct pins for that UART. If not, jumper the TX to RX of the other UART.
  5. Optionally, jumper CTS to RTS for loopback flow control.

If your carrier board does not have the correct board support package (basically a device tree added over the correct flash software prior to flash), then the various pins may or may not work.

Hopefully your device works with 3.3V TTL logic level.

Note: If you go faster than speed 115200 you should use two stop bits instead of one stop bit.