Hehehe well it helps to actually turn on the PWM module!!
Glitchy though. I've delayed the update by 1mS to smooth it out but still a big problem. Going to try disabling the PWM then updating the duty cycle and turning it back on.
Hehehe well it helps to actually turn on the PWM module!!
Glitchy though. I've delayed the update by 1mS to smooth it out but still a big problem. Going to try disabling the PWM then updating the duty cycle and turning it back on.
To get Glitch-Free, you have to synchronize the updates with Timer2.
The HPWM10 module does that with 10-bit resolution, and works just like the HPWM command.
http://www.picbasic.co.uk/forum/show...7805#post37805
But at your higher frequency, you'll still need to do it manually.
It does show how to though.
hth,
DT
Hi Darrel, I was just reading through that thread thinking it all looks familiar. I hadnt taken a look at your attachement yet.
I'll have to digest in the morning. Is there a tutorial in your attachement, and will it work for 18F devices?
I hate having one of those brains that learns by examples and questions rather than independant learning, feel so bad asking all the time. At least it usually goes in.
I should drink more. Alcohol kills brain cells, therefore one could deduce that the slower brains cells are in contact with the alcohol longer, which would lead to them being killed off. This would leave you with only faster brain cells and thus more intelligence as the slower ones are no longer holding up your thinking. So on that thought, I'm going to the fridge to open a can of knowledge.
There's not really a tutorial.
But there is a test program in the .zip that shows how to use it.
The max frequency is still 32.767khz.
And it will work with 12F's, 16F's or 18F's. As long as they have CCP modules.
However, while you grab me one of those cans of knowledge ...
The whole thing boils down to synchronizing the update with TMR2.
And HPWM10 has extra code to handle different frequencies/prescaler/CCP modules, which you won't need with a constant frequency on a single CCP.
So all you need to do with your existing code, is wait for the TMR2IF before changing the dutycycle ...No digesting required.Code:TMR2IF VAR PIR1.1 TMR2IF = 0 while !TMR2IF : wend ; let current cycle complete CCPR1L = duty>>2 ; MSB of duty cycle value CCP1CON.4=Duty.0 ; set PWM mode and store the CCP1CON.5=Duty.1 ; 2 LSB of duty
Do I get that Can of knowledge now?
<br>
DT
Sure do.
I'll report in the morning, its about 2am and my 18 month old is coughing himself awake as I type. I've got a feeling its going to be a long night. Poor guy, always so sick. Yay for ear tubes on Thursday.
Well the little guy is sick and I got about 4 hours sleep last night.
Havent tried this yet but I came up with this alternative and included Darrels changes.
Code:START: ADCIN 6, CSET 'READ VALUE OF CURRENT SET POT ADCIN 4, CSEN 'READ VALUE OF CURRENT SENCE IF CSEN > CSET Then LET DUTY = DUTY - 1 IF CSEN < CSET THEN LET DUTY = DUTY + 1 GOSUB NewDuty ' PAUSE 1 GOTO Start NewDuty: TMR2IF = 0 while !TMR2IF : wend ; let current cycle complete CCP1CON = 0 CCPR1L = Duty >>2 CCP1CON.5 = Duty.1 CCP1CON.4 = Duty.0 CCPCON.7 = 0 CCPCON.6 = 0 CCPCON.3 = 1 CCPCON.2 = 1 CCPCON.1 = 0 CCPCON.0 = 0 RETURN
Poor little guy. :sad:
As for the proposed additions ...
You don't want to do that.
The idea is to minimize the glitches, not create more.
Leave the module in PWM mode and just change the dutycycle.
<br>
DT
Bookmarks