EPICS Home EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

Format page
for printing


Search Tech-talk
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  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 
<== Date ==> <== Thread ==>
Subject: Re: Dev lib off-board register access
From: Eric Bjorklund <[email protected]>
To: EPICS tech-talk <[email protected]>
Date: Fri, 14 Jul 2006 09:49:38 -0600
Hi Kate,

On Jul 14, 2006, at 7:45 AM, Kate Feng wrote:

Eric Bjorklund wrote:

.

In my experience I have usually been able to always get non-DMA drivers to work by always declaring the register pointer as "volatile" (which is more to defeat compiler optimization and not really a caching issue) and following the last write with a dummy read to the same register (to flush the pipeline).

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 ?


This is pretty much the case for any PPC using the Universe or Tempe VME bridge. But my statement wasn't quite complete. As Andrew pointed out, write posting ("pipeline") is mostly a problem with ISR's issuing a write to clear the IRQ line and the write not actually happening until after the ISR returns (as Andrew also pointed out, the dummy read does not really have to be to the same register). So if your VME board doesn't interrupt, you probably don't need to worry about it.

At NSLS, we use RTEMS-MVME5500 BSP that I developed, which
enables the hardware cache snoop on CPU local memory for all the
DMA applications so that the sofware caching is not needed yet.
However, the VME space is marked as Non-Cacheable and
Guarded in the BSP.


I believe it is hardware caching that we've been talking about. The "software" part refers to system routines in vxWorks (and probably in RTEMS too) that talk to the MMU to either invalid or flush the hardware cache (depending on whether your DMA is reading or writing). These routines are, of necessity, system-dependent, and it would be nice to have devLib implementations so that DMA device drivers could be more portable.

-Eric Bj.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Eric Björklund
Los Alamos Neutron Science Center (LANSCE)

phone: 505-667-6031 email: [email protected]
<><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Correspondence
Replies:
Re: Dev lib off-board register access Jukka Pietarinen
Re: Dev lib off-board register access Andrew Johnson
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
Navigate by Date:
Prev: Re: Dev lib off-board register access Andrew Johnson
Next: Re: Dev lib off-board register access Jukka Pietarinen
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: Dev lib off-board register access Kate Feng
Next: Re: Dev lib off-board register access Jukka Pietarinen
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 
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 ·