Dirk,
Starting with R3.14.9 all of the wire format conversion code was centralized
into libCom/osi/osiWireFormat.h and libCom/osi/xxx/osdWireFormat.h.
Currently, most OS use libCom/osi/defualt/osdWireFormat.h which has this
code (the only exception currently is VMS).
#if defined (_M_IX86) || defined (_X86_) || defined (__i386__) || defined
(_X86_64_) || defined (_M_AMD64)
# define EPICS_LITTLE_ENDIAN
#elif ( defined (__ALPHA) || defined (__alpha) )
# define EPICS_LITTLE_ENDIAN
#elif defined (__arm__)
# define EPICS_LITTLE_ENDIAN
#else
# define EPICS_BIG_ENDIAN
#endif
However, the potential exists to add -DCA_LITTLE_ENDIAN or
-DEPICS_BIG_ENDIAN to ARCH_DEP_CPPFLAGS as your needs dictate. The benefit
of course being that one need not modify source code in base.
PS: For certain floating point architectures that have the floating point
words in reverse order, in particular ARM net-winder-floating-point if
_ARM_NWFP_ isn't defined, you need to also define EPICS_32107654_FP_ENDIAN.
Jeff
-----Original Message-----
From: Dirk Zimoch [mailto:[email protected]]
Sent: Monday, August 27, 2007 8:03 AM
To: Peter Zumbruch; Jeff Hill
Cc: [email protected]
Subject: Re: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data
Hi Peter, Jeff,
I had the same problem with little endian Embedded Linux targets, Axis
and others. I wanted the problem solved once and for all without having
to modify the base source code for every new target.
I used 3.14.8, which handles endianess a bit different.
In ca/net_convert.h, I modified the code from
... (known targets)
#else
# define CA_FLOAT_IEEE
# define CA_BIG_ENDIAN
#endif
to
...
#else
#if !(defined(CA_FLOAT_MIT) || defined(CA_FLOAT_IEEE) )
# define CA_FLOAT_IEEE
#endif
#if !(defined(CA_LITTLE_ENDIAN) || defined(CA_BIG_ENDIAN) )
# define CA_BIG_ENDIAN
#endif
#endif
This allows to define endianess in my CONFIG.Common.linux-crisv10 file
instead of the source code:
ARCH_DEP_CPPFLAGS += -DCA_LITTLE_ENDIAN
In my opinion, the config files are a much better place to configure the
system than the source code.
The same could be done for 3.14.9 in
libCom/osi/os/default/osdWireFormat.h where we can already read:
// Perhaps the definition of EPICS_BIG_ENDIAN, EPICS_LITTLE_ENDIAN,
// and EPICS_32107654_FP_ENDIAN should be left to the build system
// so that this file need not be modified when adding support for a
// new architecture?
Modify the code to:
... (known targets)
#elif !(defined (EPICS_BIG_ENDIAN) || defined (EPICS_LITTLE_ENDIAN) )
# define EPICS_BIG_ENDIAN
#endif
Dirk
Peter Zumbruch wrote:
> Hello everybody,
>
> I am working on the port of EPICS to ETRAX CRIS architecture running
Linux.
> We are using several boards which either have Axis's chips:
> ETRAX LX100 MCM (cris_v10)
> (http://www.axis.com/techsup/dev/etrax_100lx_mcm/index.htm)
> or ETRAX FS (cris_v32)
> (http://www.axis.com/techsup/dev/etrax_100lx_mcm/index.htm)
> as a control unit on-board.
>
> I meanwhile have succeeded ( :-) ) in compiling EPICS 3.14.9 on a
> linux-x86 host-system for those two architectures:
>
> - The CONFIG files needed to be create are documented at:
> linux-cris_10:
>
> http://wiki.gsi.de/Epics/ConfigurationEpicsCrossCompileLinuxCrisV10
> linux-cris_32:
>
> http://wiki.gsi.de/Epics/ConfigurationEpicsCrossCompileLinuxCrisV32
> where exclusively linux-cris files have been modified/created.
>
> - Changes in CONFIG_SITE.linux-x86.Common:
> CROSS_COMPILER_TARGET_ARCHS = linux-cris_v10 linux-cris_v32
>
> - The cross-compiler used is a gnu-compiler provided by axis:
> cris-gcc --version: cris-axis-elf-gcc (GCC) 3.2.1 Axis release
> R64/1.64
>
> - The file "$EPICS-BASE/src/libCom/osi/default/osdWireFormat.h"
> has been extended by those two lines to comply for the
> little-endianness :
>
> #elif defined (_cris_)
> # define EPICS_LITTLE_ENDIAN
>
> - The optimization -O3 had to be replaced by -Os or the default -O0
> to be able to compile.
>
> Also the example Application created via
> |$EPICS_BASE/bin/linux-x86/makeBaseApp.pl
> |compiles ||meanwhile without problems.
>
> Copied to the target system (cris_v10 Target) the IOC starts up
thoroughly.
> "dbl, dbpr, etc" applied to all given records seem to work.
>
>
> But,
> pardon me for the long introduction,
> (either locally or remotely) looking with a client application to the
> the values the data are corrupted:
>
> using *camonitor* gives for aiExample2
> (normally having a counter running from 0 to 9):
>
> zumbruchHost:aiExample2 2007-08-22 20:08:32.843735 4.33197e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:34.853797 0 ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:36.864724 3.03865e-319
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:38.873781 3.16202e-322
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:40.883986 1.04347e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:42.894597 2.05531e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:44.903989 2.56124e-320
> zumbruchHost:aiExample2 1904-10-15 19:11:38.551617 3.06716e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:48.924495 3.57308e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:50.933987 4.07901e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:08:52.944423 4.33197e-320
> ?? ??
> zumbruchHost:aiExample2 1909-01-16 05:53:46.278750 0 ?? ??
> zumbruchHost:aiExample2 1910-02-08 14:34:18.543753 3.03865e-319
> ?? ??
> zumbruchHost:aiExample2 1911-03-03 23:14:50.955094 3.16202e-322
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:09:00.984164 1.04347e-320
> ?? ??
> zumbruchHost:aiExample2 1913-04-18 16:35:54.407488 2.05531e-320
> ?? ??
> zumbruchHost:aiExample2 1914-05-12 01:16:26.675635 2.56124e-320
> zumbruchHost:aiExample2 2007-08-22 20:09:07.014232 3.06716e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:09:09.024221 3.57308e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:09:11.034747 4.07901e-320
> ?? ??
> zumbruchHost:aiExample2 2007-08-22 20:09:13.044186 4.33197e-320
> ?? ??
> zumbruchHost:aiExample2 1919-09-04 20:39:06.413164 0 ?? ??
>
> for comparison a similar well running application ("What it should look
> like")
>
> zumbruch2Host:aiExample2 2007-08-22 20:08:32.613470 1 LOLO MAJOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:34.615208 2 LOLO MAJOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:36.617301 3 LOW MINOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:38.618697 4 LOW MINOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:40.620584 5
> zumbruch2Host:aiExample2 2007-08-22 20:08:42.622103 6 HIGH MINOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:44.623496 7 HIGH MINOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:46.624957 8 HIHI MAJOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:48.627479 9 HIHI MAJOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:50.629924 0 LOLO MAJOR
> zumbruch2Host:aiExample2 2007-08-22 20:08:52.631170 1 LOLO MAJOR
>
> The same for *ca_test*:
>
> name: zumbruchHost:aiExample2
> native type: DBR_DOUBLE
> native count: 1
> DBR_STRING 3
> DBR_SHORT 768
> DBR_FLOAT 0.0000
> DBR_ENUM 768
> DBR_CHAR 3
> DBR_LONG 50331648
> DBR_DOUBLE 0.0000
> DBR_STS_STRING 1536 256 Value: 3
> DBR_STS_SHORT 1536 256 Value: 768
> DBR_STS_FLOAT 1536 256 Value: 0.0000
> DBR_STS_ENUM 1536 256 Value: 768
> DBR_STS_CHAR 1536 256 Value: 3
> DBR_STS_LONG 1536 256 Value: 50331648
> DBR_STS_DOUBLE 1536 256 Value: 0.0000
> DBR_TIME_STRING 1536 256 TimeStamp: 1901/12/13 21:45:52.547135
> Value: 3
> DBR_TIME_SHORT 1536 256 TimeStamp: 1901/12/13 21:45:52.547135
> Value: 768
> DBR_TIME_FLOAT 1536 256 TimeStamp: 1901/12/13 21:45:52.547135
> Value: 0.0000
> DBR_TIME_ENUM 1536 256 TimeStamp: 1901/12/13 21:45:52.547135
> Value: 768
> DBR_TIME_CHAR 1536 256 TimeStamp: 1901/12/13 21:45:52.547135
> Value: 3
> DBR_TIME_LONG 1536 256 TimeStamp: 1901/12/13 21:45:52.547135
> Value: 50331648
> DBR_TIME_DOUBLE 1536 256 TimeStamp: 1901/12/13 21:45:52.547135
> Value: 0.0000
> DBR_GR_STRING 1536 256 Value: 3
> DBR_GR_SHORT 1536 256 Counts
> 2560 0 2048 1536 1024 512 Value: 768
> DBR_GR_FLOAT 1536 256 Counts 0
> 0.000 0.000 0.000 0.000 0.000 0.000 Value:
> 0.0000
> DBR_GR_ENUM 1536 256 Value: 768
> DBR_GR_CHAR 1536 256 Counts
> 10 0 8 6 4 2 Value: 3
> DBR_GR_LONG 1536 256 Counts
> 167772160 0 134217728 100663296 67108864 33554432
> Value: 50331648
> DBR_GR_DOUBLE 1536 256 Counts 0
> 0.000 0.000 0.000 0.000 0.000 0.000 Value:
> 0.0000
> DBR_CTRL_STRING 1536 256 Value: 3
> DBR_CTRL_SHORT 1536 256 Counts
> 2560 0 2048 1536 1024 512
> 2560 0 Value: 768
> DBR_CTRL_FLOAT 1536 256 Counts 0
> 0.000 0.000 0.000 0.000 0.000 0.000 0.000
> 0.000 Value: 0.0000
> DBR_CTRL_ENUM 1536 256 Value: 768
> DBR_CTRL_CHAR 1536 256 Counts
> 10 0 8 6 4 2
> 10 0 Value: 3
> DBR_CTRL_LONG 1536 256 Counts
> 167772160 0 134217728 100663296 67108864 33554432
> 167772160 0 Value: 50331648
> DBR_CTRL_DOUBLE 1536 256 Counts 0
> 0.000 0.000 0.000 0.000 0.000 0.000 0.000
> 0.000 Value: 0.000000
> DBR_STSACK_STRING 1536 256 256 512 3
> DBR_CLASS_NAME ai
>
> and what it should look like:
>
> name: zumbruch2Host:aiExample2
> native type: DBR_DOUBLE
> native count: 1
> DBR_STRING 3
> DBR_SHORT 3
> DBR_FLOAT 3.0000
> DBR_ENUM 3
> DBR_CHAR 3
> DBR_LONG 3
> DBR_DOUBLE 3.0000
> DBR_STS_STRING 6 1 Value: 3
> DBR_STS_SHORT 6 1 Value: 3
> DBR_STS_FLOAT 6 1 Value: 3.0000
> DBR_STS_ENUM 6 1 Value: 3
> DBR_STS_CHAR 6 1 Value: 3
> DBR_STS_LONG 6 1 Value: 3
> DBR_STS_DOUBLE 6 1 Value: 3.0000
> DBR_TIME_STRING 6 1 TimeStamp: 2007/08/22 20:15:16.962527 Value: 3
> DBR_TIME_SHORT 6 1 TimeStamp: 2007/08/22 20:15:16.962527 Value: 3
> DBR_TIME_FLOAT 6 1 TimeStamp: 2007/08/22 20:15:16.962527 Value:
> 3.0000
> DBR_TIME_ENUM 6 1 TimeStamp: 2007/08/22 20:15:16.962527 Value: 3
> DBR_TIME_CHAR 6 1 TimeStamp: 2007/08/22 20:15:16.962527 Value: 3
> DBR_TIME_LONG 6 1 TimeStamp: 2007/08/22 20:15:16.962527 Value: 3
> DBR_TIME_DOUBLE 6 1 TimeStamp: 2007/08/22 20:15:16.962527 Value:
> 3.0000
> DBR_GR_STRING 6 1 Value: 3
> DBR_GR_SHORT 6 1 Counts
> 10 0 8 6 4 2 Value: 3
> DBR_GR_FLOAT 6 1 Counts 0
> 10.000 0.000 8.000 6.000 4.000 2.000 Value:
> 3.0000
> DBR_GR_ENUM 6 1 Value: 3
> DBR_GR_CHAR 6 1 Counts
> 10 0 8 6 4 2 Value: 3
> DBR_GR_LONG 6 1 Counts
> 10 0 8 6 4 2 Value: 3
> DBR_GR_DOUBLE 6 1 Counts 0
> 10.000 0.000 8.000 6.000 4.000 2.000 Value:
> 3.0000
> DBR_CTRL_STRING 6 1 Value: 3
> DBR_CTRL_SHORT 6 1 Counts
> 10 0 8 6 4 2
> 10 0 Value: 3
> DBR_CTRL_FLOAT 6 1 Counts 0
> 10.000 0.000 8.000 6.000 4.000 2.000 10.000
> 0.000 Value: 3.0000
> DBR_CTRL_ENUM 6 1 Value: 3
> DBR_CTRL_CHAR 6 1 Counts
> 10 0 8 6 4 2
> 10 0 Value: 3
> DBR_CTRL_LONG 6 1 Counts
> 10 0 8 6 4 2
> 10 0 Value: 3
> DBR_CTRL_DOUBLE 6 1 Counts 0
> 10.000 0.000 8.000 6.000 4.000 2.000 10.000
> 0.000 Value: 3.000000
> DBR_STSACK_STRING 6 1 1 2 3
> DBR_CLASS_NAME ai
>
> Could somebody give me an advice where else to look at?
>
> Thanks in advance,
> Peter
>
--
Dr. Dirk Zimoch
Paul Scherrer Institut, WBGB/006
5232 Villigen PSI, Switzerland
Phone +41 56 310 5182
- References:
- Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Peter Zumbruch
- Re: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Dirk Zimoch
- Navigate by Date:
- Prev:
RE: PV name changes and epics extensions Rock, Judith E.
- Next:
RE: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data 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
- Navigate by Thread:
- Prev:
RE: Port of EPICS 3.14.9 to ETRAX CRIS architecture - Strange Data Jeff Hill
- Next:
Eagle drivers anyone? Heinrich du Toit
- 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
|