我在做USB绑定的UART0通讯时, 遇到一些类似的问题. 当我向芯片发送大量数据时, 例如8K字节 如果芯片此时没有使用printf, 则可以完全发送. 如果刚好此时又printf输出字符串, 这个时候发送的数据便存在2个问题 1 - 数据的位置乱了, 例如 1234567890 会变成 1238945670 2 - 芯片内的代码无法读取完整的数据, 总有一些数据卡着等待接收. 例如发 aaa bbb ccc ddd 这些数据, 肯可能只收到 aaa bbb ccc d , 剩下dd 收不到. 如果此时再发送eee过去, 则芯片收到的是dd , 而eee又收不到. 这个现象一旦放生, 通过...

ESP_houwenxiang wrote: ↑

Mon Nov 26, 2018 6:40 am

Hi,
你遇到的第一个问题是因为 select 会等待一个信号量, 这个信号量只有在中断里才会 give, 所以导致了已经缓冲的数据无法读取到. 我们的工程师会尽快解决这个问题的. 第二个问题可以描诉的详细一点吗?有可能是缓冲区溢出导致的,我们得确认一下.

tuweidong wrote: ↑

Sat Nov 24, 2018 10:43 am

如果接收数据量累计大于rx_buf_size的大小, select将永远无法接收到数据 ,

thanks !!

你好:
第二个问题的现象: 当select后每次接收的数据量小于发送的数据量, 多次发送数据后, 应用层接收不到任何数据, 可能是接收缓冲区或者接收fifo满了.

如果接收数据量累计大于rx_buf_size的大小, select将永远无法接收到数据 ,

在使用uart的select来接收数据时, 传入read函数的buflen小于输入缓冲区内已经接收到的数据, 仅在第一次调用select函数时可以正确的执行,然后recv 指定长度的数据; 当我第二次调用select函数时, 它会提醒我timeout,但是此时输入缓冲区内依然还有数据没有被recv; 当然,每一次调用select之前都已经使用FD_ZERO和FD_SET函数来清理套接字集合. 可以在例程peripherals/uart_select上进行简单改造来重现这一现象: 1. 将UART_NUM_0修改为UART_NUM_1或者UART_NUM_2, 相应的修改相关的参数, recv接...