There is some verbiage in DS, under "Block Diagram and Configuration" that implies generated
API's return correct vaule. Same in descriptions of API call.
Quick test of compiler, return to an 8 bit variable, it should complain.
Ok so it was a stupid problem. I was reading the data to an 8 bit variable. I guess I just assumed it was a 16 bit.
Thanks for the help though, it may have taken me a bit to find that if i wasn't going to go change it to an 8-bit. However it never threw any errors reading to an 8 bit. Is that a problem?
Is there any reason that changing the compare value and period value of a PWM block in code will cause the period to spike before reaching the desired value?
Trust me, we still do not know why E = I x R, why that is physically true. And can be no other solution.
We do not know why the universe's rate of expansion is away from the mass that coeleseces it. We think it
is dark matter, a convienent term to describe a prtoblem we do not understand.
The compiler. if it is good, issues a warning, not an error. Sometimes the difference escapes me.
Change to reg writes, period and compare, the API descriptions do not show any side effects......? Not sure whats
Changing the compare value can immediately affect the state of the compare output (this is also stated in the data sheet), when the current PWM counter is above the new compare value (depending on the configuration). It might also be, in that case, that the comparision doesn't trigger, and the PWM counter runs for the full period, starts again and only then triggers the compare. CHanging the period value should not affect the output, as it is used only when the PWM counter reaches the terminal count.
I figured it might have been something like if I increase the compare value mid run, since it updates immediately, it would just add on to my signal that was already high. I only see that spike when I increase so that makes sense. Would there be a way to make sure I only update my compare and period values at the end of a pulse. I guess I could use an interrupt and a flag
Although I forgot I'm looking at the output through a NOT gate so that means my spike is really a long low time from the PWM block. But the problem remains the same, that is I'm resetting my compare and period values before they completed the previous iteration.