We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I know Keil does not support a 64 bit float.
Does anybody know of a way to create a 64 bit float? Maybe from a 32 bit float? The original data is in a ushort. We to create and read a 64 bit float to interface to an external device. We have no choice.
John; I do not know how to do the conversion. But the Keil CA51 User's Guide under 'Advanced' constructs show how Keil's tools convert the 32 bit 'Real' numbers to hex. That may give you some ideas for your double precision float constructs. Suggest that you google "double Precision Float'. I'm sure that you will find articles and algorithms for that will help you do the conversion. Bradford
The format of the floats is quite simple, so it doesn't take many lines of code to convert a 32-bit float into a 64-bit double.
If you go directly from a 16-bit integer to a 64-bit double, then you will need a couple of lines extra since you must then create both the mantissa and the exponent.
The standard is IEEE 754.
I can cast the ushort into a 32 bit float. Is it just a matter of shifting the float after it is in an 8 byte array?
Is it just a matter of shifting the float after it is in an 8 byte array?
More or less. It will probably take two shifts combined with some bitwise OR'ing and AND'ing. It probably makes sense to construct bit fields representing single and double precision floats (sign, mantissa, exponent.) After that converting between them would probably be as simple as this:
f64.sign = f32.sign; f64.exponent = f32.exponent; f64.mantissa = f32.mantissa;
Of course, I could be missing something.
Note that the exponent is biased and not two-complement, and the big difference in range of the double-precision exponent means that it has a different bias.
So you would have to extract the exponent from the 32-bit float. Update from 8-bit to 16-bit. Perform an add for changing bias. Shift to the correct location and store.
For the mantissa, it should be enough to just move the bits. The double will have a number of extra bits at the end, that should be left as zero.
Starting from a 16-bit integer, there will not be any denormalized values, NaN, +Inf or -Inf.
I was too fast posting. I had intended to add this link: en.wikipedia.org/.../IEEE_754-1985
It has quite good examples of how the numbers are actually stored.