Hex/Byte Reversing and Conversion

I'm working on an RFID system using a MFRC522 with this Library : https://github.com/miguelbalboa/rfid Here's the code I have right now:

int A=(mfrc522.uid.uidByte);
int B=(mfrc522.uid.uidByte);
int C=(mfrc522.uid.uidByte);
int D=(mfrc522.uid.uidByte);

Serial.println("UID is %x %x %x %x", A, B, C, D);

This results in the following output:

UID is 35 C5 5A 59

My issue is - how do I first reverse that UID : from 35 C5 5A 59 to 59 5A C5 35 - and second convert and print the corresponding decimal value of that reversed UID. In this case, it would be 1499120949.

I should mention that I need it as a string at the end to add it to the end of a POST command.

Your UID has 4 bytes, which correspond to 32 bits. To get a decimal value from these bytes, you have to put them together in one variable. For this you can use an unsigned long. To put the bytes together, you can shift the values to the byte boundaries:

unsigned long dec_value = (D << 24) | (C << 16) | (B << 8) | A;

<< shifts the bits of the byte by the specified amount of bits to the left; The bitwise OR | puts the now not overlapping bytes together in one value. I have reversed the order of the bytes in this code, as you wrote, that this is necessary.

To convert this unsigned long to a string you can use the function ltoa():

char buf;
ltoa(dec_value, buf, 10);  // 10 is the base value not the size - look up ltoa for avr

If you want to use a String object (which should be avoided because of heap fragmentation), you can contruct the String directly from the long value:

String my_UID = String(dec_value);
• Fantastic! I tried printing the result just to test with Serial.println("%s\n", my_UID); but I'm getting an error: no matching function for call to 'HardwareSerial::println(const char , String&)' Aug 2 '18 at 21:29
• Serial.println() does not work like sprintf(), so you can't use that syntax there. But you should be able to get the correct result by simply writing Serial.println(my_UID);. There is really no need to format the string again (also because println already adds a line break at the end, so that you can ditch the extra "\n"). Aug 2 '18 at 21:32
• Ah. Managed to get it to print - but I'm getting 4294952245 as my decimal answer. An online converter said that 595AC535 = 1499120949. I'm testing it using fixed hex bytes - pastebin.com/i2NPjv60 Aug 2 '18 at 21:36
• You need to use "unsigned long" instead of "int" for your A,B,C and D - otherwise the shifting overflows.
– Majenko
Aug 2 '18 at 21:40
• dec_value is a poorly chosen variable name, as it implies there is something “decimal” about it. It's not decimal: it's just a number, internally stored in binary, just as any other numerical variable is stored in binary. Aug 3 '18 at 8:44

A standard way to convert individual bytes to a number is to use bit shifts and bitwise OR, as shown in chrisl's answer. When doing this, however, one has to take care not to overflow the bit shifts. On the AVR-based Arduinos, an int is 16 bits long. Shifting it by 24 bit positions to the left is guaranteed to overflow, which in C++ leads to undefined behavior.

The solution, as explained in Majenko's comment, is to cast to the final type before shifting, like this:

uint32_t uid = (uint32_t) mfrc522.uid.uidByte << 0
| (uint32_t) mfrc522.uid.uidByte << 8
| (uint32_t) mfrc522.uid.uidByte << 16
| (uint32_t) mfrc522.uid.uidByte << 24;

Note that I got rid of the useless intermediate variables A through D.

Once you have have the numerical value, you may try to use it without explicitly converting to a string. Instead, you rely on the print() or println() methods to implicitly do the conversion only when needed, as in

Serial.print("UID = ");
Serial.println(uid);

or even, on a network connection:

client.print(uid);

This will save you the memory needed to store the string. If you really need to have the converted string in memory, which could happen if you need to provide a Content-Length before sending the data, you can do so with the function ultoa() from the avr-libc:

char uid_str;  // max = 10 digits + terminating NUL
ultoa(uid, uid_str, 10);  // convert to base 10

Please note that ltoa() is not appropriate here, as calling it will implicitly convert the value to a signed long, which has the potential to overflow and yield a negative result.

This “C string” – a NUL-terminated character array – can then be converted to a String object if needed, but I advice you against doing so if at all possible. String objects are more convenient to manipulate, but they are absolutely not memory friendly, which can quickly become an issue on most Arduinos.

I think this does what you need. You already have the data in an array so to reverse it you go backwards through the list and assemble the number. To fit 4 bytes into 32bits you need to multiply each byte by (256 * its position), which is what the left shift << does. So by placing the code in a small loop you get some compact code that should do the job.

int A=(mfrc522.uid.uidByte);
int B=(mfrc522.uid.uidByte);
int C=(mfrc522.uid.uidByte);
int D=(mfrc522.uid.uidByte);

Serial.println("UID is %x %x %x %x", A, B, C, D);
uint32_t reversed = 0;
for (int x = 3; x > -1; --x) // go backwards through the array
{  // Take the existing value and multiple by 256 (left shift by 8) then add the latest byte on.
reversed = (reversed << 8) + mfrc522.uid.uidByte[x];
}
String decValue = String (reversed);  // Covert the number to a string

To add a bit to the whole hex and decimal story: Those are just representations of numerical values your computer/microprocessor does not really care about.

int x = 0
int y = 0b0
int z = 0x0

these are all the same value and internally stored as binary, just like any other number.

You specifically told the println function to display said number(s) in hexadecimal representation with the format specifier %x Serial.println("UID is %x %x %x %x", A, B, C, D); using %d or %i(for integer) will print out decimal values for each number.

Converting byte array to larger data type

If you actually want them to be reversed, you could simply cast the array variable (which is nothing but a pointer) to an uint32_t pointer:

uint32_t dec_value = *(uint32_t*)mfrc522.uid.uidByte

Note the *s We first cast the pointer to a pointer of a different type (uint32_t*) and then access it's value, by prepending another *, which is then stored in dec_value, equaling 1499120949 now.

This works because in C/++ data structures in memory are guarenteed to be in the order you specified. Therefore, you essentially tell the computer to 'see' these very 4byte (32bit) as a single value rather than a independent bytes.

Usually, when converting byte arrays to larger data types, you will find the values you receive are not what you would expect. This is because they are stored in a different order (depending on the machine) known as endianness

Here is a function that addresses this issue (similiar to the other answers)

uint32_t bytearray_to_uint32(unsigned char *buffer)
{
uint32_t value = 0;

value |= (uint32_t)buffer << 24;    // cast to target type before
value |= (uint32_t)buffer << 16;    // shifting to avoid overflow
value |= (uint32_t)buffer << 8;     // no parentheses needed due to operator precedence
value |= buffer;

return value;
}

Applying this function to your case would result in 902126169 (0x35c55a59) instead of the desired 1499120949 (0x595ac535).

Also check out ntohl when dealing with endianness still puzzles you.

• 1. As already stated in Majenko's comment to chrisl's answer, and restated in my own answer, buffer << 24 will overflow on most Arduinos. 2. ntohl() is not be available on most (maybe all) Arduinos. Aug 3 '18 at 9:51
• I referred to ntohl for educational purposes only. Shifting an 8 bit value by > 8 will not overflow unless the target is too small (WinAVR). Again, the function utilizing shifting is just included for educational purposes, as it is not suited for OP's application in it's given form. Aug 3 '18 at 10:42
• This may be just my personal opinion, but I don't think “educational purposes” excuses undefined behavior. Aug 3 '18 at 12:06
• Behavior depends on target architecture and used compiler. Any decent one will either cope or throw a shift-count-overflow instead. Aug 3 '18 at 13:37