[psas-software] CanMessage byte-order

Ian Osgood iano at quirkster.com
Sat Jun 14 19:06:41 PDT 2003


On Friday, June 13, 2003, at 11:19 PM, Jamey Sharp wrote:

> On 06/13 08:02PM, David Cassard wrote:
>> I think the club rule on software is "shoot first and ask questions
>> later", er, no, make that "forge boldly ahead, and ask foregiveness
>> later".
>
> This is the policy I prefer, though we've heard passionate arguments
> against it. Regardless, Dave is describing a good policy once those
> changes are in place: test them, record the tests, and let the team 
> know
> what happened. Not that I'm perfect at this, of course. :-)

Once burned, twice shy.  I'll get consensus first, so there are more 
people to blame when things go wrong.  :)

>> On 06/12 11:00PM, Ian Osgood wrote:
>>> I built the recent Java apps and testers on my Mac, and found some
>>> byte-order bugs in CanMessage in the process.
>
> CanMessage is currently a 9am-after-14-hours-of-work hack to get things
> to work for Usenix.

Speaking of which, any word from Texas?

>>> I recommend using java.nio.ByteBuffer instead of
>>> java.io.ByteArrayInputStream and java.io.DataInputStream.  You can
>>> specify the endianness of the wrapped byte array
>
> The correct fix is in the C code: we just need to use network byte 
> order
> everywhere. I like the policy that someone proposed (I think it was
> Karl) of not gratuitously introducing dependencies on JDK 1.4, where
> java.nio was introduced.

Sounds good.  I was worried that not swapping before putting it into 
the socket was a design decision (avoid unnecessary processing in the 
133MHz FC computer).  I'll make that change to the net_common code and 
other C net testers.

On a related note, we are using bit fields on the C side to combine CAN 
id, RTR flag, and data length into one 16-bit word, but using shift/and 
in Java.  The C language does not guarantee the order of bit fields 
within a word in memory, so marshalling these into a short is another 
step required on the C side.  We have been lucky with the particular 
implementation of bit fields in gcc.

>>> public short getData16(int i)
>>> {
>>>     ByteBuffer bb = ByteBuffer.wrap(body);
>>>     return bb.order(ByteBuffer.LITTLE_ENDIAN).asShortBuffer().get(i);
>>> }
>
> This is interesting. The getData* methods are a little annoying right
> now, with the shift/or code. On the other hand, it's very simple code -
> four lines in the most complicated of the three cases, as I recall - 
> and
> in an idiom instantly recognizable to many programmers. The above code
> is not similarly recognizable, and doesn't seem to me to have
> significant benefits.
>
> Since I see little advantage to using java.nio here, I'd rather invoke
> the "no gratuitous dependancies" policy.

I prefer using native libraries for such things, but this is no longer 
an issue since it will be fixed on the C side.  I don't have practical 
Java experience, and didn't realize that java.nio was newfangled.

>>> Also, to be able to run Rocketview and UDPCanSocketTest on the same
>>> machine, I had to be able to specify both the local and remote ports
>>> (since they are swapped in the tester compared to Rocketview).  We
>>> should expand the tester's -port command line parameter to specify
>>> both ports.
>
> True. Have fun. :-)

You got it.  I'm similarly expanding test_net.c to accept command line 
parameters to test both TCP and UDP, client and server, and to 
configure addresses and ports.

> -- 
> Jamey Sharp <jamey at minilop.net> - http://minilop.net/
> <mime-attachment>_______________________________________________
> psas-software mailing list
> psas-software at lists.psas.pdx.edu
> http://lists.psas.pdx.edu/mailman/listinfo/psas-software




More information about the psas-avionics mailing list