hex/byte to int conversion

Hey, quick question. How do I convert both of these into an int (which should have a value of 123) -

  • a char[2] containing "7B" (ie as hex)

and

  • a char[1] containing "{" (ie as an ascii byte)

thanks!

a char[1] containing "{" (ie as an ascii byte)

int x = (int) char [1];

For brevity, you can omit the cast.

int v1 = int(char[2] );
int v2 = int(char[1] );
[quote]- a char[2] containing "7B"   (ie as hex)[/quote]

[code]
char *foo="{";

int bar = (int)char[0];
  • a char[2] containing "7B" (ie as hex)
unsigned char h2d(char hex)
{
        switch(hex)
        {
                case '0':       return 0;
                case '1':       return 1;
                case '2':       return 2;
                case '3':       return 3;
                case '4':       return 4;
                case '5':       return 5;
                case '6':       return 6;
                case '7':       return 7;
                case '8':       return 8;
                case '9':       return 9;
                case 'a':       return 10;
                case 'A':       return 10;
                case 'b':       return 11;
                case 'B':       return 11;
                case 'c':       return 12;
                case 'C':       return 12;
                case 'd':       return 13;
                case 'D':       return 13;
                case 'e':       return 14;
                case 'E':       return 14;
                case 'f':       return 15;
                case 'F':       return 15;
        }
        return 0;
}

unsigned char h2d2(char *hex)
{
        return (h2d(hex[0])<<4) | h2d(hex[1]);
}

char *foo="7B";

int bar = h2d2(foo);

Or something similar.
[/code]

  • a char[2] containing 0x7B (ie as hex)

You don't need two chars to hold two hex digits, unless they're stored as their character representation

char x[0] = '7';
char x [1] = 'B';

You don't need two chars to hold two hex digits, unless they're stored as their character representation

I misinterpreted what he was doing, I thought he was talking about the hex value being in a single char.

Thanks guys, a stunning response!

Yes, "they're stored as their character representation" because they've just been read as characters from a text file

the ascii example works great.

However majenko's switch code to convert from hex gives me the following error -"invalid conversion from char* to unsigned char*" Know what's up?

I copied it from another one of my projects and modified it to suit on the fly. Experiment with it. It'll be the passing of the char * variable. I had it working with two plain char variables originally.

Just remove the "unsigned" bits from the function definitions. Those were left over from my other project.

majenko - I thought you were having a joke with that code. But if you were serious then this is much better than using case statements.

int convertFromHex(int ascii){ 
  if(ascii > 0x39) ascii -= 7; // adjust for hex letters upper or lower case
  return(ascii & 0xf);
}

Mike why is that last method better than using casting? Is their a difference in how it complies?

I am sure it is, but at 3AM in the morning my brain wasn't up to counting the characters in between the numbers and the letters. And as I was up at 4AM this morning to drive across the country and back, my brain hasn't yet been up to the task of re-writing it better.

Mind if I steal your little snippet there? Although, from a pure processing point of view, which is better - a lookup table, or a condition and a mathematical calculation? (If I were doing it in PIC ASM it would be a lookup table with RETLW's offset by the PC + the W register).

Oh... and integers to store a single byte...? On an 8-bit processor...?!

How wasteful...

Mind if I steal your little snippet there?

Be my guest.

If I were doing it in PIC ASM it would be a lookup table with RETLW's offset by the PC + the W register)

If it was in assembler my method would be shorter to code, and not take up as much space. I haven't analised the code to see if it would run faster.

but at 3AM in the morning

Get some sleep.
Remember bed is your friend. :slight_smile:

Oh... and integers to store a single byte

Well in the original code I had it return long ints but this was because it was to do with RFID token codes. :stuck_out_tongue:

int convertFromHex(int ascii){ 
  if(ascii > 0x39) ascii -= 7; // adjust for hex letters upper or lower case
  return(ascii & 0xf);
}

but I'm trying to convert from a char array, of size 2, containing a hex in string form.... I don't get it

This converts one character. My post contained 2 functions. The first one is the same as this function. The second one takes a string of 2 characters and calls the first function for each character.

Keep my second function, but replace my first one (h2d) with this one.

int convertFromHex(int ascii){ 
  if(ascii > 0x39) ascii -= 7; // adjust for hex letters upper or lower case
  return(ascii & 0xf);
}

This receives an int and returns a int. Is this a joke. What is it's propose?

ohh it adjusts for upper lower. What does return(ascii & 0xf); do. & means the address of something. So what does ascii & 0xf mean....

An int is just a bigger storage area than a byte. A char is a byte. You can store a char in an int, but you waste space.

You can replace the "int"s with "char"s.

Ahh yep get that. but still don't quite understand what the return actually means. Cheers

& has different meanings in different situations.

"&variablename" is the address of variablename.

"variable & variable" is a logical and between two variables or literals.

"ascii & 0xf" is the value in ascii anded with 0xf.

If ascii contains 0x8B, that is a binary value 10001010. 0xf is 00001111.

And the two together and you get 00001010.

Or, 0xB. A quirk (or a design) of the ASCII character set places certain character groups on aligned boundaries which can be isolated with simple mathematical operations like this. Ascii '3' is 0x33. And that with 0xf (which is the same as 0x0f) and you get 0x03 (or 3 in decimal).

Ahh nice one majenko. That answers my question exactly. Thanks.

not sure why i started the last two pasts with 'Ahh' other than i have a very literal phonetic way of typing.