EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Dev lib off-board register access
From: Kate Feng <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS tech-talk <[email protected]>
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  2018  2019  2020  2021  2022  2023  2024 
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  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·