[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