[En-Nut-Discussion] Re: [btnode-development] Nut/OS goes Real-Time?

[Harald Kipp]

Matthias,

not sure wether I got you right, so please correct me.

At 12:59 01.07.2005 +0200, you wrote:

>Proposal: reduce IRQs to minimal & fast handling of their respective
>tasks.
>e.g. the SPI handler does require a single byte read and write, the
>UART RX IRQ only has to read the received single byte and can store
>it in a global variable.
>The remaining processing could then be done by code which has lower
>priority then IRQs but can interrupt app threads. This could an IRQ
>that has a lower priority than the other IRQ priority handler of the
>ATmega. In this fake IRQ handler (which does interrupt application
>threads) IRQs are still enabled to allow the important IRQs to be
>processed.

Because this "interrupt" will be unsynchronized to the event
it has to handle, it would sooner or later require polling,
wouldn't it?

Or, trying to understand your suggestion in a different way:
You mean interrupt nesting? The VS1001 driver uses this for
a very simple reason. When an interrupt occurs, several
hundred bytes have to be shifted into the decoder. Sending
a single byte per interrupt is possible but would cause too
much overhead. On the other hand, sending some hundred bytes
via SPI takes time and therefore interrupts are enabled
within interrupt context.

The bad thing is, that every thread has to reserve enough
stack space for the worst case, the case where all interupts
will be nested. With two or three threads running, this is
no big deal. With 20 or more threads this adds up to a few
kilobytes, though.



>In addition, CriticalSections have to be very short and/or they
>actually only should block the low priority add-on handler just
>proposed. so if the total load is below the max, everything should
>run nicely. Maybe someone with more RT systems experience/ data
>processing theory could comment on this :).

I discussed this with Ole recently. A few drivers (again VS1001K)
already block specific device interrupts instead of blocking
interrupts in general. Using this scheme on all device drivers
will remove many critical sections.




>This scheme looks feasible for UART, SPI and RTC Timer. Additional
>Timer processing (.. every ms for 10 us but with 20 us latency) could
>be added here, if the work is still low.
>
>
>Cheers,
>   Matthias

As I said, I still have the feeling that I completely misunderstood
you.

Harald