[参考译文] RTOS/F28M36P63C2：错误套接字未阻塞？

Todd、

我不熟悉 TM4C 板、因此我无法评论它与 Concerto 之间的任何差异、甚至无法评论 tcpEcho 演示之间的差异。  

从测试的声音可以看到，您没有对 tcpWorker()子例程进行任何修改。  假设没有更改，演示代码与 tcpWorker()例程相同：

空 tcpWorker (UARg arg0、UARg arg1)
｛
int clientfd =(int) arg0；
int bytesRcvd；
int bytesSent；
char buffer[TCPPACKETSIZE]；

System_printf ("tcpWorker：start clientfd = 0x%x\n"、clientfd)；
system_flush()；

while ((bytesRcvd = recv (clientfd、buffer、TCPPACKETSIZE、0))> 0)｛
字节 Sent = SEND (clientfd、buffer、字节 Rcvd、0)；
if (bytesSent < 0 || bytesSent！= bytesRcvd)｛
System_printf ("错误：发送失败。\n")；
中断；
｝
｝
system_printf ("tcpWorker stop clientfd = 0x%x\n"、clientfd)；

close (clientfd)；
｝ 

我不清楚如何在 while 循环表达式中的 recv()之后插入断点。  我观察到的是，recv()调用持续返回0，导致>0测试失败，并再次调用 Receive，直到最终收到消息。  这就是为什么在我修改的版本中，我移动了 while 循环内的 recv()，并将其更改为 while (true)无限循环。  为了确认返回0、我添加了打印 recvBytes 和 errno 来演示返回0字节(只有在出现错误(超时、套接字关闭等)时才会发生这种情况。  

在产生错误并且不相信它之后，我继续并单步执行 recv()调用(通过 TI-RTOS/NDK 子例程调用) 在 recv 缓冲区中找不到它能够执行 semTEK()的信标，并让操作系统阻止它，以便 NDK 任务可以在它接收套接字上的数据时执行 semGive()。  (但 TM4C 板可能有所不同)

我在测试中注意到的另一个差异是、您运行了测试客户端并让其首先发送数据。  我只是为了让它执行 connect()来创建 tcpWorker()任务，但从未发送任何数据。  我不认为这很重要、我只是想我应该提到它。