float to 48 bit hex conversion

What, exactly, have you tried?

In what way, precisely, did it not work?

What, exactly, have you tried?

In what way, precisely, did it not work?

"I have already tried this, but it's not working. how can i convert them to 32 bits."

They are already 32-bit. You need to convert to 48-bit if that is the format you expect in your output.

yeah you are right. when i converted the float in 4 byte hex they are almost similar,except the fact that they are some what miss aligned. but still the first byte is completely different. Is there any way get the first byte?

The first byte in your hex dump is the exponent, and possibly the sign.

You must get a full specification for your 6-byte format (or do a full analysis of all relevant combinations) to figure out how to convert mantissa and exponent betweeen the two formats.

Do you have any system where you can play with 6-byte floats? Remember denormalized numbers, NaN, +/- inf and zero as special cases.

this is what i found out searching the given documents.

real occupy 6 bytes, giving a float point value with a 40 bit mantissa and a 8 bit exponent. the exponent is stored in the first of the 6 bytes and the mantissa in the next five bytes with the least significant byte first.

1st byte = $?? exponent
2nd byte = $?? 10^-5
3rd byte = $?? 10^-4
4th byte = $?? 10^-3
5th byte = $?? 10^-2
6th byte = $?? 10^-1

the exponent uses binary format with an offset of $80. Hence, an exponent of $84 indicates that the value of the mantissa is to be exponentiated by 2^($84-$80) = 2^4 = 16. if the exponentis zero, the floating point value is taken.

the value of the mantissa is obtained by dividing the 40 bit unsigned integer by 2^40. the mantissa is always normalised i.e. the most significant bit should be interpreted as a 1.the sign of the mantissa is stored in this bit, a 1 indicating that the number is negative and a 0 indicating that the number is possitive.

Two separate issues?

1) The Keil side only have four-byte floating point numbers.

2) The intended receiver requires six-byte floating point numbers in hexadecimal form.

So we have to assume that he talk about the other side right now.

The question is if the six-byte description is for the correct format. In that case, the exponent is one bit shifted compared to the Keil exponent, since the Keil format has the sign bit together with 7 bits of the exponent. And the last bit of the exponent continues into the hext byte.

In this case, you must figure out where the sign bit (or if the mantissa is using two-complement form - probably not) is located.

Then you may possible be able to throw away 16 bits from the correct side of the mantissa when going from the hex output to the Keil format, and insert 16 zero-bits when going from the Keil format to the 6-byte format.

But your description saying that each byte of the mantissa of the 6-byte format is a ten-potence shifted can't be right - the mantissa should not store decimal values, but binary.

------------------

Let's look at your numbers. You claim that the exponent is offset with 0x80.

A visual look at the hex output shows that the decimals starts from the right, i.e. the high part of the mantissa is in the last byte.

We will have to assume that this byte has a sign bit in the highest bit.

Your example: 12.00 = 840000000040
-------------------

0x84 - 0x80 = 4 => multiplying factor 2^4 = 16

Starting from the right (and replacing most significant bit (sign bit) with a fixed 1, since a normalized mantisssa should be in the range 1.0 to 1.9999999999:

11000000
======== = 1.5
10000000

1.5 * (2^3) = 12.

But your suggested exponent was 4, not 3 so we would get the result 1.5 * (2^4) = 24, which is the wrong answer.

--------------------------------------------

Your example 21.48 = 8500000AD72B

101010111101011100001010
======================== = 1,3424999713897705078125
100000000000000000000000

1,3424999713897705078125 * 2^4 = 21,479999542236328125

Same here, the exponent must be 4, not 5.

Your example 257.89 = 890000ECF100
-----------------

10000000 11110001 11101010
---------------------------- = 1.0007382631
10000000 00000000 00000000

256 * 1.0007382631 = 257.89995

So this decoding of the mantissa was "good", but requires that the exponent is 8, i.e. that we multiply with 2^8 = 256.

0x89 - 0x80 = 9. Even here, the exponent we get is one step too large for your original claim.

--------------------------------

So, in the end, you will have to adjust your definition of the exponent. It seem to be offset with 0x81.

But you must also check what happens with the value 0 and with + and - infinity and with very small, denormalized numbers.