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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | intConnect vs ipmIntConnect vs devConnectInterrupt |
From: | Bill Brown <[email protected]> |
To: | Epics Tech-Talk <[email protected]> |
Date: | Fri, 29 Sep 2000 08:21:01 -0700 |
I'm working on the interupt service section of a driver for a timer/counter IP (Greenspring IP-UnidigT). Don't know that we'll ever really use the IP - it was relatively cheap and simple so it seemed like a good target for learning the pitfalls of interrupts on IP's. The problem is in figuring out which vector to use. ipmIntConnect() for at least some carriers simply makes a call to intConnect() which "just does it"; there is no checking that the vector is not already in use. devConnectInterupt checks that the vector is not assigned before it calls intConnect() and returns a status which may indicates that the vector requested is already in use. In the case that the vector is in use it seems like the IP driver could just try again with another vector. Is there any reason why ipmIntConnect() couldn't call devConnectInterupt() instead, thereby simplifying debugging and perhaps book keeping? I also see that drvIpMv162.c doesn't seem to support this entry point. Does this mean that IP-generated interrupts cannot be supported when using the mv162 (or '172?) as a carrier? I have the feeling that once again I can't find the trees 'cause the forest is in the way. Any help greatly appreciated! -bill