EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: floating point problem in CA?
From: "Jeff Hill" <[email protected]>
To: "'Heinrich du Toit'" <[email protected]>, "'EPICS Techtalk'" <[email protected]>
Date: Thu, 28 Feb 2008 13:02:19 -0700
Hello Heinrich,

Are you running Linux on your arm? Certain arm processors store the 8 byte
IEEE floating point values in middle endian format. If you have the latest
EPICS base I seem to recall that, on Linux, the configuration for
EPICS_FLOAT_WORD_ORDER comes from sys/parm.h and that you need not do any
special to get it to work (unless we have it coded wrong :). The relevant
code is in libCom/osi/default/osdWireFormat.h.

Jeff

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Heinrich du Toit
> Sent: Thursday, February 28, 2008 8:52 AM
> To: EPICS Techtalk
> Subject: floating point problem in CA?
> 
> Hi
> 
> This is weird and I'm not really sure how to track it down.
> 
> I have an embedded ARM board. I've compiled EPICS onto that.
> 
> I run vlinac (just to get something ) on my host PC (x86)
> 
> Then I take an ai variable. (in other words a floating point thing)
> 
> If I say from the ARM board caput  pvname value
> Then the correct value gets into the pv on my host pc.
> But.. the wrong value gets back via channel access.
> if I caget the value I get the wrong answer.
> 
> It seems that the network byte order is done wrongly maybe.. I'm not sure.
> If I put 1.0
> and then get again I get: 5.29981e-315
> 
> Which is almost like the wrong network byte order but not exactly it
seems.
> It could be that somewhere along the lines something thinks double is 6
> bytes only (rather than 8) and then also swaps the byte order.
> 
> Maybe there is an htons or something missing somewhere in the code?
> But how this is possible baffles me. :/
> 
> I've written a small program to test the structure and layout off
> "double" on both my PC and the ARM. it seems identical to me.
> 
> If anybody has any idea how I can "check" this or try and find the
> problem it would be help full.
> I am aware that the problem is not necessarily in epics but could be in
> the compiler options or something like that.
> 
> 
> thanks
> -Heinrich


References:
floating point problem in CA? Heinrich du Toit

Navigate by Date:
Prev: RE: floating point problem in CA? Glen Wright
Next: FW: floating point problem in CA? Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: floating point problem in CA? Glen Wright
Next: Re: floating point problem in CA? Heinrich du Toit
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  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 ·