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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: RTEMS 5 Cannot Read Event Generator |
From: | Andrew Johnson via Tech-talk <tech-talk at aps.anl.gov> |
To: | chengsn at ihep.ac.cn, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
Date: | Wed, 17 Aug 2022 11:42:18 -0500 |
I try to running the mrfEventSystem driver with EPICS 7 on RTEMS 5. After modifying part of the code, the driver can read the EVR(EVent Reciever) Card, and it works well. But when I run the driver and use the EVG(EVent Generator), I get this error: EgConfigure: Unable to read Event Generator Card 0 (slot 3) at VME/A24 address 0x1800000.0x1800000 = 0x01800000 is not a valid VME A24 address, it has too many digits set to fit into 24 bits. Have you tried say 0x00800000 instead, or did you mean 0x00180000?In st.cmd file, the configuration for the EVG is EgConfigure(0, 3, 0x1800000). When I change the OS from RTEMS to vxWorks(on MVME6100 and MVME5500), the driver can read the EVG.
Ahh, that's not the mrfioc2 module which explains why you're using EgConfigure() to register the card.
Here is the hardware I am using:
EVG: VME-EVG-230.
EVR: VME-EVG-230-RF.
Single board computer: MVME6100 and MVME5500.
The software:
mrfEventSystem Driver Version: MRF Series 200 Event System Software Release V2-4.
The fact that you can talk to the EVR at that address from one OS but not the other implies that VxWorks may be masking off the high byte to generate its A24 address, but RTEMS doesn't.
The value of ret: EVR returns 0; EVG returns 0x88FD0000 (in vxWorks and RTEMS, sizeof(long) = 8).
Do you have any suggestions?
-- Complexity comes for free, Simplicity you have to work for.