• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Endian-ness - Serial Port

 
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,

I'm putting together an app to talk to a piece of hardware connected to the PC via the serial port. Understanding what the device is sending back is not easy at the moment and it occurred to me that maybe endian-ness is an issue when reading byes of data from the hardware buffer - i.e. if the hardware is sending little endian bytes? Can anyone comment, I might be talking rubbish, I'm out of my depth with this one as I'm really a web developer who's been roped in to helping out on this project?
 
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the little-endian vs big-endian is definitely a possible problem.

I found a website that offers a solution for switching between the two:
http://www.rgagnon.com/javadetails/java-0007.html



also, it may be worth it to find a copy of the book Java I/O (granted, it may be out of date now...) but the table of contents lists something about little / big endian stuff and this interview with the author also points out that he covers it.
------------------
quote:
Wayner:
How could Sun enhance/extend the I/O classes?

Harold:
There's no support for little endian data, or other byte orders like VAX floating point numbers. I do, however, show readers how to write stream classes that understand these formats themselves. These classes can be connected to the standard stream classes in a straight-forward fashion.

------------------
[ June 15, 2004: Message edited by: Jessica Sant ]
 
Jessica Sant
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK... scratch all that -- I knew there had to be more recent stuff:

java.nio.ByteBuffer has a snazzy method called ByteBuffer.order(ByteOrder bo) that can take one of two orders: ByteOrder.BIG_ENDIAN or ByteOrder.LITTLE_ENDIAN.

Nonetheless -- I think the endian-ness question you had is a valid one and the hardware could definitely be sending you info back in little-endian, when Java expects to be recieving it in Big-endian.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Perhaps I am mis-interpreting the conversation and it has been a while since I messed with serial ports but as I recall, all the ended-ness at the byte level is taken care of by the serial transmission protocol at the hardware level. So the question of endedness only has to do with entities larger than a byte - at the OS level rather than the hardware level.
Bill
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
ByteBuffer is concerned with with "Endian-ness" in that it's a mechanism for stuffing non-byte objects into a linear sequence (vector) of bytes. It's the non-byte objects that produce the grief, since "word size" varies from 2 bytes to 8, with occasional forays into even more bizarre values depending on the machine and OS in question and endian-ness is likewise variable.

Actual transmission of the data would be from "left to right", or, if you prefer, in ascending index order. Lay out your data in a byte array or ByteBuffer and transmit it either as a unit or by stepping through the individual bytes and outputting them and either way, you'll not get any rude surprises from the transmission hardware (I leave the actual buffer layout surprises as an exercise ).

Don't forget - internally, Java characters are Unicode, and thus 2 bytes long!
 
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A pedantic note..JDK 1.5 supports Unicode 4, which allows range 0X0000 to 0x10FFFF - that's 2 bytes + 5 extra bits. It looks like chars are now four bytes.

I remember reading a great article that someone here linked to about Unicode 4, but I've lost the link.

...anyway, the point is, all the more reason to not use chars dealing with binary data


--Tim
 
Ben Wood
Ranch Hand
Posts: 342
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks guys. I'll try and digest this info. It looks like the endianess might not be a problem though as we now have the equipment returning valid control codes chars, although we still haven't been able to get any real data out of it. Doesn't help that this equipment is about 15 years old :roll:
 
reply
    Bookmark Topic Watch Topic
  • New Topic