|
Scott,
my worry behind changing/adding architecture is
because existing software needs to be changed. There is not much to change, but
as you know, it takes time to really change it in all the different software
places (to name a few: uclinux, orpmon, test cases that use interrupts). So my
mine concern is that we render this software useless in future implementations.
>From this POV it might just be better to say in the manual that only level
interrupts are supported and for edge triggered an external interrupt controller
is needed. My question is, how many interrupt controllers, specifically in
system on chip, are edge triggered? In my opinion most of the stuff today
in SoC is level.
Anyway yes the patch for OR1200 lower two interrupt
inputs is OK. I'll commit to the CVS.
regards,
Damjan
----- Original Message -----
Sent: Wednesday, February 26, 2003 6:33
AM
Subject: RE: [openrisc] PIC
documentation
-----Original
Message-----
From: owner-openrisc@opencores.org
[mailto:owner-openrisc@opencores.org]
On Behalf Of Damjan
Lampret
Sent:
Tuesday, February 25,
2003 5:03
AM
To: openrisc@opencores.org
Subject: Re: [openrisc] PIC
documentation
before we make a rush decision let
see what are some other options.
How about clearing pending
interrupts in PICSR by reading PICSR register. This would constitute an atomic
interrupt read/clear operation. You get pending interrupts and ack them by
single PICSR read operation. Any current software would have to be modified if
it doesn't store PICSR status already and therefore this could mean that
current software wouldn't have to be modified and there would be no two
version of the software in the future.
One problem I can
imagine with this solution is that reading the PICSR clears *all* pending interrupts, not just the one
that originally triggered the dispatch to the interrupt service routine
(ISR). That means that the ISR that reads the PICSR will need to service
all pending interrupts (or somehow post them to the OS for deferred
servicing). Whether or not your proposed change to the PIC would cause
lack of forward-compatibility in SW seems somewhat dependent on how ISRs are
implemented. I would hazard that some ISRs exist that service only a
single interrupt, then resume program execution, possibly to be interrupted
immediately again. (Actually it’s not much of a guess; I have written
such code for the OpenRISC port of eCos myself.)
-Scott
|