Experimental Physics and
Industrial Control System

"Allison, Stephanie" <[email protected]> · Thu, 6 Sep 2012 14:51:38 -0700

Hi Michael,

Does it make sense to add epicsDma to devLib2 or should it be in another module?  epicsDma comes from the GTR (generic transient recorder, aka, digitizer) module.  Till provided SLAC with an RTEMS layer under epicsDma to supplement the vxWorks implementation.  Eric Norum would have give permission to move epicsDma from GTR to devlib2.   GTR would then require devlib2 to build.  

Thank you,
Stephanie

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Davidsaver, Michael
> Sent: Thursday, September 06, 2012 2:33 PM
> To: [email protected]
> Subject: RE: Epics driver using BLT or CBLT to read FIFO wanted
> 
> 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
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System