I'm using RTL for my project, and what I am finding is that when I pass parameters (mentioned in another post) and when I do simple math the variables are zeroed out?
What in the world would cause this? I have never seen this, and I am really not sure what could be causing this. Has anyone ever seen this before, and what in the world do I need to do to prevent this?
Here is a snipit of code that is being zeroed:
pMot->STAT.ulPulseWidth = pMot->STAT.ulPulseWidth / 100;
pMot->STAT.ulSysClkPeriod = (unsigned long)(SysCtlClockGet() / PWM_PERIOD_DIV); pMot->STAT.ulPWMPeriod = pMot->STAT.ulSysClkPeriod * pMot->STAT.ulPulseWidth;
Getting zeroed out is just that..... When math is performed, ie the calculation of mult, div, or even addition, the value returned is ZERO even though the calculation clearly should not be.
I am observing this through real-time debugging on a development board.
Using Hungarian notation, so "ul" would stand for unsigned long.
After having given some thought to the issue, I am wondering if it has to do with the function call not being within the same stack? This seems the most plausible and I am currently investigating this theory.
This seems the most plausible and I am currently investigating this theory
I'm afraid not. What about Andy's question regarding the variable values? What about compiler optimizations - did you check the generated assembly code?
"What about Andy's question regarding the variable values?"
See: e2e.ti.com/.../154969.aspx
You need to show the actual definition so that we can be sure that it is correct to really give an unsigned long...
Looking at the code from the cross post:
static volatile float fPWMPercent; static volatile unsigned long ulLocal; . . . ulLocal = ulVal; // Make sure we stay within the range of 50 - 100 if (ulVal < 50) ulVal = 50; // Make sure we stay within the range of 50 - 100 if (ulVal > 99) ulVal = 99; fPWMPercent = (ulLocal / 100); ****** HERE IS WHERE THE PROBLEM IS ******
ulLocal will have a value between 50 and 99 (inclusive). Using integer arithmetic, the result of that value divided by 100 will always be zero. This value is then converted to a float, which is zero.
Looks like simple bad coding/assumptions to me.
Incorrect!
It is ulVal which is forced to have a value between 50 and 99 (inclusive) - not ulLocal.
However, the code does suggest that the expected range of ulLocal is less than 100...
"Looks like simple bad coding/assumptions to me"
Indeed!
Muddled code can too easily lead to muddled interpretation.
"Muddled code can too easily lead to muddled interpretation."
Which is the reason most people have ignored that other thread, and will keep ignoring it until the source code has been reposted in a readable way. It isn't meaningful that we should have to cut/paste the code and perform a beautify on it just to be able to read it properly.