Experimental Physics and Industrial Control System
On Fri, 06 Oct 1995 17:05:40 EDT Bonnie Montjar <[email protected]> wrote:
>I am using the XYCOM 240 board configured for 32 inputs (ports 0,1,2,3) and
>32 outputs (the rest). I've loaded the card into test crate with an
>ioc (162), and set up my database to have it read data bits on the first
>two ports. Well, when I checked it by poking the hardware, where I
>thought it should drive the bit low, I got no response (ports 0&1),
>but when I tried the same thing on what, according to the XYCOM 240
>manual, are ports 2&3, I got little red lights all over the screen!
>Anybody else run into this?
>
>Here's the wierd part - my hardware addresses say the database is looking
>at the data bits in ports 0 & 1, but.... Have I been sitting in front
>of a radiation-producing terminal too long? Am I missing something
>really obvious?
Bonnie,
What version of EPICS are you running?
How are you doing the conversion from Signal Number to port,bit?
When we started using the xy240 at the RGO about a year ago we found the driver had
bugs in, relating to addressing and getting port data confused. Unfortunately the
driver fix that we produced got "refixed" before it was installed, so the 3.12.1
release driver still has buggs in it (N.B. for Gemini developers, the Gemini
releases work OK). Our fix *is* in the Beta for 3.12.2, and I will attach the
patch file for it (from the 3.12.1 version) at the end of this message.
The other vague possibility is that the driver fix we produced may have changed the
way the card bits are addressed from the way you're using it -- I hope not, but I'm
not sure what documentation (if any) you're working from.
This is how the 3.12.1 driver maps signal numbers to ports:
The I/O bits appear in the memory space as 4 adjacent bytes, so are read
and written by the driver as a single 32-bit number. Port 0 is the MSByte of this
32-bit value & port 3 the LSByte, therefore P3B0 maps to S0 and P0B7 maps to S31.
If this is different to the way you're used to, please let me know because we have
a problem which needs to be resolved - the RGO and Gemini databases use this
mapping. The original driver didn't actually implement the other mapping properly
anyway, so no one else seems to have been using it.
- Andrew
O o ._ Andrew Johnson, Royal Greenwich Observatory
__\\_ Madingley Road, Cambridge, CB3 0EZ
__|ooooo|__ Tel +44 (0)1223 374823 Fax 374700
~~\_________/~~ WWW http://www.ast.cam.ac.uk/~anj/
--- drvXy240.c.orig Thu May 25 11:48:30 1995
+++ drvXy240.c Thu May 25 11:48:30 1995
@@ -338,13 +338,13 @@
/* use structure to handle high and low short swap */
/* get current output */
- work = (dio[card].dptr->port6_7 << 16)
- + dio[card].dptr->port4_5;
+ work = (dio[card].dptr->port4_5 << 16)
+ + dio[card].dptr->port6_7;
work = (work & ~mask) | (val & mask);
- dio[card].dptr->port6_7 = (unsigned short)(work >> 16);
- dio[card].dptr->port4_5 = (unsigned short)work;
+ dio[card].dptr->port4_5 = (unsigned short)(work >> 16);
+ dio[card].dptr->port6_7 = (unsigned short)work;
return OK;
}
- Navigate by Date:
- Prev:
XY240 mystery.... Bonnie Montjar
- Next:
Automatic allocation of hardware addresses using Capfast John Maclean
- 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:
XY240 mystery.... Bonnie Montjar
- Next:
Automatic allocation of hardware addresses using Capfast John Maclean
- 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