[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Tue, 08 Jan 2002 10:03:05 +0100
- From: valette at crf.canon.fr (VALETTE Eric)
- Subject: BSP_install_rtems_irq_handler API
Thomas Doerfler wrote:
en libbsp and libcpu code/preprocessor statements.
> I am currently moving the helas403 BSP and PPC403/405 CPU code
> to the new exception handling, and I really have a split
> opinion on the new API. I think that some part are really
> nice, like to "irq_on" and "irq_off" functions in the drivers,
> but you are right, not passing the vector numbers to the irq
> function is really one design flaw among others (IMHO):
No. You can do int by adding your own vector that push the argument and
then call a geberic function. In that case you pay the cost because you
need it but not every user that do not need it. Cost in term of
instruction is exactly the same.
> *IRQ/exception related numbers are generously mixed into one
> enumeration, this makes things hard to distinguish
Please be more precise...
> *at least for PPC there seems to be no standard way to
> provide a new exception handler without giving it its own
> assembler entry/exit code, although the default handler
> code could easily be modified to support this
What do you want for an API?
> *part of the related files is placed in libcpu, another part
> in libbsp, without clear definitions which parts are
> architecture specific, which are microcontroller specific
> and which are really board specific. (maybe a hirarchy
> lib/libbsp/<arch>/shared/<controllerchip>/xxx would hel
Execptions are processor dependent. IRQ are platform dependent as the
PIC and interrupt line affectation change from board to boards. The code
actually reflects this...
> Maybe your mail might start a discussion how to improve
> structure, but it will take some time (and testing) to reorder
> things once more. I also don't think that changing the API
> every year is a good idea... My idea would be to discuss ideas
> how to improve things and then, when a consensus is there
> rework them.
Starting the discussion is fine but do not try to reinvent the whell and
read the mailling lists archive...
/ ` Eric Valette - Canon CRF
/-- __ o _. Product Dev. Group Software Team Leader
(___, / (_(_(__ Rue de la touche lambert
35517 Cesson-Sevigne Cedex
Tel: +33 (0)2 99 87 68 91 Fax: +33 (0)2 99 84 11 30
E-mail: valette at crf.canon.fr http://www.crf.canon.fr