By your explanation, i understand that you expect this "_Fract" to be a
16-bit fixed-point number with format Q1.15.
A Q1.15 fixed-point number can represent numbers in the range -1.0 to
0,999969482421875.

If you really need to represent the value 1.0, then you need a Q2.14
format. It can represent numbers in the range -2.0 to 1,99993896484375.

When you try to convert integer 100 to Q1.15 (which can represent at
most 0,999969482421875), the compiler is doing "saturation", that is
using the largest value it can represent (0x7fff is the Q1.15 binary
representation of 0,999969482421875).

Probable doing   "f =3D i/32768.0;" will give you the expected result.


Isaac



Em 17/07/2014 17:19, Edson Brusque escreveu:
> Hello all!
>
>      I'm stuck in an strange situation. I've read the docs, googled a=20
> lot, researched a lot and still haven't solved it.
>
>      Please, let me explain with an example:
>
> ----
>      uint16_t i;	// A 16 bit signed integer
>      _Fract f;	// A 16 bit signed fractional
>
>      i =3D 100;	// [i] is now 0x0064
>      f =3D i;	// [f] is now 0x7FFF. I need it to be 0x0064.
> ----
>
>      The actual application is getting values from an external ADC in=20
> signed int form and needs to move to a _Fract value to make use of=20
> fractional arithmetics built in XC16. But the compiler is doing some=20
> conversion with saturation.
>
>      I just need the int values (-32768 to +32767) scalled to fractional=
=20
> (-1 to +1). Actually, it's just copying the contents from one register=20
> to the other.
>
>      I can convert int to float and then make the conversion and=20
> scalling to _Fract but it's a lot of wasted CPU cycles.
>
>      Anyone have any clues?
>
>      Best regards!

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.