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

[Ulrich Prinz]

Hi!

Am 19.07.2012 14:14, schrieb Uwe Bonnes:
>>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:
>
>      Ole> Hi Uwe,
>      >> if we accept the additional redirection for a common IrqCtl()
>      >> function, placement of IQR_HANDLER could be eased with a macro like
>
>      Ole> But using this macro would result in duplicate code (flash space)
>      Ole> again, wouldn't it?
>
> I don't think so. There is no difference between explict code and macro
> generated code. Only if the main programm links to the code, the code is
> actual included.

Macro is replaced by its defined code in pass 1 of the compiler run and 
therefore just a 'text-replacement'. It does not create code if it is 
not included or referred/linked.
>
>      Ole> What about my idea to use the totally same code for all IRQs by
>      Ole> changing the API a little and pass the sig_xxx struct to IrqCtl and
>      Ole> to the signal handler as well (which could then read the users
>      Ole> argument from the struct).
>
>      Ole> Unfortunately my approach would need changes in the NutRegisterIrq
>      Ole> as well. So we would have to adjust all platforms accordingly.
>
> STM32 has some shared interrupts, where I don't have any idea yet how make
> it to work with NutRegisterIrqHandler(). These IRQ are no "basic" ones, like
> USART, so probably I can live with STM32 specific registration code, or
> could even use the IRQs directly. But a generalized solution would be
> fine. Maybe you approach could help for that too. On the short run the
> fastest approach is if the Cortex people (you and me) decide for the macro .

I cannot really understand the problem. I already did some slight mods 
locally to the interrupt calls for the USARTs and GPIOs. AFAIK we have 
two different colors of the IRQ setup functions. The AVR type is one 
peripheral only and the second one is already existent in early ARM code 
where the control function gets an additional parameter specifying the 
sub-peripheral. I used that for USARTs and GPIOs in Cortex.

May be you can tell me exactly which special IRQ you think of that does 
not match NutRegisterIrqHandler?

Ulrich