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

[Harald Kipp]

Ole,

Did you consider the implementation of the separate
interrupt stack in your thoughts? It had been implemented
by Oliver Schulz some time ago to allow reliable stack
usage calculation. I think it is disabled by default,
but if every driver does its own complete interrupt
handling, then this feature will become useless.

Beside that, one of the reasons for routing interrupts
through system routines is, that we may be able to add
performance monitoring (e.g. counting interrupts).

As often, you can't have all advantages in one solution.
If you need to squeeze out the last nanosecond of response
time, than every kind of overhead is too much. If you
want features, then your response time will suffer.

For example, the old UART driver uses a byte value to
count the number of bytes in the receiver buffer, which
had a fixed length of 256. No turn around checking was
required and the interrupt routine had been simple and
fast. The current USART driver supports handshaking, half
duplex and configurable buffer lengths, which blew up the
code significantly.

IMHO, the best solution would be, to create a specific
UART driver, remove and add everything, which is or is not
required for a specific application. This driver may
even do its native interrupt handling. Its documentation
can clearly state, that it breaks the separate interrupt
stack configuration.

Regards,
Harald


Btw. the PPP driver already uses a specific driver UART driver
to do its HDLC part. Be warned, it's not a masterpiece of clear
code design...it just works. :-)


At 15:05 01.07.2005 +0200, Ole Reinhardt wrote:
> >This could be done for all interrupts quite easily reducing every
> > interrupt execution by ~20us, however, the flexible Nut/OS interrupt
> > registration mechanism gets lost...
>
>I think we don't realy need to use the registration mechanism at least
>on interrupt sources that are not flexible in any way. UART interrupts
>for example may be hard coded as they will never change on any hardware
>plattform (except an other cpu type is used).
>
>Ole Reinhardt