Jeff, 1. You want to poll Ethernet_input plus update all of the lwIP timers in your polling loop. If this is in a task, only this task is permitted to make lwIP API calls. Most implementations I've seen call ethernetif_input, not netif->input.
2. Yes, with the protection. I would not call Ethernet_input from the isr because it could run a long time passing the packet up the stack for processing. I suppose you could protect ISR reentrancy and protect calls into lwIP while in the ISR, but it's not necessary. You need to run a loop for lwIP timers and it's just as efficient to call Ethernet_input as well. 3. Yes. Which is why it's easier to just store the packets and have the polling loop process them. I posted a message on this list not too long ago with a function that takes care of all of the lwIP timers and calls ethernetif_input. I use the RAW API, or NO_SYS=1 as some here refer to it. Bill >-----Original Message----- >From: [email protected] >[mailto:[email protected]] On >Behalf Of Jeff Barber >Sent: Wednesday, March 11, 2009 3:23 PM >To: Mailing list for lwIP users >Subject: [lwip-users] lwip driver model > >I'm planning to port lwIP into a new system. I want to use the raw >API with no OS. I will need to write a new ethernet NIC driver and I >just want to make sure I completely understand the driver model (I >find the documentation available on this subject rather confusing). I >would appreciate it if someone could confirm the assumptions here, or >explain where I'm off base. > >1. The function ethernet_input should be called to introduce new >packets into the lwip stack. > (Or, more specifically, it appears that my framework should specify >ethernet_input in the netif_add call as the input function; then the >driver should call netif->input.) > >2. Interrupt handler *may* call pbuf_alloc or mem*_alloc in interrupt >context (with an appropriate definition of sys_arch_protect) but >should not call ethernet_input if there is any chance that other code >in the stack is already executing. > >3. Hence, practically speaking, the interrupt handler will need to >defer actually introducing packets into the stack until the main >polling loop. > >Thanks a lot, >Jeff > > >_______________________________________________ >lwip-users mailing list >[email protected] >http://lists.nongnu.org/mailman/listinfo/lwip-users _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
