How to use high and low bytes?
Asked Answered
E

6

20

I am trying to represent 32768 using 2 bytes. For the high byte, do I use the same values as the low byte and it will interpret them differently or do I put the actual values? So would I put something like 32678 0 or 256 0? Or neither of those? Any help is appreciated.

Esmeralda answered 22/5, 2011 at 20:25 Comment(4)
What are you trying to do? An unsigned short is 16-bits in c++, and would store numbers up to 32767.Enzymolysis
Homework, eh? :) Look here: en.wikipedia.org/wiki/Binary_numeral_system Bytes are nothing but groups of eight bits.Delora
I am trying to send a iRobot Create a command to drive straight. It says a value of "32768 or 32767" will make it drive straight. It takes in a high byte and low byte. The best I have gotten (in terms of driving straight) is 255 128, but that still turned some.Esmeralda
@Mike Bantegui A signed short stores numbers up to 32767, an unsigned short goes up to 65535.Pax
I
31

In hexadecimal, your number is 0x8000 which is 0x80 and 0x00. To get the low byte from the input, use low=input & 0xff and to get the high byte, use high=(input>>8) & 0xff.

Get the input back from the low and high byes like so: input=low | (high<<8).

Make sure the integer types you use are big enough to store these numbers. On 16-bit systems, unsigned int/short or signed/unsigned long should be be large enough.

Interfluent answered 22/5, 2011 at 20:37 Comment(4)
Or unsigned short. Generally better to use unsigned types with the >> operator.Buie
Only because two bytes are involved is it wise to assume that the 16-bit boundary will not be broken. Generally though, bit shift operators work just find with signed integers and the choice to go unsigned should have more to do with whether or not negative values are required.Interfluent
short is large enough that 32768 may overflow to -32768, and int may be the same size as short. Thus the value of 32768 >> 8 is implementation-defined.Buie
Actually, this conversation is irrelevant. I just noticed that the question is tagged 16-bit. Updating my answer accordingly...Interfluent
W
5

Bytes can only contain values from 0 to 255, inclusive. 32768 is 0x8000, so the high byte is 128 and the low byte is 0.

Writing answered 22/5, 2011 at 20:29 Comment(4)
You have a lot of reputation, but it's still not true that a byte always is exactly 8 bit wide. That, btw, is also the reason why in protocol specifications often the name "octet" is used as opposed to "byte". There are still systems around where a byte can have a size bigger than 8 bit. Also see Wikipedia: en.wikipedia.org/wiki/ByteCorkscrew
Fair enough. But I think I could count the number of modern systems that have a byte defined as something other than 8 bits on one hand.Writing
true true. I reckon in practice this often won't matter, but I think one should know the distinction. And since the question of the OP is a very basic one, I think it would be worth to mention that in an answer.Corkscrew
Always with the zebra. Horses people, horses.Thrips
I
4

Try this function. Pass your Hi_Byte and Lo_Byte to the function, it returns the value as Word.

WORD MAKE_WORD( const BYTE Byte_hi, const BYTE Byte_lo)
{
     return   (( Byte_hi << 8  ) | Byte_lo & 0x00FF );
}
Impuissant answered 7/5, 2016 at 13:38 Comment(0)
P
2

Pointers can do this easily, are MUCH FASTER than shifts and requires no processor math.

Check this answer

BUT: If I understood your problem, you need up to 32768 stored in 2 bytes, so you need 2 unsigned int's, or 1 unsigned long. Just change int for long and char for int, and you're good to go.

Pitch answered 18/1, 2017 at 23:27 Comment(0)
T
0

32768 is 0x8000, so you would put 0x80 (128) in your high byte and 0 in your low byte.

That's assuming unsigned values, of course. 32768 isn't actually a legal value for a signed 16-bit value.

Teleost answered 22/5, 2011 at 20:29 Comment(0)
A
0

32768 in hex is 0080 on a little-endian platform. The "high" (second in our case) byte contains 128, and the "low" one 0.

Aloin answered 22/5, 2011 at 20:31 Comment(1)
This is unhelpful and confusing. It introduces a second property of the bytes, relative order in memory, and fails to explain it as well as the high-order/low-order property mentioned by OP.Buie

© 2022 - 2024 — McMap. All rights reserved.