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;
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.