Experimental Physics and Industrial Control System
In recent versions of base EPICS_CONVERSION_REQUIRED is set typically in
"base/src/libCom/osi/os/default/osdWireFormat.h". It is defined only if byte
swapping is needed or if the local floating point format isn't IEEE FP.
I will defer your other questions to Janet.
Jeff
#if EPICS_BYTE_ORDER != EPICS_ENDIAN_BIG || EPICS_FLOAT_WORD_ORDER !=
EPICS_BYTE_ORDER
# if ! defined ( EPICS_CONVERSION_REQUIRED )
# define EPICS_CONVERSION_REQUIRED
# endif
#endif
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Heinrich du Toit
> Sent: Thursday, February 28, 2008 10:55 PM
> Cc: EPICS Techtalk
> Subject: Re: floating point problem in CA?
>
> Thanks for all your help guys...
>
> In the end it seemed that I had to get -mcpu=arm9 to the compiler.
> I also added -marm but I'm not sure what it does really.
> Seems that without -mcpu=arm9 the compiler doesn't generate correct
> 8-bit codes and that means that some of the conversions doesn't work
> correctly. In convert.cpp I think.
>
>
> So my last question is.
> Where exactly SHOULD I put there command in the config files?
>
> Currently I've put:
> ARCH_DEP_CFLAGS += -mcpu=arm9 -marm
> ARCH_DEP_CPPFLAGS += -mcpu=arm9 -marm
> inside os/CONFIG.Common.linux-arm
>
>
> A few other things I don't understand:
> in convert.cpp there is EPICS_CONVERSION_REQUIRED...
> where is this actually controlled - on or off??
>
> I had to disable the "export GCC_EXEC_PREFIX" in the epics config files
> before my compiler decided to actually find cc1.
> weird.
>
>
>
> Heinrich du Toit wrote:
> > 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
- Re: floating point problem in CA? Heinrich du Toit
- Navigate by Date:
- Prev:
Re: Initialize multi-element field Benjamin Franksen
- Next:
Record loop issue Emmanuel Mayssat
- 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: floating point problem in CA? Heinrich du Toit
- Next:
FW: floating point problem in CA? Jeff Hill
- 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