2 bytes to short

Question

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?

Trapper

Is there a particular reason you use short instead of int? Isn't your CRC value unsigned? – Weider

Answer 1

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.

Petiole

you're right, it does promote to int so shift by 7 is ok. But << 32 is undefined so it does nothing. – Fracture

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? – Quentin

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. – Saltzman

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... – Petiole

A very well-placed, well-suited hammer... Ya know, for when the question isn't so trivial – Male

Yes, this works. But it is slower than the direct conversion. – Dc

@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..) – Petiole

@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). – Dc

Answer 2

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.

Saltzman

You don't need the casts to int, that happens implicitly for the & operations. – Contrary

In my setup/tests, this is the fastest. +1. – Dc

Answer 3

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);

Illogic

Answer 4

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 ~10⁹ So don't downcast the expression to short as it will net you the signed value.

Weider

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. – Saltzman

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. – Janka

Answer 5

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.

Decorate

in my tests, this is faster than manual conversion or the other answer here using ByteBuffers (with fixed allocation). – Tamra

Answer 6

This works for me

short temp = ;
result[0] = (byte) ((temp >>> 8) & 0xFF);
result[1] = (byte)((temp) & 0xFF);

Inguinal