The simple answer is the lwIP core is not protected from concurrent access, which means you must take care yourself that the stack is not accessed from different contexts (as you explained) at the same time.
Unfortunately, this means what you are trying to do will not work with the current code: either you access the lwIP core from _one_ interrupt only (as Jonathan explained), or from non-interrupt level only.
Simon
Am 25.10.2007 um 15:16 schrieb Rick Culver: I am relatively new using the lwip stack but have been able to successfully use the RAW API in some what of a "polled" mode. However, I am needing to get the stack to function using interrupts because I have a number of functions that will not be able to service the lwip stack frequently enough in the polled mode. My question has to do with re-entry of the stack code. That is, if I process my packet read function >from a hardware interrupt and trigger the timers (tcp_tmr()) from a tick interrupt is there a problem with the lwip getting confused? Added to this there would be situations where I would be setting up a packet to send (udp_send() or tcp_send()) with in a function not triggered by an interrupt. Basically I could have 3 levels of trigger (tick IRQ, hardware IRQ, background) all firing at the same time, is this a problem? I don't really have an RTOS and don't really want to implement one for this job. I just need the stack to run more or less independent of my main application. Can anyone provide some inside or direction on this before I even try to implement the interrupts? Thank you all. _______________________________________________ lwip-users mailing list
|