Re: [lwip-users] Feeding incoming packets to lwIP

[Dan Lewis]

David,

Thanks for taking the time to write such a detailed response. However, I'm 
afraid I still disagree with (or perhaps misunderstood) your statement, "The 
issues are the same whether you disable ISRs or use a semaphore."  You 
obviously have a lot of experience in this sort of thing, so if I misread you 
and it turns out that I'm "preaching to the choir", then please forgive....

When two threads compete for access to a shared resource (e.g., a single 
variable), then all that is necessary is to insure that the scheduler won't 
allow a context switch from the middle of one thread's critical section and 
suddenly start running the other thread's critical section. Semaphores provide 
this kind of (thread-vs-thread) protection. The situation is different, 
however, when the competition is between a thread and an ISR. The scheduler 
can't prevent the ISR from running. In this case you can only protect the 
thread's critical section by disabling interrupts for its duration.

In response to your question:

> So if your ISR does not call any lwip functions, how do you get the 
> ethernet data from your chip to memory and then to lwip. How many copies 
> are involved?

The ISR calls a uC/OS function to post a message to a uC/OS mailbox. The 
message is merely a flag, indicating that an interrupt (signaling the arrival 
of a packet) has occured and that a packet is waiting in the internal ring 
buffer of the NIC. Then I have an independent thread that consists of an 
infinite loop. At the top of the loop is a uC/OS function that pends on the 
same mailbox, waiting for something (anything) to be posted. Once the pend 
completes, the thread (not the ISR) makes the lwIP call to ethernetif_input() 
which calls low_level_input() to read the packet directly from the NIC into a 
pbuf and pass it up to lwIP. Of course the thread has to have a high priority 
so that it gets to run almost immediately after the interrupt.

I favor this approach rather than letting the ISR call functions such as those 
in memp.c and pbuf.c.  IMHO, it's always best for ISR's to "get in and get out" 
as fast as possible. Otherwise, you spend so much time in the ISR that you may 
miss a subsequent interrupt from the same (or a lower priority) device.

All the best!

Dan