[En-Nut-Discussion] Cortex ix_xxx_interuptY code duplication

Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Thu Jul 19 14:57:43 CEST 2012


>>>>> "Ole" == Ole Reinhardt <ole.reinhardt at embedded-it.de> writes:

    Ole> Hi Uwe,
    >> at present nearly each nut/arch/cm3/dev/xxx/ih_xxx_*.c file
    >> implements it's own xxxIrqCtl(int cmd, void *param) function.  The
    >> core of that function is always the same, apart from a different
    >> xxxIrqEntry and xxx_IRQn settings. Not a very maintainable situation.

    Ole> This is a _very_ good point and I thought about this before.

    Ole> For the LPC every IRQ handler uses exactly the same code, I think
    Ole> for the STM it will be the same.

    Ole> Even the AT91 architecture uses the same code in most cases.


    >> ...  Shouldn't we extend above TwoWireIrqCtl() to a IrqCtl() function
    >> in e.g. arch/cm3/os, replacing all xxxIrqCtl() functtions.

    Ole> Yes we could easily write a common IrqCtl function, but would have
    Ole> to pass the signal as additional argument. This would need changes
    Ole> in the API, but from the user land code this should not be called
    Ole> anyway. 

The NUTOS API jump to IRQ_HANDLER.ir_ctl. The API of
static int x##IrqCtl(int cmd, void *param)
didn't change. So no other code changes are needed.

The x##IrqCtl() function then add the need other arguments (x##_IRQn,
x##IrqEntry) and jumps to a CM3-common Cm3IrqCTL() function.

    >> So an API change here should not hurt, right?

As I see it, the API change is only local to CM3, not global to NUTOS.

    >> I think the additional redirection in the case of the common IrqCtl()
    >> doesn't matter. That way, much code duplication could be avoided.

    Ole> I think there wouldn't be any further redirection needed as long as
    Ole> we pass the IRQ_HANDLER instead of a user argument, as the user
    Ole> argument is stored in the IRQ_HANDLER struct, isn't it?

It's hard to discussion without a sample implementation or some pseudo code.
Show code :-) 

Again, the proposed macro + common Cm3IrqCTL() function can be used so long
as a global API change has not been agreed on. An having no zillions of
ih_xxx_yyy.c files will help with the later change.

Bye

-- 
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