|From:||garibaldi pineda garcia|
|Subject:||Re: [lwip-users] blocked udp|
|Date:||Wed, 28 Sep 2016 13:20:05 +0100|
A second way to do it, not so preferred by some peoples but worked for me, is to add critical
Sections in code that call’s LwIP functions. Adding a critical section means that you block other
Tasks for a short time. Especially the TCP task from running. It means that if you allocate a buffer from
the LwIP pool until you do not Call exit from the critical section the TCP task will not run and therefore
will not interfere.
Depends on what you mean by "critical section". If this is disable/enable interrupts, that only works if you don't use an OS.
1) Your ethernet MAC interrupt directly calls into lwIP to deliver RX packets in IRQ context (this implies all your lwIP callback functions are called in IRQ context). If you call into lwIP from your application code, then yes, all you need to to is disable interrupts. If timers are involved, even more locking code is needed to lock out timer IRQ and ethernet IRQ from each other (assuming these may be nested).2) Use "mainloop" code: http://git.savannah.gnu.org/
cgit/lwip.git/tree/doc/NO_SYS_ SampleCode.cOS:1) Use lwIP core locking. Then you only need to aquire the lwIP core lock using LOCK_TCPIP_CORE() / UNLOCK_TCPIP_CORE() before calling into lwIP.2) Use tcpip_callback() to get called back from TCPIP thread and do the sending work there.In both OS cases, take care of ethernet RX, you need to use tcpip_input() as input function in netif_add() to make RX thread-safe.Dirk
lwip-users mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|