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.
Dear Forum,
I have experienced some strange behaviour using float/double values in a formula calculation.
Using the same static double values the result may differ each time I run the calculation?
I'm using a LPC824 (Cortex M0) with no FPU and KEIL-MDK. No MicroLIB and default compiler version 5
I'm aware of the usage of double/float precision issue. But this problem is when using the same values, the result is different each time I run a calculation.
I have a voltage (double) from a ADC, that is run through a formula, that uses 7 coefs (double).
The formula is this:
dResult = V0[paramIndex] + ( (dTemp-T0[paramIndex])*(P1[paramIndex]+(dTemp-T0[paramIndex])*(P2[paramIndex]+(dTemp-T0[paramIndex])*(P3[paramIndex]+P4[paramIndex]*(dTemp-T0[paramIndex]))))/( 1+(dTemp-T0[paramIndex])*(q1[paramIndex]+q2[paramIndex]*(dTemp-T0[paramIndex]))));
V0[], T0[], P1[], P2[], P3[], P4[], q1[] and q2[] contains static double values. So they do neve change.
dTemp is the double value (voltage) passed to the function containing the formula.
If I also keep the dTemp stable (fixed static value of 27.8125) the dResult is different each time I run the formula. If I use the value of 27.7812 it is the same value each time.
Why do I see this behavior? Why is the result not the same each time?
Thomas
Hi,
It was just part of the complete code. But I have stripped everything else away in my project, and run the code (as posted).
Here are my results
Value dResult dResult1 dResult2 Index 1 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 2 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 3 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 4 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 5 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 6 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 7 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 8 27.7812 1.105545438064 1.105545438064 1.105545438064 Index 9 27.8125 1.10671996255 1.10671996255 1.109160524578 Index 10 27.8125 1.10671996255 1.10671996255 1.107294639882 Index 11 27.8125 1.10671996255 1.10671996255 1.107294641133 Index 12 27.8125 1.10671996255 1.10671996255 1.107294639882 Index 13 27.8125 1.10671996255 1.10671996255 1.107294641133 Index 14 27.8125 1.10671996255 1.10671996255 1.109160524578 Index 15 27.8125 1.10671996255 1.10671996255 1.109160524578 Index 16 27.8125 1.10671996255 1.10671996255 1.109160524578
The dResult2 is the value with no segmented formula. It is changing every time using 27.8125 as the stimuli value. Not with the other. And is NOT the same values when I restart the program as posted earlier. Next time i run it, it can be different values.
What I also have noticed, is that the value calculated with 27.8125 is a bit of compared to my TI86 calculator. It must be 1.106827150. The result posted by LPC User using the LPC845 gives the correct value?
Why?
My project can be downloaded here: owncloud.agramkow.com/.../GeG3B6pFMVVqMRr
The result posted by LPC User using the LPC845 gives the correct value?
Are you asking if my result is correct? I don't know. As I said before, I didn't try to understand the calculation.
The value shown is the dCalculation. I didn't report the intermediate values.
Hi again,
I tried removing more and more code and it seems related to setting the CPU to low power mode.
It is related to this:
cmdData[0] = 12; cmdData[1] = PWR_LOW_CURRENT; cmdData[2] = 12; __disable_irq(); LPC_ROM_API->pPWRD->set_power(cmdData, &response); __enable_irq();
Removing this does the trick. With both the changing value and the precision
Any idea why? Because I need the low power mode.
Yes, you result are the correct ones. My is a bit of.
But it seems to be related to setting the LPC824 into low power mode.
You've only got a 256 byte stack. You're not far off that with your code and I don't know what the internal ROM routines use.
Have you tried increasing that stack size?
That's probably something you need to take to NXP, then...