RAW API Interupts

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

RAW API Interupts

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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: RAW API Interupts

Jonathan Larmour
Rick Culver wrote:
> 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?

It depends on whether you have nested interrupts - one interrupt can
interrupt another. Ultimately you cannot have two threads of execution in
lwIP core code at the same time, so if your packet read function has called
ip_input(), and a timer can then trigger and interrupt it, then that's bad.

You could disallow nested interrupts - just disable interrupts. But since a
lot of lwIP code may be run by calling ip_input(), that could lead to a
dire interrupt latency, which is normally a bad idea too.

> 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?

Yes if you take no steps to serialise access to lwIP core code.

> 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.

Disabling interrupts would work, but is very much a sledgehammer approach.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: RAW API Interupts

goldsimon@gmx.de
In reply to this post by Rick Culver
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


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

RE: RAW API Interupts

JamminJimP
In reply to this post by Rick Culver
Message
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
 
 
-----Original Message-----
From: lwip-users-bounces+jim.pettinato=[hidden email] [mailto:lwip-users-bounces+jim.pettinato=[hidden email]] On Behalf Of Rick Culver
Sent: Thursday, October 25, 2007 9:16 AM
To: [hidden email]
Subject: [lwip-users] RAW API Interupts

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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users