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

[Leon Woestenberg]

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.

Regards,

Leon.