Hello Jens,
I am still on this problem.
Yes. I have interrupt and I have semaphore. See bellow...
But what can be wrong? How do I detect that packets are behind?
Thanks a lot
Rastislav
Interrupt
void ETH0_0_IRQHandler(void)
{
uint32_t status;
status = XMC_ETH_MAC_GetEventStatus(ð_mac);
if (status & XMC_ETH_MAC_EVENT_RECEIVE)
{
sys_sem_signal_isr(ð_rx_semaphore);
}
XMC_ETH_MAC_ClearEventStatus(ð_mac, status);
}
Task waiting on semaphore
static void
ethernetif_input(void *arg)
{
struct pbuf *p = NULL;
struct eth_hdr *ethhdr;
struct netif *netif = (struct netif *)arg;
while(1)
{
sys_arch_sem_wait(ð_rx_semaphore, 0);
p = low_level_input();
if (p != NULL)
{
ethhdr = p->payload;
switch (htons(ethhdr->type))
{
case ETHTYPE_IP:
case ETHTYPE_ARP:
/* full packet send to tcpip_thread to process */
if (netif->input( p, netif) != ERR_OK)
{
pbuf_free(p);
}
break;
default:
pbuf_free(p);
break;
}
}
}
}
Input processing
static struct pbuf *
low_level_input(void)
{
struct pbuf *p = NULL;
struct pbuf *q;
uint32_t len;
len = XMC_ETH_MAC_GetRxFrameSize(ð_mac);
#if ETH_PAD_SIZE
len += ETH_PAD_SIZE; /* allow room for Ethernet padding */
#endif
if (len < XMC_ETH_MAC_BUF_SIZE)
{
/* We allocate a pbuf chain of pbufs from the pool. */
p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);
if (p != NULL)
{
#if ETH_PAD_SIZE
pbuf_header(p, -ETH_PAD_SIZE); /* drop the padding word */
#endif
XMC_ETH_MAC_ReadFrame(ð_mac, buffer, len);
len = 0;
/* We iterate over the pbuf chain until we have read the entire
* packet into the pbuf. */
for (q = p; q != NULL; q = q->next)
{
/* Read enough bytes to fill this pbuf in the chain. The
* available data in the pbuf is given by the q->len
* variable.
* This does not necessarily have to be a memcpy, you can also
preallocate
* pbufs for a DMA-enabled MAC and after receiving truncate it to the
* actually received size. In this case, ensure the tot_len member of
the
* pbuf is the sum of the chained pbuf len members.
*/
memcpy(q->payload, &buffer[len], q->len);
len += q->len;
}
#if ETH_PAD_SIZE
pbuf_header(p, ETH_PAD_SIZE); /* Reclaim the padding word */
#endif
}
else
{
XMC_ETH_MAC_ReadFrame(ð_mac, NULL, 0);
}
}
else
{
XMC_ETH_MAC_ReadFrame(ð_mac, NULL, 0);
}
return p;
}
-----Messaggio originale-----
Da: lwip-users
[mailto:[email protected]] Per conto
di Jens Nielsen
Inviato: mercoledì 11 maggio 2016 16:52
A: [email protected]
Oggetto: Re: [lwip-users] socket slow down
Hi
If you search the list you will find a lot of people with the same question,
it's impossible to tell where your packets are delayed without you doing some
analysis (traces? breakpoints?) but one thing I can say for sure is that your
problem is quite certainly not within lwip. A common error is to assume that
one packet equals one interrupt which equals one signalled semaphore which
equals one processed packet, whenever you receive a second packet before the
previous is processed you'll be "one packet behind" and experience delays like
you describe.
Where did you get your driver?
Best regards
Jens
On 2016-05-11 12:42, Rastislav Uhrin wrote:
>
> Hello,
>
> I need advice and help on one issue with lwip stack version 1.4.1. I
> am new to this stack and to networking in general. Nevertheless I have
> integrated it to application on Infineon xmc processor together with
> FreeRTOS.
>
> Looking on many different examples on the internet and many trial and
> error. I am using netconn sockets. Application works!
>
> The only problem is that after some time, better say after exchanging
> several 10-100 packets of different sizes, response gets slow. From
> 2ms down to 2-3seconds. It still works but slow. Same if I use ping.
>
> I tried all possible setting of lwip options but of course since I
> don't have deep insight of what they influence I was not able to
> improve this behavior.
>
> I would appreciate if you can give me a hint what could be wrong, what
> could I check, how to proceed to debug this strange behavior.
>
> I tried also new version 2.0 of stack but behavior is same.
>
> rum
>
>
>
> _______________________________________________
> lwip-users mailing list
> [email protected]<mailto:[email protected]>
> https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]<mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
