我希望使用串行端口与另一个设备txdev通信,问题是txdev正在异步发送数据,我不希望read函数阻塞,好的是txdev正在发送固定大小的数据,但我不知道如何使用这个技巧。
我要做的是:

fd = open(DEVICE_NAME, O_RDWR | O_NOCTTY);
bzero(&termios_p, sizeof(termios_p));
termios_p.c_cflag = CS8|CSTOPB|CLOCAL|CREAD;
termios_p.c_iflag = IGNPAR;
termios_p.c_oflag  = 0;
termios_p.c_lflag = ~ICANON;
termios_p.c_cc[VMIN]=DATA_LENGTH;
termios_p.c_cc[VTIME]=10;

cfsetispeed(&termios_p, BAUDRATE);
cfsetospeed(&termios_p, BAUDRATE);

tcflush(fd, TCIFLUSH);
tcsetattr(fd,TCSANOW,&termios_p);

this posti取消重新启动,这导致读取被阻塞VTIME=0也被阻塞。
有人能帮我找出解决方案吗?我认为我必须使用中断处理程序而不是read你同意吗?
第二个问题:由于发送方无法与接收方同步,是否有一个中断处理程序将接收到的数据存储在指定的缓冲区中(如果是规范模式,但不是非规范模式,则取消重新启动),或者只有在达到read函数时才执行此操作,如果我错了,请纠正我
像往常一样,非常感谢。

最佳答案

我想使用串行端口与另一个设备txdev通信,问题是txdev正在异步发送数据,我不希望read函数阻塞,
您似乎误解了Linux应用程序应该如何从串行端口读写。所有数据都在程序和UART之间缓冲。您的程序不必总是准备好在数据断开时读取数据。操作系统(特别是UART设备驱动程序和tty子系统,其中包括行规程)这样做,并为您的程序缓冲数据。
根据定义,RS-232是一种异步通信链路。字符/字节可以随时传输。消息包将在任何时间点到达,因此应用程序将不得不等待组成消息包的字节。这就是使用阻塞读取的情况。
接收串行数据的典型问题是如何对接收到的数据进行词法扫描,以识别完整的消息分组。文本消息(规范模式)只需使用ASCII行控制字符来分隔消息/行。即使是固定长度的数据包也需要验证(以确保消息实际上以正确的字节开始)。见this example of scanning fixed-length packets
我想我必须用中断处理程序而不是读你同意吗?
不,UART设备驱动程序已经在为其中断提供服务(或者使用DMA)来捕获从串行链路接收到的每个字节。
由于发送方无法与接收方同步,是否有一个中断处理程序将接收到的数据存储在指定的缓冲区中(取消启动,这是规范模式的情况,但不是非规范模式),或者只有在达到读取功能时才执行此操作,
接收端的串行端口无需与字节级的发送串行端口“同步”。RS-232是一种异步通信链路:发送方可以/将在任何时候发送字符/字节,另一端必须准备好在设备驱动级(而不是应用程序)接收它(除非有硬件或软件流控制)。
操作系统总是缓冲这个接收到的数据。应用程序的read()系统调用只是从系统缓冲区到用户缓冲区的复制操作。此复制操作适用于规范模式和非规范模式。
“获得同步”通常是要通过协议在消息或数据包级别解决的问题。主从式是定义串行链路协议的常用配置。主端向从端发送查询消息。从机必须始终准备好接收查询。从机端可以通过事务请求或数据捕获或其他方式进行响应,或者通过NAK消息来指示它对主机没有任何东西。此请求-响应对话框旨在控制或调整两个单元之间的数据流(和处理负载)。
附录
我计划做的是在无限循环中进行阻塞读取(VTIME=0vmin=DATA_LENGTH)
假设您总是在发送设备之前启动您的程序,以便第一次发送的数据长度与程序第一次读取的数据长度一致。
在一个理想的或被监控的情况下,这可能大部分时间都会起作用。
但是对于工业24/7应用,丢失消息帧对齐的可能性是真实存在的(例如,发送设备在传输过程中重新启动),因此没有有效手段来验证和恢复消息帧对齐的方案是不充分的。
IOW串行端口的raw read()可能不会在缓冲区中返回对齐的消息(即buf[0]可能不包含消息的第一个字节)。
具有非零VTIME的更小VMIN是典型的termios配置,其前提是每条消息后串行链路空闲(间隔较短)。
但是代码应该是健壮的,可以在读取任何/所有消息片段时处理它们。因此可能需要多个read()来重建整个消息。

关于c - 在输入中以固定数据无阻塞读取,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/38140875/

10-10 09:57
查看更多