EPICS Home

Experimental Physics and Industrial Control System


 
<19941995  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 <19941995  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: Re: devLib, locationProbe routine
From: [email protected] (Jeff Hill)
Date: Wed, 26 Oct 94 14:06:23 MDT
> 
> Am I right in thinking that the routine  locationProbe  in devlib returns 
> SUCCESS to indicate that the given address does *not* respond to VME accesses of 
> any size?  

Correct.

> I presume the aim here is to indicate that this area of the memory 
> map is currently not used.

Correct.

> It seems wrong 
> to expect an error code (S_dev_addressOverlap) as the status return indicating 
> success (ie board found), which is what I would have to do if I used the  
> locationProbe  routine.

This depends on what you are using locationProbe() for. Some VXI cards allow
their addresses in VME A24/A32 to be mapped dynamically. If we move a card
to an allocated address space then we must be certain that nothing already
exists in this space.

> 
> Should I be using this in my driver to check that a board is present?  The older 
> drivers use vxMemProbe, which returns OK if something responds.  

One of the original goals for devLib.c was that it should provide a wrapper around
vxWorks specific routines so that EPICS drivers would be more portable.
So we do want drivers to call a routine in devLib.c that provides a bus error
safe probe. Perhaps the return code names from this routine are badly chosen.
I am open to creating a new routine for 3.12 which addresses this issue.

Another goal of devLib.c was to detect address collisions and provide
address maps on demand. This functionality is provided by 
devRegisterAddress() and devAddressMap().

> 
> Are there plans to modify the existing drivers to use the devLib facilities?

Yes. The source in devLib.c was a product of the aborted EPICS RX 
project. I suspect that there are very few drivers that actually use 
it at this time. The first step should be to review the 
devLib interface for EPICS V4. We should look carefully at virtual memory
issues, A16/A32/system RAM mapping conflicts (attn John Winans), and
OS independence.


Jeff

______________________________________________________________________
Jeffrey O. Hill			Internet	[email protected]
LANL MS H820			Voice		505 665 1831
Los Alamos, NM USA 87545	FAX		505 665 5107

Navigate by Date:
Prev: Re: devLib, locationProbe routine Marty Kraimer
Next: vxWorks mv167 BSP memory FAQ John R. Winans
Index: <19941995  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: devLib, locationProbe routine Marty Kraimer
Next: vxWorks mv167 BSP memory FAQ John R. Winans
Index: <19941995  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