EPICS Controls 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  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Epics driver using BLT or CBLT to read FIFO wanted
From: "Davidsaver, Michael" <[email protected]>
To: "[email protected]" <[email protected]>
Date: Thu, 6 Sep 2012 21:32:58 +0000
See below

> -----Original Message-----
> From: [email protected] [mailto:tech-talk-
> [email protected]] On Behalf Of Benjamin Franksen
> Sent: Thursday, September 06, 2012 4:55 PM
> To: [email protected]
> 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 Allison, Stephanie
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
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

Navigate by Date:
Prev: quadEM R3-0 now available Mark Rivers
Next: RE: Epics driver using BLT or CBLT to read FIFO wanted Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Epics driver using BLT or CBLT to read FIFO wanted Benjamin Franksen
Next: RE: Epics driver using BLT or CBLT to read FIFO wanted Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·