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]
- References:
- Interrupts, vectors and mv230x ioc Timo Korhonen
- Re: Interrupts, vectors and mv230x ioc Andrew Johnson
- Navigate by Date:
- Prev:
Re: Interrupts, vectors and mv230x ioc Andrew Johnson
- Next:
Tornado/2.0 error message Pete R. Jemian
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Interrupts, vectors and mv230x ioc Andrew Johnson
- Next:
Tornado/2.0 error message Pete R. Jemian
- Index:
1994
1995
1996
1997
1998
1999
<2000>
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|