Question

我正在尝试使用Linux下的termios框架在UART（usbserial）上连接非接触式智能卡读卡器。代码在PC上工作正常，但是当我在ARM9目标上交叉编译并试用它时，它能够打开设备甚至将命令写入设备，但是read命令无限期地阻塞。以下是代码段：

int mifare_rdr_init(struct mifare_1K * ptr, char *rdr_devnode)
{   
    bzero(ptr, sizeof(struct mifare_1K));           // zero the entire structure
    // open serial device
    int fd = open(rdr_devnode, O_RDWR|O_NOCTTY );
    if (fd == -1) {
    perror("Failed to open serial device ");
    return 1;
    }
    ptr->serialfd = fd;                 // save file descriptor

    ptr->serialdev.c_iflag = 0;                 // no i/p flags
    ptr->serialdev.c_oflag = 0;                 // o/p flags
    ptr->serialdev.c_cflag = ( CS8 | CREAD | B38400 );      // 8 bits, receive enable, baud for rdr
    ptr->serialdev.c_lflag = ( ICANON );                // CANONICAL mode, means read till newline char '\n'.
    // control chars 
        // commented below line as suggested by A.H below, since it's not needed in CANONICAL mode
    // ptr->serialdev.c_cc[VMIN] = 1;               // read unblocks only after at least one received char.

    // flush all i/o garbage data if present
    tcflush(ptr->serialfd,TCIOFLUSH);

    int ret = 0;
    // apply settings
    ret = tcsetattr(ptr->serialfd,TCSANOW,&ptr->serialdev);
    if (ret == -1) {
        perror("tcsetattr() failed ");
        return 2;
    }
    return 0;
    }

int get_mifare_rdr_version(struct mifare_1K *ptr, char *data)
{
    // flush all i/o garbage data if present
    tcflush(ptr->serialfd,TCIOFLUSH);

    int chars_written = write(ptr->serialfd,"$1V\n",4);
    if( chars_written < 0 ) {
        perror("Failed to write serial device ");
        return 1;
    }
        printf("cmd sent, read version...\n");   // this prints, so I know cmd sent...
    int chars_read = read(ptr->serialfd,ptr->data_buf,14);
    if( chars_read < 0 ) {
        perror("Failed to read serial device ");
        return 2;
    }
    // copy data to user buffer
        printf("reading done.\n");    // this doesn't print...
    return 0;
}

mifare_1K结构包含串行设备，termios结构和我正在使用的各种缓冲区的文件描述符。我提到的设备是usb-to-serial（module：ftdi_sio）设备。在termios模式下，它的配置为38400 @ 8-N-1。

Canonical模式，因为来自阅读器的响应以'\ n'结尾，所以它在Canonical模式下处理得更好，因为它会在收到'\ n'之前读取设备（如果我错了，请纠正我）。

首先我调用init（）fn然后调用get_rdr_version（）。打印字符串“cmd sent，read version ...”，因此我知道它能够写入，但不会打印字符串“读取完成”。之后。

另一件事是，如果我移除读卡器并将该端口连接到另一台PC上的gtkterm（串口终端程序），我就不会收到gtkterm上的“$ 1V \ n”了!! 。然后在一点RnD之后我发现如果我重新启动阅读器连接读取器的系统，那么只有我在另一个Gtkterm上得到那个cmd“$ 1V \ n”。如果我在没有重新启动的情况下再次尝试，那个gkterm上没有看到那个cmd ...一个线索，但是他已经想出来了。

类似于将cmd写入设备文件，但是没有耗尽到实际设备吗？有没有办法解决这个问题？

任何帮助都非常受欢迎，因为我现在已经被困在这一段时间了.......nnks。

更新：

好的，我已经通过稍微修改代码来实现它。如下所示。

// open serial device
    int fd = open(rdr_devnode, O_RDWR|O_NOCTTY|O_NDELAY );  // O_NDELAY ignores the status of DCD line, all read/write calls after this will be non-blocking
    fcntl(fd,F_SETFL,0);   // restore read/write blocking behavior
    if (fd == -1) {
    perror("Failed to open serial device ");
    return 1;
    }

这是在我的init（）函数中打开端口的代码的修改部分。两个变化：

1）O_NDELAY被添加到open（）调用中的标志，忽略数据载波检测（DCD）线以查看另一端是否已连接并准备好进行通信。这最初用于MODEM，我不需要，事实上，因为我使用usbserial，所以根本没有它。但是这个标志还进一步调用read（）和write（）作为非阻塞。值得注意的是，我原本以为这会通过将CLOCAL添加到termios结构的cflag中来解决，我曾尝试过这种方法但是没有用。

2）fcntl（fd，F_SETFL，0）恢复进一步read（）和write（）调用的阻塞行为。

这个组合对我来说非常合适。仅的原因我没有将此作为答案发布，因为它是相同的硬件，我还不知道为什么它在没有这个修改的情况下在PC上工作。事实上，我能够使用 minicom 从ARM9 TARGET上的智能卡读卡器读取数据，但不是我的程序。我将检查FT232BL文档以查看默认情况下DCD的状态是什么。

无论如何，我在Serial programming Guide for POSIX operating systems找到了这一点信息。解释任何人???当然，我会在找到答案后发布答案。

干杯：）

Answer 1

刚刚在带有Telegesis USB模块的Raspberry Pi上遇到相同的症状，我将其添加为另一个数据点。

在我的情况下，原因证明是一个缺失的RTS标志。 Telegesis期望CRTSCTS流控制，并且在没有看到RTS的情况下不会向Raspberry发送任何数据。这里令人困惑的方面是：a）相同的代码在PC上运行得很好，并且b）在第一次插入Telegesis时它在Raspberry上运行良好，但是在/ dev / ttyUSB0的后续开放中没有数据可见由Raspberry。

出于某种原因，似乎在ARM上RTS标志在设备关闭时被清除，但是没有再次设置，而在x86 / x64上，RTS标志保持设置。这里的修复只是设置RTS标志（如果还没有） - 例如

#include <sys/ioctl.h>
//...
int rtscts = 0;
if (ioctl (fd, TIOCMGET, &rtscts) != 0)
{
  // handle error
}
else if (!(rtscts & TIOCM_RTS))
{
  rtscts |= TIOCM_RTS;
  if (ioctl (fd, TIOCMSET, &rtscts) != 0)
  {
    // handle error
  }
}

我注意到在您的情况下您不使用流量控制，因此上述情况可能不适用。这是你的问题，并提到minicom工作，这导致我们发现我们的问题的解决方案 - 所以谢谢你！

Answer 2

您可能会检查三件事：

规范模式/非规范模式混合1

您正在混合规范模式和非规范模式：

ptr->serialdev.c_lflag = ( ICANON );
// ...
ptr->serialdev.c_cc[VMIN] = 1;

termios(3)联机帮助页有关VMIN的信息：

VMIN 非 - 数字读取的最小字符数。

很明显，你的超时不会像你想象的那样发挥作用。

Canonical mode / non canonical mode mixup 2

另外，该联机帮助页面在下面进一步说明：

这些符号下标值都不同，除了VTIME， VMIN 可能分别与VEOL， VEOF 具有相同的值。在非规范模式特殊字符含义被超时替换含义。有关VMIN和VTIME的说明，请参阅说明下面的非规范模式。

因此，请检查这两个平台的这些常量的定义是否不同。可能是，EOL / EOF逻辑可能会被错误的设置破坏。 EOL和EOF都会导致从read返回。

未初始化`c_cc`

您的代码未显示c_cc数组的正确初始化。您既不会读取现有设置，也不会为规范模式所需的值提供合适的默认值。到目前为止显示的代码甚至没有清除值。因此可能会使用不可预测的值。

因未知原因读取串口

2 个答案:

规范模式/非规范模式混合1

Canonical mode / non canonical mode mixup 2

未初始化`c_cc`

因未知原因读取串口

2 个答案:

规范模式/非规范模式混合1

Canonical mode / non canonical mode mixup 2

未初始化c_cc

未初始化`c_cc`