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: Multiple asyn ports inside asynPortDriver class |
From: | Abdalla Ahmad via Tech-talk <tech-talk at aps.anl.gov> |
To: | Mark Rivers <rivers at cars.uchicago.edu>, "tech-talk at aps.anl.gov" <Tech-talk at aps.anl.gov> |
Date: | Mon, 11 Nov 2024 09:59:05 +0000 |
Hello Mark Thanks for the info this is really helpful. Since drvUser is a void pointer, it allows to have my own driver interface as a struct right? Also, I looked into asynUser definition, what is the difference between drvUser, userData and userPvt?
Should I care about the latter two? Thanks. Abdalla. From: Mark Rivers <rivers at cars.uchicago.edu> Hi Abdalla,
I recently wrote a driver for the SIS3153, which is a USB to VME interface card. It allows access to VME bus registers from a Linux machine over USB with no
CPU card in the VME crate. I was faced with a similar decision as you: do I use the asyn "addr" field to specify the VME address, or do I encode it in the drvParams part of the link INP
or OUT field? I decided to use the drvParams field for 2 reasons:
I adopted the following convention for the drvParams field:
For example:
My SIS3153 driver is based on asynPortDriver. It implements the drvUserCreate method to parse the drvParams field. That routine converts the VME_ADDRESS field into an integer, and puts a pointer to that integer in the pasynUser->drvUser field. It removes the VME_ADDRESS
from the drvParams string, and passes the remainder of the string (ADDRESS_MODE) to the base class asynPortDriver::drvUserCreate. That base class parses the ADDRESS_MODE because those are defined as the port driver parameters. The driver constructor does not set the ASYN_MULTIDEVICE flag in the constructor, so asynPortDriver and asynManager treat the driver as only supporting addr=0. The writeInt32 and readInt32 methods get the VME address to use as follows: addr = *(int *)pasynUser->drvUser; Let me know if you have any questions. Mark From: Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo> It seemed to be an issue with the device itself, the device’s own software produced the same timeout behavior on continuous TCP requests. I have another question, right now I am relying on asyn’s address as the register’s address on the device but I think
the driver could be designed in a better way, can you give pointers on how to parse asyn parameter strings and create corresponding asyn parameters? Thanks! Abdalla. From: Mark Rivers <rivers at cars.uchicago.edu> Hi Abdallah, UDP and TCP use the same port number, not just the same IP address and physical port? I don't think I have run into that before, so I can't see whether it has been tested with asyn. You can turn on asynTrace
on each port, and send them to different files to see if there are issues. Mark From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Abdalla
Ahmad via Tech-talk <tech-talk at aps.anl.gov> Hi I am writing an EPICS driver for an Ethernet-based device in which the control interface is split between TCP and UDP layers of the same port number (i.e., registers IO is through UDP while waveforms is through TCP). I have to
create two asyn ports using drvAsynIPPortConfigure function, so my question is are there any consideration regarding this approach? Because I am noticing some timeout issues, most likely from the device’s side, so I want to narrow the issue as much as I can.
Thanks in advance. Best Regards, Abdalla Al-Dalleh Control Engineer SESAME P.O. Box 7, Allan 19252, Jordan Fax: +96253511423 Email : abdalla.ahmad at sesame.org.jo |