I see something I don't like. You are making a call to a subroutine that is outside of the interrupt routine you are in. BAD coding practice...
I see something I don't like. You are making a call to a subroutine that is outside of the interrupt routine you are in. BAD coding practice...
Dave Purola,
N8NTA
EN82fn
Hi Dave,
Would you care to elaborate a bit on WHY exactly that is such BAD practice (as long as you RETURN of course)?
Yes, it does put another return adress on the stack but really, that's usually not a problem - certainly not with 18F parts where you can nest 27 levels deep.
My guess is that the "blips" are comming from the frequent updates of the dutycycle using the HPWM command. It's my understandning that it (the HPWM command) reconfigures the CCP module completely every time it executes even though it's only the dutycycle that changes.
Another thoguht: I don't know about the "PLL-bug" mentioned but perhaps the HPWM command calculates the dutycycle value based on the wrong frequency so the registers overflows or something?
Bottom line is, try setting the CCP modules up manually and see if that helps, there should be plenty of examples around the forum.
/Henrik.
I always thought it was best to keep the coding within an interrupt to a minimum. I set flags and then check for them in my main logic.
If code absolutely has to execute within the interrupt, I'd place it in-line. I would think calling an other subroutine chews cycles needlessly.
Robert
Henrik,
I agree with you that it must be the HPWM command that is causing the blips since the 46K22 has a buffered PWM.
However, as you can see from the source code, i do most things by setting the register directly like the ADC scanning. However, i have not yet been able to get the PWMs to work by setting them manually.
The PLL bug is because certain elements of PBP do not account for the 4 times increase of the clock speed due to enabling of the on-board PLL. It's those elements that ignore "Define OSC" and try to determine clock speed on their own.
Demon and Dave,
I agree the code is not optimal, it's the resultant mess of trying to debug the problem and sticking stuff in subroutines so that i can call it anywhere and not have to worry about it coming back correctly.
I'll go take a look for manual setting of the PWM and see if that sorts it...
Thanks guys.
Bookmarks