Re: [lwip-users] lwIP Ethernet (TCP and UDP) communication slows down and acting weird

[Sergio R. Caprile]

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.