Hi There,
I'm using lwip TCP client using raw api with kinetis k64 MCU.
It's a high speed data transmission (about 2mbps), and the code looking working good.
But there is some problem, because of which the code jumps to sys_assert() functionafter transferring few 10s of MBs and stay there. The section of code is as follows-
void sys_assert( const char *msg )
{
//FSL:only needed for debugging
#ifdef LWIP_DEBUG
PRINTF(msg);
PRINTF("\n\r");
#endif
OSA_EnterCritical(kCriticalDisableInt);
for(;;);
}
and i'm transferring the data to lwip by repeatedly calling below section
if(ERR_OK == tcp_write(tcp_conn_pcb, p_byTCPSendBuff, g_TCPSendSize, TCP_WRITE_FLAG_MORE))
{
g_TCPSendSize = 0;
}
and the code jumps to sys_assert() from following section of tcp_in.c
LWIP_ASSERT("tcp_receive: valid queue length", pcb->unacked != NULL ||
pcb->unsent != NULL);
can someone tell me what i'm doing wrong and how can i prevent the execution from going to sys_assert()
Thanks in advance
Punit Kumar
Hi, Punit,
Regarding your question, I think there is problem if you transfer packet to an Ip address continuously.
How about using the code:
while(1)
{
tcp_write();
tcp_recv();
tcp_close();
delay();
}
BR
XiangJun Rong
Thanks xiangjun.rong
But how it should be if i need to send continuous sensor sampling data @48ksps having about 70 bytes of information per sample?
--
Punit Kumar
Hi, Punit,
Regarding your question, let's figure out the required bit rate:
70*8*48KSPS=2.688Mega bits per second, as we know the Ethernet interface can transmit 100M bits per second if the Ethernet bus is idle, even if we consider the packet head load such as mac address/IP address/port, i think it is okay. Because you transfer stream, I suggest you use DGRAM mode(using UDP protocol). I suggest you use the maximum packet size, in other words, put as many as samples into one packet to increase efficiency.
Hope it can help you.
BR
Xiangjun Rong
Hi xiangjun.rong
can you please tell me how this condition be true
if (pcb->snd_queuelen != 0)
{
LWIP_ASSERT("tcp_receive: valid queue length", pcb->unacked != NULL || pcb->unsent != NULL);
}
i got this message, which is possible only if unacked == 0 & unsent == 0, but still queuelen != 0,i.e.,something there in queue?
awaiting your response
Best Regards
Punit Kumar
Hi Punit.
I discussed the issue with our experts and there are their points:
It can work in interrupt but the code may not be mixed with lwIP usage in main application.
It simply must be one-threaded. Main application and hooks running in interrupts creating preemption.
All the code using lwIP must be in interrupt (cause of lwIP hooks), so using it in user application is forbidden.
A simple main loop for a single-threaded system (lwIP 1.4.0+) might look like this:
while(1) {
/* poll the driver, get any outstanding frames, alloc memory for them, and
call netif->input, which is actually ip_input() */
poll_driver(netif);
sys_check_timeouts(); /* Handle all system timeouts for all core protocols */
}
there are no interrupts.
“To enable the lwIP stack, the user application has to perform two functions calls from the main program loop:
• ethernetif_input() to treat incoming packets (function defined in the network interface GMAC driver)
• timers_update() to refresh and trigger the lwIP timers (defined in the user application, typically under the
network folder)”
It mean that the lwIP in bare-metal is polled – not interrupt driven.
To your question about snd_queuelen please see the explanation here on the thread lwip-users - tcp_write() errors on snd_queuelen
Anyway, all these experts are on lwip community, please for lwIP-related questions, the user may ask on “Mailing list for lwIP users”: https://lists.nongnu.org/mailman/listinfo/lwip-users
I hope this helps you.
Best Regards,
Iva