Experimental Physics and Industrial Control System
Thanks very much Andrew.
I have been finding out some of these details bit by bit, but glad you've confirmed my suspicions about how hard this will be. I was hoping I'd missed a trick but it looks like I will have to delve into the BSP and drivers to partition the IRQ lines between the processors.
This is probably more trouble than it's worth, as we have room to simply put two crates in if we need to.
I'm trying the intermediate solution of offloading some of the CPU intensive work to the second processor without shifting any of the I/O. This will put a lot more strain on channel access but the traffic will go through one local switch, so may be OK.
Thanks again.
Keith
-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: 28 March 2017 17:59
To: Baker, Keith (DLSLtd,RAL,TEC); [email protected]
Subject: Re: Two VxWorks IOCs in one VME Crate
Hi Keith,
On 03/28/2017 07:20 AM, [email protected] wrote:
> We want to run two MVME5500 processor boards in one VME crate where
> both processors run EPICS IOCs under VxWorks (v5.5) and receive
> interrupts from other I/O cards on the VME bus? (A mix of Hytec cards
> and Power Supply Controllers.)
>
> We have cases of two processor boards in a one crate, but they are not
> both receiving interrupts from I/O modules in other slots.
>
> My boards do not need to receive data from the same I/O modules. I've
> assigned interrupt vectors so they are unique to each IP module and
> processor, but both IOCs throw up errors for receiving uninitialised
> interrupt vectors. They seem to receive interrupts on vectors not
> configured for them, or rather not from the modules they are interested in.
>
> There are 7 VME interrupt levels (on 7 VME bus lines) and I found some
> suggestion that the two processors must not both handle the same
> interrupt level, but it looks like our drivers do not give us freedom
> to configure this.
>
> Can anyone clarify this or offer a solution?
Yes, unfortunately the only way to partition interrupts across a single VME backplane to two or more CPU boards is to dedicate each IRQ line and hence interrupt level to a specific CPU board. The interrupt vector space is not shared so partitioning the vectors doesn't matter, only the IRQ lines. If you have no control over which IRQ line a particular I/O board drives then you can't decide which CPU to run the driver for that board on, it *must* run on whichever CPU "owns" that IRQ line.
Many I/O boards configure their IRQ line with jumpers or switches; make sure that you can't change it that way, even if that means you have to build a special version of any driver that has hard-coded the level (I would recommend modifying any such drivers you find to allow run-time configuration if the hardware supports that).
You must also ensure that that the VxWorks BSP's sysIntEnable() routine is only called for levels/IRQs that this CPU owns, which may mean that you have to exclude some drivers from the binary when building the IOC executable for each CPU. The sysIntEnable() routine tells the CPU's VME interface to respond to requests on the given IRQ line, and only one CPU can handle each line. Note that sysIntEnable() is called by devLib's
devEnableInterruptLevelVME() and devEnableInterruptLevel() routines where a driver uses the devLib APIs instead of the VxWorks-specific ones.
I can explain in more detail if you really want to know it, but the simple answer is that you may have to move I/O responsibilities between your two CPUs to get your particular setup working.
- Andrew
--
Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." -- Edward Snowdon
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
- Replies:
- Re: Two VxWorks IOCs in one VME Crate Ralph Lange
- References:
- Two VxWorks IOCs in one VME Crate keith.baker
- Re: Two VxWorks IOCs in one VME Crate Andrew Johnson
- Navigate by Date:
- Prev:
Re: stringout in softIOC Andrew Johnson
- Next:
Re: Two VxWorks IOCs in one VME Crate Ralph Lange
- 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: Two VxWorks IOCs in one VME Crate Andrew Johnson
- Next:
Re: Two VxWorks IOCs in one VME Crate Ralph Lange
- 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