[psas-software] CanMessage byte-order
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
> 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
> 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
> 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 -
> 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/
> psas-software mailing list
> psas-software at lists.psas.pdx.edu
More information about the psas-avionics