I think, and could be wrong, that
calling the timers or ethernetif_input from an ISR could occur while a tcp_recv
or tcp_sent callback is in process and this would cause problems. I say this
because tcp_sent is ultimately called from tcp_input and your ISR would make
that a recursive call.
I used ethernetif_input to receive packets
and the resulting tcp callbacks are my event handlers. The rest of my system
is driven by interrupts. When they aren’t running, my main loop calls
the lwIP timer processing and ethernetif_input functions and some other minimal
background functions. So the non-interrupt time of my processor is spending
probably 80% processing packets. Because of this I cannot overrun the
connection. I don’t even think I use ¼ of the allocated buffers. This
works well for me. If you use an ISR, you’re bandwidth is limited to the
number of packets you process per interrupt. If you process all received
packets and can buffer all of them between interrupts, you should do OK, except
for the latency between interrupts.
Bill
From:
address@hidden
[mailto:address@hidden On Behalf Of Rick
Culver
Sent: Tuesday, March 18, 2008
10:40 AM
To: Bill Auerbach; 'Mailing list for lwIP users'
Subject: Re: [lwip-users] Timers
& Low Level Tick
These are some good thoughts, thank you. I also thought
about trying to process the ethernetif_input() in an ISR triggered by the
hardware when a packet is received but I had the same concerns. Currently
I have the ethernetif_input() and the timer functions called from a function (I
call it lwip_check() which is simply called in my "main" loop.
I was wondering if I called lwip_check() from a low priority interrupt instead
of the "main loop" if that might work. It wouldn't step on the
timer functions as they would be called at a different time from the same lwip_check()
and at the same priority. The 2 questions in my mind are 1) how
often would I need to call lwip_check() and 2) would other functions in
the "main loop" that try to output (tcp_write() or udp_write() )
would then have a problem being stepped on. Any thoughts about these
ideas?
----- Original Message -----
Sent: Monday, March 17,
2008 10:36 AM
Subject: RE: [lwip-users]
Timers & Low Level Tick
Rick, you and I are using lwIP in a
similar fashion. I saw the same thing you did. To significantly
improve the performance, I changed ethernetif_input to return an int. It
returns 1 if it processed a packet (if low_level_input returned non NULL) and 0
if it didn’t. When I process packets, I use:
while( ethernetif_input() )
;
to ensure I process all received
packets.
I don’t believe you can reliably
call ethernetif_input from an ISR. I thought of doing the same thing on a
“received a packet” interrupt, but this could interrupts
tcp_fasttmr which I thought would be a bad thing.
Bill
From:
address@hidden
[mailto:address@hidden On Behalf Of Rick
Culver
Sent: Monday, March 17, 2008 10:46
AM
To: address@hidden
Subject: [lwip-users] Timers &
Low Level Tick
I am using the callback API with the LWIP stack.
Currently I have a function that calls the timers (etharp_tmr, tcp_slowtmr,
tcp_fasttmr, etc.) and the processing of received packets. I call this
function in the main non-IRQ loop. However, I am finding that in
some cases I can not call this function frequently enough to keep up with the
packets and/or timers. I was thinking of setting up a low priority IRQ to
simply call this function about every 100ms or so to process the timers and
received packets. My question is this, if I am also trying to set up
calls to tcp_write at the non-IRQ level will cause problems for the stack to
run my processing function at the low level IRQ interrupt? Can this be
done and/or can it be done with certain precautions in doing so? Please
advise.
|