Float24 (24 bit floating point) in Hex?

I am using float 24 bits to store a floating point value in the MRK III compiler from NXP. It stores a 24 bit float value as a 3 byte Hex in data memory. Now when I use IEEE 754 floating point conversion to get a number back from binary to real, I get something very strange.

Let me say this with an example -

Note - "since my compiler supports 24-bit floats (along with 32-bit floats), I assign something like this."

Sample program:

float24 f24test;
float f32test;

f32test= 2.9612;
f24test= (float24)f32test;

      

Debug window output (global variable): -

f32test = 2.961200e+000
f24test = 2.9612e+000

      

Values ​​stored in DM (Data Memory Simultaneous) taken from the debugger -

f32test = 40 3d 84 4d (in hex)

f24test  = 02 3d 84  (in Hex)

      

PROBLEM: - Now when I try to convert f32test = 40 3d 84 4d (in hex)

to binary and then back to float using IEEE 754 I could get 2.9612. Although at the same time when I try to convert f24test = 02 3d 84 (in Hex)

to binary and then back to float using IEEE 754 I couldn't get 2.9612 instead of some weird value.

I am going through this wiki page to talk about floating point arithmetic -: http://en.wikipedia.org/wiki/Single-precision_floating-point_format

I'm confused why it doesn't work for float 24 if I use the same format for 1 digit, 8 bit and 15 bit Mantissa. (In float 32, this is 1 sign bit, an 8-bit exponent, and a 23-bit Mantissa.)

Can any of you guys help me get the value 2.9612 back from f24test = 02 3d 84 (in Hex)

???

Please do, I have been struggling with this for the last 15 hours :(

Thank you in advance:)

+1


source to share


2 answers


f32test = 40 3d 84 4d (Hexadecimal)

f24test = 02 3d 84 (in Hex)

In IEEE 754 floating point formats, the floating point exponent is stored with bias . It is clear that whoever designed the 24-bit floating point format you are referring to did not choose to use the same offset system as in the IEEE 754 binary, as the exponent bit values ​​of the two representations above do not match despite the exponents both are represented by 8 bits (according to you).



In 32-bit notation, exponent is represented by 0x80 bits, which sounds correct to represent a value between 2 and 4.

You can start with the hypothesis that the 24-bit exponent has an offset of 0x04 and confirms this with more values. The single meaning is not enough for us to make sense of the 24-bit floating point format, which is not part of the IEEE 754 standard and is clearly designed with some exotic variations.

0


source


I suppose this is an old post, but I will compliment this experience that I am currently going through ...

I am also trying to find out how NXP represents the float24 datatype. I am writing a small test macro that will be inserted into much more of the code, and I am trying to use the float24 datatype since the normal floating point datatype creates problems (I am a trainee so I am not sure why this is causing problems, perhaps the purpose the code I'm writing can't support 32-bit floating point numbers?).

There were some notes left by some other engineer on most of the code that contains something like this ...

 /* ByteValue[0] : mantissa bits m7..m0
    ByteValue[1] : sign bit, mantissa bits m14..m8
    ByteValue[2] : exponent e7..e0 (signed, 2s complement repres.)
    Actual value is
    f = s * ( 2^(-1) + m14 * 2^(-2) + ... m0 * 2^(-16) ) * 2^e */

      



Unfortunately, this new information is still cryptic (what is the bias? Suppose it is bias? What is a variable?) Assuming it means the sign bit, why is it multiplied by the mantissa, since multiplication could mean the result is 0. if the sign bit is 0? etc.).

However, this may show that the structure of this number is different. The sign bit is no longer MSB, it is listed immediately after the exponent. This would also mean that in your case the exponent is +2 (since your hexadecimal number starts at 0x02 and corresponds to ByteValue [2]).

I hope this helps someone stumble upon this post. I am still trying to figure this out myself. Please post any new thoughts.

+1


source







All Articles