[Top][All Lists]

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

Re: [lwip-devel] RFC: SYS_ARCH_DECL_PROTECT makes no sense, remov e it

From: Leon Woestenberg
Subject: Re: [lwip-devel] RFC: SYS_ARCH_DECL_PROTECT makes no sense, remov e it
Date: Wed, 05 May 2004 23:56:18 +0200
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

Hello Jim,

Pettinato, Jim wrote:
Actually, the protection mechanism we've been discussing prevents that. Ints
are disabled while the lightweight protection scheme is in a critical
section (between SYS_ARCH_PROTECT() and SYS_ARCH_UNPROTECT()). I think this
is how Adam intended they be used.

Without a preemptive kernel, I could not wait around for the task-level
driver to read the ethernet device, the SMSC chip only has a 4-deep hardware
fifo. Hence the bad habit. :) I'm considering ways of breaking that bad
habit; I'm not thrilled with the idea of calling allocation routines from an
ISR myself.

I understand your problem. You cannot service the chip outside the interrupt often enough , so you would lose bursts of packets.

Fair enough. I did not know the SYS_ARCH_PROTECT was used for interrupt/
task level protection only.

I understand the need. I just needed a case where it made sense. Thanks!

We minimize the latency between successive reads.

Thanks for your input - how do you keep up with incoming packets at the task
level if you've no preemptive scheduler?

Our processor is an Infineon 16-bit processor at 18 MHz. Prio Nested Ints.

We minimize latency between reads. Our application is a while loop calling several state machines successively. There is no busy loop
(OK, some inits have busy loops).

In one system, where we have no (RT)OS, we have a busy loop that reads a flag set by the driver interrupt. If the flag is set, we loop through
the received packets. Afterwards, we disable the interrupt, read the
chip receive queue and if empty, clear the flag, re-enable the interrupt.

Note that the interrupt is disabled for only 4 cycles.

If the driver buffer overflows, we lose packets. We can cope with ping
floods from a fast Linux host. We only miss packets using the "initial
load" ping parameter, which puts back-to-back packets on the wire.

2) In another system we use uCOS-II and its pre-emptive scheduler.



reply via email to

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