g+
g+ Communities
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  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Dev lib off-board register access
From: "Rees, NP \(Nick\)" <nick.rees@diamond.ac.uk>
To: <tech-talk@aps.anl.gov>
Date: Thu, 13 Jul 2006 10:50:24 +0100
This is really a follow-up to the 2002 thread on PowerPC caching:

http://www.aps.anl.gov/epics/tech-talk/2002/msg00417.php

At Diamond we use the mvme5500. It seems that every vxWorks driver we
have will fall over at some point unless we are careful with memory
caching. Very few EPICS drivers do this properly. However, on the
mvme5500 if we precede every read with a cacheInvalidate and follow
every write routine with a cacheFlush we don't seem to have any
problems.

We have rapidly come to the conclusion that we need to have a set of
routines in devLib to handle register accesses. The two models we am
aware of is the Linux memory barrier routines, and vxWorks cacheLib
routines. I don't know about RTEMS or Windows. The Linux routines are
simpler than the vxWorks ones, but if we adopted that model we could
only implement it in vxWorks with asm directives since the Linux calls
are incompatible with cacheLib.

At the same time I suggest we should handle big/little endian issues as
well as caching. The routines of course know whether the processor CPU
is big or little endian, but they need to be told about the endian-ness
of the card they are reading or writing to.

So I suggest, as a minimum:

devGetBigEndianRegisters( volatile void * from, void * to, size_t nobj,
size_t size );
devSetBigEndianRegisters( void * from, volatile void * to, size_t nobj,
size_t size );

devGetLittleEndianRegisters( volatile void * from, void * to, size_t
nobj, size_t size );
devSetLittleEndianRegisters( void * from, volatile void * to, size_t
nobj, size_t size );

The get routines would call cacheInvalidate on vxWorks or rmb on Linux
and then read the data as nobj chunks of the given size. They would
byteswap if necessary.

The set routines would byteswap, write and then call cacheFlush on
vxWorks or wmb on Linux. If the cacheLib routines don't appear to work
on vxWorks for a particular architecture, then a read of the last data
element written might be added for that architecture (as outlined in the
above thread).

What do people think? Is this the right interface or are there other
suggestions?

I am prepared to do this for Linux and VxWorks, but I don't have access
to the other architectures. Would others be willing to take this up?

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713


Replies:
Re: Dev lib off-board register access Dirk Zimoch
Re: Dev lib off-board register access Andrew Johnson

Navigate by Date:
Prev: Re: Sequencer embedded C code question Dirk Zimoch
Next: Re: Dev lib off-board register access Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: Re: about add/delete record in process database during operation Andrew Johnson
Next: Re: Dev lib off-board register access Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·