[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] lwIP Ethernet (TCP and UDP) communication slows down an
From: |
Sergio R. Caprile |
Subject: |
Re: [lwip-users] lwIP Ethernet (TCP and UDP) communication slows down and acting weird |
Date: |
Mon, 9 May 2016 18:30:39 -0300 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
I didn't take a very in deep look at the capture file, but I can tell
you your .8 device is missing frames.
If that device is indeed the lwIP machine, you are most likely having a
problem in your driver or your threading.
You say you only use callbacks, but you are not. It is not lwIP who owns
the system, and it only runs when you tell it to run. Callbacks are lwIP
calling you for action after you've told it to the something.
At some point, your Ethernet controller has a frame. 1) Do you poll the
controller from the main loop ? 2) Do you get an int from the
controller, flag the situation, and get back to the controller to get
the frame from the main loop, or 3) do you get an int from the
controller and proceed to get the frame and send it to lwip right from
inside the interrupt handler ?
(3) is definitely bad behaviour, wrong, caca, thou shalt not do that.
To check if your driver takes all frames out... well, without knowing
your chip, I would start by looking for somewhere checking an "I have
outstanding frames" indicator. If the check is not inside a loop...
From my very own driver and port (which is no guarantee, but worked OK
so far...):
the controller gets a frame and generates an interrupt
frames arriving after this condition will NOT generate a new interrupt
which is handled by dm9000_interrupt()
a flag is set
main() loops
main() calls ethernetif_input()
which calls the low level function
which calls dm9000_start_rx()
which returns if there is no outstanding frame
or loops for every frame until it gets a good one (CRC)
sends oldest outstanding frame to lwIP
who calls your callbacks
and returns
and returns
and returns
and keeps going...
So, actually, the chip is polled for outstanding frames every time it
signals he got (at least) one, and one good frame is processed per call.
This gives priority to embedded app over comms. Your mileage may vary;
you might want to loop for every frame.