[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