Experimental Physics and
Industrial Control System

Timo Korhonen <[email protected]> · Fri, 20 Oct 2000 17:05:03 +0200

Hi Andrew,

thank you for your comments and advice.

Andrew Johnson wrote:

> For the mv2700 BSP here at APS I didn't want to substantially change the
> way the BSP worked, so I've kept the chain.  There probably should be an
> intDisconnect() routine to cope with situations like your driver, but I
> wouldn't use the technique you described myself because this isn't a
> standard vxWorks facility.  I would change the driver to connect just one
> routine that makes a call through a global function pointer.  It can just
> change the function pointer itself when it wants to switch to a different
> service routine, so doesn't need anything like intDisconnect().

I agree, but did not do like this because:
-the driver is not my code and I guess I should contact the author and ask if he
is willing to change the code (well, I could also make a local version for us.
Actually, I did not understand what was happening and did not want to touch
the code too much ;-) And, with the patches, the driver now works fine.

-devDisconnectInterrupt is provided in the epics base API (devLib.c), and should
(IMHO) either be supported for all architectures or taken out. It is not used very
often (this was the first instance I have ever seen it used), but nevertheless.
(assuming that only one interrupt per vector is connected, the original API call
can be implemented rather easily - this was also the reason for my original
question.)

> I added a routine to ravenMpic.c in our mv2700 BSP to be called by
> intVecGet() and return the first entry in the chain for the given vector
> number.  This removes the need to change veclist.c other than to exclude
> the default handler stub tests.  My additions were as follows:
>

I did something very similar...

> > 3. The list of unexpected interrupt handlers is not very relevant in the case of
> > mv2306, because the Universe interrupt handler checks the vector table and
> > complains if the interrupt handler entry is NULL.
> > It is not necessary to have a handler attached to unused vectors. This is just
> > cosmetics, but in the patches I remove the default vxWorks handler stub
> > definitions from the table, to avoid confusing error messages during startup.
>
> Agreed, the stubs are not useful for PowerPC, but 68K targets do need
> them.  I would like to see veclist regard NULL returns from intVecGet() as
> unconnected vectors on PPC, but keep the old functionality for the 68K
> family.
>

I left the stubs in place for 68K by using #ifdefs.
My version of veclist output looks like the following:
-> veclist
vec 0x03     C ISR i8250Int(0x1ADE54)
vec 0x04     C ISR i8250Int(0x1ADE0C)
vec 0x07     C ISR sysSpuriousIntHandler(0x0)
vec 0x10     C ISR sysIbcIntHandler(0x0)
vec 0x12     C ISR 0x10595C(0x1BAF70)
vec 0x15     C ISR sysUnivVmeIntr(0x0)
vec 0x20     C ISR 0x1034A4(0x0)
vec 0xA6     C ISR ErIrqHandler(0x1AB0B00)
vec 0xA8     C ISR ErIrqHandler (ErLink)
value = 0 = 0x0

for 68K the code is not changed, I only added some code for PPC to look for the
symbols.

Timo

--
Timo Korhonen  PSI (Paul Scherrer Institut), SLS
               CH-5232 Villigen PSI
               tel + 41- 56 3103262  fax + 41 - 56 310 3151
e-mail:        [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System