11-27-2020 03:29 PM
Setup: I am trying to develop a TCP/IP application, I originally based it on the lwIP Echo Server example. Hardware is Arty Z7 board with Zynq 7020. I have modified the application to regularly stream chunks of data 1000 times per second. Each chunk of data is ~100 bytes, so total bandwidth is low - about 100 kB/sec.
Problem: However, I notice regular interruptions in the stream - sometimes as short as 50 msec, and sometimes up to 300 msec. I am currently running on just 1 processor (core_0), and I notice that these gaps happen when the tcp_sndbuf is full. It seems tcp_write requests are queueing up and run out of space. Eventually, the stream of data will continue, but in the meantime some data has been lost/never sent. The problem can be reliably triggered when calling xil_printf. This function seems to take a long time to execute, maybe because JTAG over the USB is slow?
Question: It seems like the xil_printf statements take priority away from TCP/IP traffic somehow, is this true? Should I try to get a second application running on a second core, and have my second core handle the xil_printf? I hope this is not necessary though. Is there some other way to force the TCP traffic to have priority so that other processes don't cause it to drop data?
I wonder if my problem is similar to the one described here:
12-26-2020 10:23 PM
Things to think about: What is it you're printing? And to where (UART)? Why? Could you use sprintf into a buffer instead, and then dump the buffer at some other time? Are they just debug prints, or something that is essential? If you're using a UART, did you set it up to be interrupt driven? Could you use something like proto threads (same author as lwIP)? What OS are you using?