values not calculating correctly - CLOSED

[Gabriel]

Hi

I'm working on a DS18B20 and for some reason

[PCM programmer]

Post the variable declarations for all the variables in your code above.

Give us some sample values for OW_Buffer[0] and OW_Buffer[1].

Also post your PIC and compiler version.

[Ttelmah]

'How things are declared', is vital for this. There are also things that 'worry'.

The poster is using a double cast. Now assuming 'Temp_Raw' is possibly
a unsigned int16, casting it to signed, will _not_ 'sign extend' this into a
signed type. I'm not sure double casting is actually legal, and in fact the
default order of precedence for operators, is left to right, suggesting this
will convert the value to float, and then to signed int16!...
No, checking, the associativity or casts is right to left, so it should do the
conversion to signed int16 first, but still has the problem that this
will not sign extend the value received from the sensor. It also is a
complete waste of time (suspect the optimiser will actually get rid of
it and just convert the int16 directly to a float.

Now the point about signed conversion, is that if you have a value in a
unsigned int16, like perhaps 0xC040, and cast this to a signed int16, this
will not give you a -ve result. Instead the value will result in an overflow.

In fact if the optimiser does remove the double cast, the result of casting
this into the float will be 49216, not the negative number wanted....
A quick test shows this is what happens.

To convert a binary signed value into a signed int16, move it with a union,
not a cast.
So:

[temtronic]

I'm thinking 'something' happened in the newer compiler version as it worked before 'sometime'.
I have to admit that with any 'complicated' math, I break it down into several lines of code,making it easier for my old eyes to see and follow.
I use 'scaled integers' for that sensor instead of floating point. It was a 'mind exercise' and even though it looks 'ugly',it actually produces faster,smaller code. I also convert *C to *F in 3 lines while real programmers would do it in one.

As I've said before I'm not a trained C programmer, learned it by 'osmosis' while playing with PICs.
Jay

[Ttelmah]

Yes, they changed how sign extension was handled a few versions ago.
Whether a unsigned value, that would actually represent a -ve number
gets turned into a -ve when cast into a signed value is 'implementation
defined' in C, so it is always safer to not rely on doing this....

[Gabriel]

These are the original declarations, which I'm still using..

[Gabriel]

Indeed negative numbers are not computing correctly.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[temtronic]

hmmm...
I wonder if the compiler defaults int16 to be UNSIGNED int16 ? If so does that change 'things'...??

[Gabriel]

I've implemented the solution with the union suggested by Ttelmah:

[Ttelmah]

It may be worth saying, you don't actually need to cast sword to float. That
the division is by 16.0 (with the decimal) forces the maths to use
float and do an implicit cast. Generally I've found this to be slightly
more efficient in many cases than explicitly casting!...

[Gabriel]

Thank you all for your help!
_________________
CCS PCM 5.078 & CCS PCH 5.093