Decimal to hex conversion and beyond

Rsadeika

What the program below does is converts a decimal number to hex, and then converts the hex back to a decimal number, verifies that the conversion is correct.

What I really want to accomplish is convert feet to mm, convert it to a hex, convert upper byte and lower byte back too decimal contained in separated variables. As an example:
6' * (12*25.4)= 1828 mm
7 24 - conversion to hex
7 36 - conversion to decimal
upbyte = 7
lowbyte = 36
The problem that I am having is splitting the 724 into 7 and 24 for conversion back too decimal. I looked at the printf docs, and it shows '*' too declare how many characters to display, but I am not sure how that would apply too what I want too accomplish. Any help would be appreciated.

Ray

/*
  dectohex.c

*/
#include "simpletools.h"

int main()
{
  // Add startup code here.
 pause(1000);
//dec to hex
  char outStr[256];

  int inDec;
  inDec = (6 *(25.4 * 12));  // Calculates feet to mm.
  sprintf(outStr,"%X",inDec);
  printf("%d in hex is %s\n",inDec,outStr);

// Convert hex back to dec
  long int numValue;
  numValue = strtol(outStr,NULL,16);
  printf("decimal value %d\n",numValue);
 
  while(1)
  {
    // Add main loop code here.
    
  }  
}

pedward

Use:

low byte
(variable & 0xFF)

high byte
(variable >> 8) & 0xFF

Are you making a table for inclusion into a C program or a human readable table?

The computer cares not what radix you use, if you split a 2 byte value into a high and low table, it's a byte either way.

Why do you want to convert radices?

BlackSoldierB

I am not sure if this is what you want.
This code converts the input into a upperbyte and lowerbyte variable.

int lowerByte = inDec & 0xFF;   
int upperByte = inDec >> 8;
   
print("lowerByte= %d, upperByte= %d\n",lowerByte, upperByte);

Rsadeika

Thanks guys, I am getting closer but...

When I do the conversion of 1828, I get a hex value of 724, I guess each value of 724 is a byte, so, in the program, right now, I capture the 2 and 4 values. What I need to do is capture the x24 or the first two values as the lower byte, the next two values xx7 as the upper byte. Sorry for the wrong information. When I start to do some negative conversions like (-1828), then the hex values will be something like (...FFFFFF8DC), so in this case the upper byte will be F8=248 and the lower byte will be DC=220, I hope this not too confusing.

Ray

/*
  dectohex.c

*/
#include "simpletools.h"

int main()
{
  // Add startup code here.
 pause(1000);
//dec to hex
  int hbyte;
  int lbyte;
  char outStr[256];
  int bbytes;
  int numVu;
  int numVl;

  int inDec;
  inDec = (6 *(25.4 * 12));  // Calculates feet to mm.
  sprintf(outStr,"%X",inDec);
  printf("%d in hex is %s\n",inDec,outStr);

// Convert the string 'outStr' to an integer
  hbyte = atoi(outStr);  // hbyte = 724
  numVu = (hbyte >> 8) & 0xF ;
  printf("%d\n",numVu);  // numVu = 2, should be 7

  lbyte = atoi(outStr);  // lbyte = 724;
  numVl = lbyte & 0xF;
  printf("%d\n",numVl);  // numVl = 4, should be 24

pedward

What are you really trying to do?

You are working on the micro level and trying to diagnose micro problems.

Describe at the macro level what you are trying to accomplish, because what you've discussed so far sounds way off in left field.

Rsadeika

Describe at the macro level what you are trying to accomplish, ...

I am working on a robot project that has its own processor, and its own command set. What I want to do is automate a calculation for some of its commands, for instance:
opcode: 156
serial sequence:[156] [Distance high byte] [Distance low byte]
Distance data bytes 1-2: 16-bit signed distance in mm, high byte first (-32767 - 32768)
Example, 40 cm travel: [156] [1] [144]
There are at least five other commands that use this format, so I will need this to be automated within the C control program that I am working on. For the time being I am doing a manual calculation for the values needed, but as this project moves along, and I decide too keep pursuing this, I will have too automate.

At the moment I am testing too see if this would be a good choice for an autonomous robot. At the moment I am using the PropBOE board because I can pick up 18V @ 1.5A power source, from the robot, which would be sufficient to power a Raspberry Pi, via the PropBOE, for an additional processing source. I still have a lot of testing to do before I can make a decision as to whether this robot could be used. So, as you can see, I can use all the help I can get on this one.

Thanks
Ray

Rsadeika

low byte
(variable & 0xFF)

high byte
(variable >> 8) & 0xFF

I think I came up with a solution, by accident of course, but first can somebody explain to me the magic of 'variable & 0xFF' and (variable >> 8) & 0xFF'. For instance if I use a variable like 255 then I get, high byte- 0, low byte- 255, but if I use 256 then I get, high byte- 1, low byte- 0. What kind of black magic is this?:-)

Ray

mindrobots

Rsadeika wrote: »

I think I came up with a solution, by accident of course, but first can somebody explain to me the magic of 'variable & 0xFF' and (variable >> 8) & 0xFF'. For instance if I use a variable like 255 then I get, high byte- 0, low byte- 255, but if I use 256 then I get, high byte- 1, low byte- 0. What kind of black magic is this?:-)

Ray

if you use 16 bits to represent it, 255 decimal is 0x00FF and 256 is 0x0100 - now do your masking and shifting

variable & 0xff is 0x00ff & 0xff yields 0xff which is 255

00FF
00FF

---

AND
00FF

with variable = 0x0100, (variable >> 8) gives you 0x0001 in variable, then variable & 0x00FF give you 0x0001

0001
00FF

---

AND
0001

It's not black magic, just how binary and logical operators work and in this case you are using hexdecimal, so you work in 4 bit nibble for each hex digit, you can work in binary or octal if you'd prefer.

Rsadeika

Below is the code for getting a high and low byte, in this example, for 400. Now how do you reverse the process to get a number from an incoming high and low byte? Using the numbers below, high byte 1, low byte 144, how do you get that back too 400? This may not be as straight forward as the previous conversion, or is it.

Ray

int numVu;
int numVl;

int hbyte = 400;
int lbyte = 400;

  numVu = (hbyte >> 8) & 0xFF ;
  printf("%d\n",numVu);   // High byte = 1
  numVl = lbyte & 0xFF;
  printf("%d\n",numVl);   // Low byte = 144

Mike G

Now how do you reverse the process to get a number from an incoming high and low byte?

Just reverse the process...

* Shift the high byte left 8 times
* OR the high and low byte.

1 << 8 = 0x0100
0x0100 OR 0x90 = 0x0190 = 400

Rsadeika

I added this part:

int numOn;
  numOn = ((numVu << 8) + numVl);
  printf("%d\n",numOn);  // numOn = 400

and that seems to be working correctly. Is this the way it is supposed to work? Or is this just a coincidental outcome? I tried some other numbers besides the 400, and it seems to be resulting as expected.

If this is a correct interpretation of getting the high byte and low byte, and then reversing the process to get the original number back, I have not seen this done in Spin, maybe a Spin expert could show how this would be done in Spin?

Ray

int numVu;
int numVl;

int hbyte = 400;
int lbyte = 400;

  numVu = (hbyte >> 8) & 0xFF ;
  printf("%d\n",numVu);   // High byte = 1
  numVl = lbyte & 0xFF;
  printf("%d\n",numVl);   // Low byte = 144

int numOn;
  numOn = ((numVu << 8) + numVl);
  printf("%d\n",numOn);  // numOn = 400

Mike G

Is this the way it is supposed to work? Or is this just a coincidental outcome?

Ray, of course it works! It's basic arithmetic. I think there's some confusion because you're mixing base10 numbers with base2 arithmetic.

Shifting a base2 number to the left one time is the same as multiplying by 2.
%0010 (2)
%0100 (4)

Shifting a base2 number to the left 8 times is the same thing as multiplying by 256. In post #10 we could have multiplied by 256 instead of shifting.
%0000_0000_0000_0001 = 0x0001 = 1
%0000_0001_0000_0000 = 0x0100 = 256

Shifting a base10 number to the left is the same as multiplying by 10.
05
50

Rsadeika

Ray, of course it works! It's basic arithmetic. I think there's some confusion because you're mixing base10 numbers with base2 arithmetic.

Thanks Mike G for the excellent additional, no pun intended, explanation. Yep, it looks like I am having a terrible time with baseX number 'rithmetic. Luckily there isn't any base8 being thrown into the mix, then I would definitely have too take more naps.:-) This has been a very good insight into why I am avoiding PASM.

Ray