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
- Replies:
- RE: floating point problem in CA? Jeff Hill
- References:
- floating point problem in CA? Heinrich du Toit
- Navigate by Date:
- Prev:
Re: floating point problem in CA? Andrew Johnson
- Next:
Re: Initialize multi-element field Benjamin Franksen
- 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? Jeff Hill
- Next:
RE: 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
|