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: [email protected] [[email protected]] on behalf of Davidsaver, Michael [[email protected]]
Sent: Thursday, September 06, 2012 4:32 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(®isters_->irq_control_status_reg,
> > SIS3820_IRQ_SOURCE4_DISABLE);
> >
> > and this:
> > - firmwareVersion_ = registers_->moduleID_reg & 0x0000FFFF;
> > + firmwareVersion_ = readReg32( ®isters_->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
<2012>
2013
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 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
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|