g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: RE: Epics driver using BLT or CBLT to read FIFO wanted
From: Mark Rivers <rivers@cars.uchicago.edu>
To: "Davidsaver, Michael" <mdavidsaver@bnl.gov>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 7 Sep 2012 04:42:23 +0000
I am curious about the plans for devlib2.

The first paragraph on the main page of the devlib2 documentation says:

"devLib2 is an extension to the EPICS OS independent VME bus access library (devLib v1) found in the 3.14.x series. The v2 library is an overlay and extension to the v1 library and not a replacement. It is planned that the v2 library will be merged with the v1 library for the 3.15.x series. After that point devlib2 will continue to exist as a location for backports and bug fixes for the 3.14.x series."

The first version of 3.15.x has now been released, and it does not seem that devlib2 has been merged with the v1 library.  Is this still planned?

Thanks,
Mark


________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Davidsaver, Michael [mdavidsaver@bnl.gov]
Sent: Thursday, September 06, 2012 4:32 PM
To: tech-talk@aps.anl.gov
Subject: RE: Epics driver using BLT or CBLT to read FIFO wanted

See below

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> bounces@aps.anl.gov] On Behalf Of Benjamin Franksen
> Sent: Thursday, September 06, 2012 4:55 PM
> To: tech-talk@aps.anl.gov
> Subject: Re: Epics driver using BLT or CBLT to read FIFO wanted
>
> Am Donnerstag, 6. September 2012, 21:57:00 schrieb Mark Rivers:
> > I would like to renew my plea for an update to the EPICS devLib to
> > support VME operations in an OS-independent manner.  This includes
> not
> > just the DMA operations that this thread originally referenced, but
> > also basic register write and read operations.
> >
> > For example, when Kate Feng converted my SIS320 driver from vxWorks
> to
> > RTEMS she made changes like the following:
> >
> > -        status = sysDmaFromVme(dmaId_, fifoBuffer_, (int)fifo_base_,
> > VME_AM_EXT_SUP_D64BLT, (count)*sizeof(int), 8); +#ifdef __rtems__
> > +        status= BSP_VMEDmaStart(dmaId_,fifoBuffer_PCIaddr,
> > fifo_baseVMEaddr_, (count)*sizeof(int)); +#else
> > +        status = sysDmaFromVme(dmaId_, fifoBuffer_,
> > + fifo_baseVMEaddr_,
> > VME_AM_EXT_SUP_D64BLT, (count)*sizeof(int), 8); +#endif
> >
> > According to Till's message this might not have been necessary, since
> > he said he had an RTEMS implementation of Andrew's API, so perhaps
> the
> > same API call could have been used?
> >
> > But there were also changes like this:
> > -    registers_->irq_control_status_reg =
> SIS3820_IRQ_SOURCE4_DISABLE;
> > +    writeReg32(&registers_->irq_control_status_reg,
> > SIS3820_IRQ_SOURCE4_DISABLE);
> >
> > and this:
> > -  firmwareVersion_ = registers_->moduleID_reg & 0x0000FFFF;
> > +  firmwareVersion_ = readReg32( &registers_->moduleID_reg) &
> > + 0x0000FFFF;
> >
> > So where I was doing register access directly, on RTEMs this is being
> > wrapped in a function or macro.  I understand that this may be needed
> > on some architectures to ensure that writes are done immediately,
> etc.
> > The problem is that Kate's code won't build on vxWorks because the
> > readReg32 function is defined in a header file only included for
> > RTEMS.  I don't know of a vxWorks equivalent.
> >
> > We really need something standard in EPICS base that we can all use
> in
> > our VME drivers to make them OS and architecture independent.
>
> I agree, wholeheartedly. The more so since the RTEMS way to access
> registers strikes me as the better idea anyway: matching a C struct
> definition with the register layout (as it is done traditionally in
> EPICS drivers) is error prone and non-portable, since the exact memory
> layout of a struct depends on architecture and compiler. So, yes, we
> need a set of access functions (or
> macros) like read/writeReg8/16/32 packages as an OSI library; and
> indeed devLib is the right place to put them.


There is a set of macros in devLib2 defined for all OSs

http://epics.sourceforge.net/devlib2/

They have forms like le_read32(address) and nat_write16(addr,value) with variations for 8,16, and 32 bit data widths and byte order swap (be_/le_ for PCI) and no swap (nat_ for VME).  By default there are just volatile pointer dereference.  There are specializations for those RTEMS and vxWorks targets which provide something better.

http://epics.sourceforge.net/devlib2/group__mmio.html

I'd provide some more links, but the hgweb page won't load for me right now...

http://epics.hg.sourceforge.net/hgweb/epics/devlib2/

Look in the common/ directory.


Michael





Replies:
Re: Epics driver using BLT or CBLT to read FIFO wanted Michael Davidsaver
References:
Epics driver using BLT or CBLT to read FIFO wanted Bai Jiaoni
Re: Epics driver using BLT or CBLT to read FIFO wanted Till Straumann
RE: Epics driver using BLT or CBLT to read FIFO wanted Mark Rivers
Re: Epics driver using BLT or CBLT to read FIFO wanted Benjamin Franksen
RE: Epics driver using BLT or CBLT to read FIFO wanted Davidsaver, Michael

Navigate by Date:
Prev: RE: Epics driver using BLT or CBLT to read FIFO wanted Allison, Stephanie
Next: EPICS build system, RELEASE file, and relative paths Angus Gratton
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
Navigate by Thread:
Prev: Re: Epics driver using BLT or CBLT to read FIFO wanted Michael Davidsaver
Next: Re: Epics driver using BLT or CBLT to read FIFO wanted Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·