lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-devel] core/timers.c with NO_SYS?


From: Bill Auerbach
Subject: Re: [lwip-devel] core/timers.c with NO_SYS?
Date: Tue, 14 Jun 2011 12:16:51 -0400

Hi Leon,

>That's why in an RTOS environment the interrupt handler must not do
>the actual work; it must schedule a thread that takes the appropriate
>lock, not an interrupt disable lock.
>
>Doing work in an interrupt handler is a common design mistake; the
>interrupt handler should only make sure the interrupt is silenced
>until serviced by a thread.

Although we're getting off topic, I can't agree that it's a mistake to use
one methodology over another.  Interrupts are real-time and a designer does
what he must to make the product stable and reliable (and work of course).
Some interrupts might be more appropriately serviced in a thread and others
in the ISR itself.  At Gigabit high-throughput speeds the packet rate is
impossible to *not* do inline.  In fact even on a 600MHz PowerPC I polled a
global "packet received" count because even just signaling a task in the ISR
that packets have arrived took too much time and my receive bandwidth fell
noticeably.  The NIOS II (Simon and I both happen to use) can't even keep up
at Gigabit speed.  We throttle back and tell the PHY to run at 100MbS.  We
get no TCP errors at 100 MbS and errors at Gigabit.
 
>But it seems there are too many different approaches to take, and
>people are using the current architecture for that. I think there is
>no way to clean up the current mess without breaking these existing
>users.

You might well be right about this.  It might be best to design a new
thread-safe API and use callbacks or macros and let the port handle RTOS
things as it needs to.  Then again there may be no one shoe that fits all.

>I will start a new effort on a proper RTOS layer on top of the raw API.

This would be good.  Although we use a cooperative RTOS with lwIP.  This
allows all threads to do what they need to with lwIP without worrying about
low level data structures.  As most of our products do things based on ISRs
or the mostly running TCP timer thread (which ultimately does the callback
to the application) I've been happy with lwIP's RAW API.

Take care,
Bill





reply via email to

[Prev in Thread] Current Thread [Next in Thread]