[En-Nut-Discussion] Cortex ih_xxx_interuptY code duplication, continued

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Wed Jul 25 11:02:51 CEST 2012


>>>>> "Ulrich" == Ulrich Prinz <ulrich.prinz at googlemail.com> writes:

    Ulrich> Hi!  Am 19.07.2012 14:14, schrieb Uwe Bonnes:
...
    Ulrich> May be you can tell me exactly which special IRQ you think of
    Ulrich> that does not match NutRegisterIrqHandler?

Look e.g at 
 STM32F10X_XL

TIM1_BRK_TIM9_IRQn = 24,/*!< TIM1 Break Interrupt and TIM9 global Interrupt  */

If we want to handle this interrupt with plain NutRegisterIrqHandler(), the
code to handle TIM1_BRK must handle TIM9 too and vice versa. 
This is against the principle of least surprise.
So I think we should somehow decouple both signals. With placing either
sig_TIM1_BRK or sig_TIM9 some higher level interrupt code has to be placed
at TIM1_BRK_TIM9_IRQn and on interrupt has to look for the reason of the
interrupt and branch to the appropriate sig_XX code.

This is somehow the same situation as with the GPIO/EXTI interrupts. Here we
have a GpioRegisterIrqHandler() that cares for placing the common interrupt
and branches to the appropriate GPIO_SIGNAL code.

So for shared interrupts like above we either need a complement to
GpioRegisterIrqHandler() and GPIO_SIGNAL like RegisterSharedIrqHandler() and
SHARED_SIGNAL or we need a good idea how to extend NutRegisterIrqHandler().

Uwe

-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------


More information about the En-Nut-Discussion mailing list