|
From: | Nicolas Pinault |
Subject: | Re: [lwip-users] Abnormal Tx delays |
Date: | Fri, 21 Sep 2007 14:07:24 +0200 |
User-agent: | Thunderbird 2.0.0.6 (Windows/20070728) |
The problem with the MAC I use is on the Rx Interrupt side since I don't use Tx interrupt. The KSZ8841 has a MAC with a Rx FIFO wich can contain several packets. When a received packet matches all filter conditions, it is transfered into the fifo and an interrupt is generated. My interrupt handler only signals a semaphore. My Rx task waits on this same semaphore, reads Interrupt status and clears interrupt status. If Rx is signaled in Interrupt status, then the packet is read from Rx FIFO. The problem arises when 2 or more Rx packets are stored in Rx FIFO before Rx task can react to interrupts (thru semaphore). For example : - One packet is stored in Rx FIFO, an interrupt is trigered and the semaphore is signaled. - Another packet is stored in Rx FIFO, another interrupt is trigered and the semaphore is signaled again. - Rx task gets the semaphore, reads the interrupt status, clears the interrupt status and reads the packet fron the Rx FIFO. - Rx task gets the semaphore again reads the interrupt status and... do nothing since the interrupt status does not signal a Rx packet event. I expected the interrupt status flag to be still signaling a Rx packet in FIFO since a Rx packet IS in the FIFO. Now, if, say, 10 seconds later a new packet is stored in the Rx FIFO, all the process executes well but... reads the packet that has been received 10 seconds earlier. The new received packet will be read when another packet is received. This way, a ping response can be sent seconds after the request. Lwip is not faulty. Nicolas |
[Prev in Thread] | Current Thread | [Next in Thread] |