36

I'm reading a packet with a length of 133 bytes from the serialport, the last 2 bytes contain the CRC values, 2 byte values I've made single (short I think) using Java.

This what I have done:

short high = (-48 & 0x00ff);
short low = 80;

short c = (short) ((high << 8) + low);

But I'm not getting the correct result. Is it a problem because of the use of signed values? How can I solve this problem?

jps
  • 20,041
  • 15
  • 75
  • 79

6 Answers6

69

Remember, you don't have to tie yourself in knots with bit shifting if you're not too familiar with the details. You can use a ByteBuffer to help you out:

ByteBuffer bb = ByteBuffer.allocate(2);
bb.order(ByteOrder.LITTLE_ENDIAN);
bb.put(firstByte);
bb.put(secondByte);
short shortVal = bb.getShort(0);

And vice versa, you can put a short, then pull out bytes.

By the way, bitwise operations automatically promote the operands to at least the width of an int. There's really no notion of "not being allowed to shift a byte more than 7 bits" and other rumours that seem to be going round.

Neil Coffey
  • 21,615
  • 7
  • 62
  • 83
  • you're right, it does promote to int so shift by 7 is ok. But << 32 is undefined so it does nothing. – CookieOfFortune Apr 10 '09 at 06:07
  • I find that 'converting' buffer of 8192 size takes almost forever when debugger is attached to the device. Is there a way to convert whole buffer in one go? – Daniel Mošmondor Mar 27 '13 at 13:40
  • 2
    RE: "you don't have to tie yourself in knots with bit shifting"; in my experience (and it's quite considerable since most of my career is in comms), when dealing with comms protocols of this ilk you'd better get darn familiar with bit manipulations. – Lawrence Dol Apr 10 '14 at 17:33
  • 1
    Lawrence - I'd broadly agree. But on the other hand, in this specific case the ByteBuffer class provides an API specifically designed to do what the poster is trying to do... – Neil Coffey Apr 11 '14 at 04:13
  • 1
    A very well-placed, well-suited hammer... Ya know, for when the question isn't so trivial – Blake Neal Jun 07 '18 at 19:03
  • Yes, this works. But it is slower than the direct conversion. – Luis A. Florit May 28 '22 at 01:36
  • @LuisA.Florit - It theoretically will. But if you're only doing it once to check a CRC, the extra couple of nanoseconds probably won't matter :) In other cases... it will depend a bit on the situation. In use cases where you're converting a lot of values on a data stream, it is likely to be more convenient to use a ByteBuffer anyway, and the JIT compiler is in principle designed to optimise away the method call. (But you'd need to time in practice if it was performance-critical..) – Neil Coffey May 28 '22 at 04:32
  • @NeilCoffey My use case was to read a 1 minute 16 bit PCM audio file and extract the shorts to show a waveform. Direct conversion showed the waveform with no perceptible delay, while this method took around a second or so to show it (in a Galaxy Note 10). – Luis A. Florit May 28 '22 at 12:38
35

When converting byte values from a stream into numeric values in Java you have to be very careful with sign extension. There is a trap with negative numbers (values from (unsigned) 128-255).

Try this (it works if hi and lo are any Java integer type) :

short val=(short)(((hi & 0xFF) << 8) | (lo & 0xFF));

I find it's best to be explicit with the parentheses in these cases.

Lawrence Dol
  • 63,018
  • 25
  • 139
  • 189
14

This happens when trying to concatenate bytes (very subtle)

byte b1 = (byte) 0xAD;
byte b2 = (byte) 0xCA;
short s = (short) (b1<<8 | b2);

The above produces 0xFFCA, which is wrong. This is because b2 is negative (byte type is signed!), which means that when it will get converted to int type for the bit-wise | operation, it will be left-padded with 0xF!

Therefore, you must remember to mask-out the padded bytes so that they will definitely be zero:

short s = (short) (b1<<8 | b2 & 0xFF);
Lake
  • 4,072
  • 26
  • 36
11

The other answers are OK, but I would like to put an emphasis on the type:

short high=(-48 & 0x00ff);
short low=80;

int c= ((high & 0xFF) << 8) | (low & 0xFF);

The short type can represent values between -32768 to 32767. 53328 cannot be nicely stored in short, use int instead as it allows you to store unsigned value up to ~109 So don't downcast the expression to short as it will net you the signed value.

akarnokd
  • 69,132
  • 14
  • 157
  • 192
  • Though, when dealing with 16 bit CRC's you only need the correct bit pattern; it matters not if the final Java value is signed. – Lawrence Dol Apr 10 '14 at 17:30
  • thanks, I used `& 0x00FF` from the first line to convert an unsigned byte to a short. for example, setting 0x87 to a short gave -121 instead of the intended 135. – wrapperapps Feb 14 '18 at 22:19
8

You can convert 2 bytes to a short in a more readable and elegant way.

short s = ByteBuffer.wrap(new byte[]{0x01, 0x02}).getShort();
// now s equals 258 = 256 + 2

The first byte is the most significant byte.

Mariusz Wiazowski
  • 2,118
  • 1
  • 16
  • 17
  • in my tests, this is faster than manual conversion or the other answer here using ByteBuffers (with fixed allocation). – brimborium Jul 15 '21 at 14:13
0

This works for me

short temp = ;
result[0] = (byte) ((temp >>> 8) & 0xFF);
result[1] = (byte)((temp) & 0xFF);
Pwn
  • 308
  • 3
  • 9