尝试使用Jetson TX2 NX在UART端口 (UART1，引脚203和205，/dev/ttyTHS2) 上通过MAVLink 2协议与ProfiCNC Cube Orange Flight Controller通信， 使用500000波特率 (测试了其他速率，从9600一直到921600)。 软件和硬件已经被验证可以在Jetson Nano上工作， 但是，由于需要一个更强大和性能更好的平台，它被选择采用TX2 NX。
已经更改了TX2 NX上的.dts文件， 以启用UART1端口并禁用所有其他UART接口，因为不需要它们
TX2 NX是运行在一个定制的载板 Tx和Rx线路上的信号在示波器观察,
面临的问题是，当在同一个运营商板上运行相同的软件时 经常会出现超时和数据传输错误 这在TX2 NX上会发生，但在Nano上不会发生
2. 问题梳理监视“dmesg—follow”，在问题期间能看到任何日志输出吗? 这是一个随机的失败，还是可以重复的?
如果把NX的TX/RX(我假设你没有使用CTS/DTS)放在环回模式 TX和RX直接连接在一起，仍然有数据问题吗?
请共享dmesg日志以获取最终的内核错误或警告。
3. 测试使用TX和RX引脚上的环回，TX2 NX有可能向UART TX线注入噪声。
3.1 TEST 1在Jetson Nano和Jetson TX2 NX上测试了一个简单的命令， echo “hi” > /dev/ttyTHSx. 在Jetson Nano上是ttyTHS1，在TX2 NX上是ttyTHS2。 首先，从TX插入一根电缆到RX引脚， 并向/dev/ttyTHS发送命令 这在终端上产生了无限的垃圾邮件
由于这个串行端口被循环回自身， 下面是运行”hi” > /dev/ttyS1 之后发生的事情
1. echo命令默认在消息的末尾添加一个换行符，因此“hi”+ LF发送到/dev/ttyS1 2. 因为设置了“onlcr”，串行设备将LF转换为CRLF，所以发送Tx线的物理消息是“hi”+ CRLF 3. 因为设置了“icrnl”，所以在Rx线上接收到的物理消息将CR转换为LF。因此，“cat”输出的消息是“hi”+ LFLF。 4. 因为设置了“echo”，所以在Rx(“hi”+ LFLF)上接收到的消息随后被发送回Tx线上。 5. 因为onlcr，“hi”+ LFLF变成了“hi”+ CRLFCRLF。 6. 因为icrnl，“hi”+ CRLFCRLF变成了“hi”+ LFLFLFLF 7. 由于echo的原因，“hi”+ LFLFLFLF被发送出Tx为了修复这个问题 运行了以下命令: stty -F /dev/ttyS1 -echo -onlcr
禁用” echo “可防止消息的无限循环， 禁用” onlcr “可防止串行设备在输出时将LF转换为CRLF。 现在，每次运行echo, cat都会收到一个“hi”(带有一个换行符!) 之后，能够通过UART发送单个消息。 在下面的图片中，可以找到已执行的测试的打印:
Jetson Nano (工作正常):
Jetson TX2 NX(它并没有产生无限的垃圾邮件，但它打印了大量的 command not found ):
查看kern.log， 似乎没有任何问题
Note:
在第一次测试中，我们意识到， 如果硬件环回连接在Jetsons关闭时，Jetson Nano将正常启动， 但TX2 NX将无法启动。 我们总是需要拔掉连接，启动TX2 NX，然后再次插入测试。
3.2 TEST 2使用逻辑分析仪探测这些线 差异是清晰可见的
Jetson Nano:
Jetson TX2 NX:
在Jetson Nano上，可以看到预期的行为， Jetson在UART行上写“hi”文本，然后静音， 在TX2 NX上写“hi”有一个小的等待， 然后在行上引入更多的数据
4. 使用minicom测试测试了minicom和结果似乎是一样的，下面的截图:
从“命令未找到”的错误开始 如果正在使用一个绑定到串行控制台的串行设备， 那么可能会遇到这种情况 (或者如果意外地使用了一个有效的命令，例如“ls”，那么可能会返回一些意想不到的信息)。
“/dev”中的设备不是真正的文件， 实际上是假装成文件的内核驱动程序 (普通的文件读/写操作，结合IOCTL调用，使内核驱动程序可以像文件一样工作)
当且仅当“#”相同时，可以预期任何“/dev/ttyTHS#”与 相应的“/dev/ttyTHS#”是完全相同的UART硬件
不应该同时使用两个驱动程序， 如果与一个将ttyS绑定到串行控制台的ttyTHS对话， 那么这正是会发生的事情。
使用ttyS用于串行控制台的原因是， 早期的引导代码(在Linux内核运行之前) 只有遗留驱动程序，不具备使用支持dma的ttyTHS驱动程序的能力。 在引导期间，如果从一个ttyS切换到一个ttyTHS，串行控制台日志的连续性将会丢失，因此串行控制台都使用ttyS。
如果运行这个命令，那么任何带有“dialout”的“group”都只是一个串行UART， 但是带有“tty”的“group”都将用于串行控制台: ls -l /dev/ttyS /dev/ttyTHS
另外注意，不同的tty可以用于不同的Jetson设备上的串行控制台。 UART是否有任何意外使用，它也是一个控制台?
供参考，UART设置的控制最初是通过设备树进行的。 针对特定设备的PINMUX电子表格是你设置不同默认值的方式。 然而，使用这个作为串行控制台的软件是一个独立的答案…… 在U-Boot中可能需要做一个改变，Linux本身也需要做另一个改变。 关于禁用或更改串行控制台以使给定端口可用 (如果串行控制台不使用该端口，那么答案就更简单了)，
