converting 8 bits to 16bits and divi up the bits.

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wan't to convert a char of 8 bits to a short so that I get a total of -32767 to 32767. Basically stretching it.

If i just simply shift by 8 I get 0xff00, not 0xffff as expected. So to get the full values do I just add ff to it?

Y - value>>8 + value //didn't seem to work right.

Last Edited: Sat. Jun 21, 2014 - 10:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you add 0x00ff to it, then it does not have a minimum value of 0.

Just face it, 0xff00 is the largest 16 bit number you can get with only 8 "active" bits.

You could just duplicate the original 8 bits in the upper 8 AND the lower 8 of the 16 bit value. That would result in a linear mapping that extends all the way from 0x0000 to 0xffff.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Basically loosing precision and stretching it.
Why do you think you would be loosing precision?
Quote:
If i just simply shift by 8 I get 0xff00, not 0xffff as expected.
Why would you expect 0xffff? 0xff is 127. Shifting that by 8 is equivalent to multiplying by 256. 127 times 256 is 32512 not 32767.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok right, makes sense.

Last Edited: Sat. Jun 21, 2014 - 10:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi, correct I was not thinking right at first. Been working on this too long. I didnt mean to say loosing but rather not getting the full precision I could.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok now I just need to figure out why my packets are not working.

y= (reportBuffer[Y_MAIN_STICK] << 7)
XreportBuffer[14] = (y >> 8);
XreportBuffer[15] = (y & 0xff);

also tried

y= (reportBuffer[Y_MAIN_STICK] << 7) + reportBuffer[Y_MAIN_STICK];
XreportBuffer[14] = (y >> 8);
XreportBuffer[15] = (y & 0xff);

something is not right.

Last Edited: Sun. Jun 22, 2014 - 03:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, the method I suggested results in WORSE resolution. If you go from 8-bit values of 0x00 to 0x01, the 16-bit value would go from 0x0000 to 0x0101 for a change of 0x0101 between each 8-bit count. That is because you are stretching s56 8-bit values over the 16-bit span of 0 to 65525.

If, instead, you simply multiply each 8-bit value by 256 (left sift 8 times), each successive 16-bit value differs by only 0x0100. That is because you are stretching the 266 8-bit values over the span of 0 to 65280.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


255 * 257 = 65535
255 * (256 + 1) = 65535

uint8_t foo;
uint16_t bar;
.
.
.
bar = (foo<<8) + foo;

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim, I don't follow you but I'm interested. I read that as left shifting each bit in the byte by 8?

eightBitValue.btt0 <<= 8
eightBitValue.btt1 <<= 8
eightBitValue.btt2 <<= 8
ect...

That's not what you mean though right?

joeymorin, that is the example I was basing my original though off of. In the short of it I have 255 levels and I need to stuff it in to -32767 to 32767. then figure out that packet problem.

Last Edited: Sun. Jun 22, 2014 - 03:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, not certain what YOU mean!

Multiply by 256 is same as left-shifting the whole 8-bit byte left 8 times.

That is, 0b10010001 would become 0b1001000100000000.

Either way, whether you send 0b10010001 as 0b1001000100000000 or send it as 0b10010001, you have exactly the same resolution because you have only 256 distinct values. It does not matter how you spread those values out, you still only have 256 values, no more, no less.

You have the appearance of loosing resolution when you do the left-shift. But, that is an illusion because you still have exactly 256 different values.

Why do you need to do anything more than 0xAB -> 0x00AB?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ah so you mean I get a better spread, interesting. That could work out better, depends if the target machine has calibration or not. I'll look in to that thx!

Why do you need to do anything more than 0xAB -> 0x00AB?

Well again that depends on how the machine reads it and if I can calibrate.

machine = xbox BTW.

I think it's self calibrating when the controller is inserted. I need to be sure the user can hit absolute min and absolute max however I do it.

Thx for explaining that, that concludes the first part of my confusion.

Last Edited: Sun. Jun 22, 2014 - 03:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As far as C is concerned, , 0x00ff and 0xff represent exactly the same numeric value. What really happens, under the hood, depends on the native word size - 8, 16, 32, or 64. You have no control over that. But the OS should make all that invisible to you and you should not have to care (unless you are reading/writing hardware registers).

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well in this case the communication is done via usb so the xbox will gather data from the controller. The usb client in the controller would read the registers in a real environment but this is a simulation, so I should be ok(all software).