UART上的串行数据已损坏

Serial data over UART gets corrupted

本文关键字:数据 已损坏 UART      更新时间:2023-10-16

我正在为开发板(Beagle Bone Black)开发一个应用程序,该应用程序将通过UART外围设备发送一些数据。开发板运行Linux Kernel(一些Debian发行版,3.8.xLinux内核版本)。

为了通过UART发送和接收数据,我使用标准的UNIXAPI:open()read()write()系列函数。

为了设置通信参数(baud ratestop/start bitsparity等),我使用termios结构(来自termios.h)。

这是我进行I/O设置的一些相关代码序列:

fd_debug = open("output.out", O_CREAT | O_WRONLY, S_IRUSR | S_IWUSR);
fd_write = open(port.c_str(), O_WRONLY | O_NOCTTY | O_SYNC);
std::cout << std::endl << "I opened: " << port;
struct termios settings;
tcgetattr(fd_write, &settings);
cfsetospeed(&settings, B19200);         /* baud rate */
settings.c_cflag &= ~PARENB;            /* no parity */
settings.c_cflag &= ~CSTOPB;            /* 1 stop bit */
settings.c_cflag &= ~CSIZE;
settings.c_cflag |= CS8 | CLOCAL;       /* 8 bits */
settings.c_lflag = ICANON;              /* canonical mode */
settings.c_oflag &= ~OPOST;             /* raw output */
tcsetattr(fd_write, TCSANOW, &settings); /* apply the settings */
tcflush(fd_write, TCOFLUSH);

在那里我打开了两个文件描述符:

  • fd_debug:链接到文件,用于调试
  • fd_write:链接到UART外围设备(在我的特定情况下为/dev/ttyO4)

这是当我想通过UART:发送一个字节时执行的函数

int UARTIOHandler::write(uchar8 byte) {
auto tp = std::chrono::steady_clock::now();
std::cout << std::endl << "[write] Timestamp: " << std::chrono::duration_cast<std::chrono::milliseconds>(tp.time_since_epoch()).count();
::write(fd_debug, &byte, 1);
return ::write(this->fd_write, &byte, 1);
}

为了检查我发送的数据是否通过UART正确接收,我已经连接了板上的TXRX引脚(环回测试)(因为我希望能够接收回我发送的信息),并在特定的UART端口上运行minicom

minicom -D /dev/ttyO4 -b 19200 -C test.test

在发送了一些数据后,我比较了这两个文件(调试文件和minicom生成的输出文件(应该包含通过UART接收的数据))。问题是数据不一样!

这是实际发送的数据(十六进制):

55 33 02 04 06 08 0a 0c d5 55 0b 01 03 05 07 ef 55 3f 07 06 05 04 03 02 01 e3 55 16 01 02 03 04 05 06 07 08 db 55 3f 01 02 03 04 05 06 07 e3

这是在调试文件中接收到的数据(它是相同的,所以这证实了存在一些UART问题):

55 33 02 04 06 08 0a 0c d5 55 0b 01 03 05 07 ef 55 3f 07 06 05 04 03 02 01 e3 55 16 01 02 03 04 05 06 07 08 db 55 3f 01 02 03 04 05 06 07 e3

这是minicom工具接收到的数据(设置为侦听相同的UART端口和相同的设置(baudparity等):

55 33 02 04 06 08 0a d5 55 01 03 4d 69 6e 69 63 6f 6d 32 2e 36 2e 31 07 ef 55 3f 07 06 4d 69 6e 69 63 6f 6d 32 2e 36 2e 31 04 03 02 01 e3 55 16 01 02 03 04 4d 69 6e 69 63 6f 6d 32 2e 36 2e 31 06 07 08 db 55 3f 01 02 03 04 4d 69 6e 69 63 6f 6d 32 2e 36 2e 31 06 07 e3

从一点上可以观察到,所有数据都会被破坏,并且接收到更多的字节。

为了检查输出文件中的实际数据,我使用了hexdump,如下所示:

hexdump -ve '1/1 "%.2x "' test.test

可能是什么问题?

这似乎是Minicom对ENQ字符(0x05)的响应,并将其响应记录在会话捕获中。附加数据是未损坏的Minicom2.6.1。它被替换为流中的每个0x05。