|
Rick,
Typically none of the actual stack functions really need to be accessed
in interrupt time when using the raw API - except perhaps pbuf allocation from
the pool when receiving a packet - i.e. allocate pbufs to queue incoming
packets in interrupt time, but don't pass them up the stack.. that can be done
in non-interrupt time.
Likewise with the timer - set a flag on your timer interrupt at
the appropriate interval.
Then,
the main application loop can process incoming packets and invoke the tcp
timer functions based on presence of the flags.
-
Jim
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.
|