Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: Dev lib off-board register access
From: Kate Feng <feng1@bnl.gov>
To: Andrew Johnson <anj@aps.anl.gov>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Fri, 14 Jul 2006 15:11:30 -0400
Andrew,

Andrew Johnson wrote:

> Kate Feng wrote:
> >
> > Do you mean the dummy read following the last write is needed for
> > only vxWorks-mvme5500 ? Or  is it  needed for almost all the powrPC
> > boards using  VxWorks ? Does it apply to all the VME boards ?
>
> A dummy read following the last write is needed for Interrupt Service
> Routines running on most CPU boards nowadays, and certainly for any
> Universe-2 based board.  Even the old 68K boards using the VMEchip2 can
> have Write Posting enabled on their VME master windows, although I don't
> think the write pipeline is anywhere near as long in that case so
> omitting the read might not cause any noticable effects.  A common
> symptoms of omitting the read is to cause suprious interrupts which will
> probably have a vector of 0xff.  These often appear to be harmless, but
> they do waste CPU time.

I clearly understood what you stated in your  first E-mail regrading the
dummy read in ISR.  I probably misunderstood Eric's message about the
dummy read.  I thought he was talking about the non-ISR related issue
on the VME universe side.  Anyway, the reason why I wanted to
clarify is that there is a cavet about the MVME5500 board, which is
due to its Discovery I system controller.  It is a  different issue from
what was discussed about the dummy read.

* Some PCI devices require Synchronization Barriers or PCI ordering
* for synchronization.  For example, the VME-OMS58 motor controller we
* used at NSLS requires either enhanced CPU Synchronization Barrier
* or PCI-ordering (only one mechanism is allowed) for the PCI-write.
* The PCI-ordering simply implements a PCI configuration read for one byte.



The implementation can be found at :
http://www.nsls.bnl.gov/facility/expsys/software/EPICS/

RTEMS-MVME5500 BSP v1.3 : pci/pci_interface.c.

The example is described at synAppRTEMS/motorApp/drvOms58.cc
and RTEMS-MVME5500 BSP v1.3/README.VME.

So far, this mechanism does not seem to be needed in any other
VME devices used in our RTEMS-MVME5500 applications. It is not needed
for the RTEMS-MVME2307 at all even for the VME-OMS58 motor controller.
In spite of the PCI sync overhead for the Oms58 motor controller, I do
not see the runtime performance of RTEMS-mvme5500 being compromised as
compared with that of RTEMS-mvme2307.


Jukka Pietarinen wrote :

> I believe it has to be the same register the write was targeted at. I
> had problems accessing indirect RAM (sequence RAM of EVG) with MVME5500
> running vxWorks.  The only solution I found was to read back the address
every time
> before reading the data.

If this is non-ISR related on the MVME5500, you might want to check out
the cavet I pointed out, which "might be" a more proper way to implement
it.  Just a suggestion since I do'nt have  your board.


Andrew Johnson wrote :

>
>
> > Is this implemented in other vxWorks-PPC  site such as APS or any
> > other facility ?  I did'nt notice this in synApp which was written by
> > APS, but I am off-site now that I can'nt verify the code.
>
> It is not really sensible to try and resolve this issue in the BSP,

???  I did'nt say   the dummy read is implemented in RTEMS BSP.

> it
> really should be the VME slave board driver's ISR that generates the
> dummy read since the BSP is probably not aware of any specific VMEbus
> addresses that it can read from (and it would not be a good idea to
> perform an access that generates a Bus Error as this would completely
> kill interrupt performance).

This is how it is implemented in RTEMS.

Kate





References:
Dev lib off-board register access Rees, NP (Nick)
Re: Dev lib off-board register access Dirk Zimoch
Re: Dev lib off-board register access Eric Bjorklund
Re: Dev lib off-board register access Kate Feng
Re: Dev lib off-board register access Andrew Johnson

Navigate by Date:
Prev: Re: Dev lib off-board register access Andrew Johnson
Next: Re: Dev lib off-board register access Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: Dev lib off-board register access Andrew Johnson
Next: Re: Dev lib off-board register access Eric Bjorklund
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·