A slicker way to be constantly changing the duty cycle?


Closed Thread
Results 1 to 15 of 15

Hybrid View

  1. #1
    Join Date
    Mar 2009
    Posts
    653

    Default A slicker way to be constantly changing the duty cycle?

    Having setup HPWM, what's the least invasive way to change the duty cycle?

    it may well be that the HPWM command is it...but i'd betom have affirmation from a HPWM expert!

    It's in the back of my mind that the PicBAsic HPWM is likely to be doing several things, whereas having got HPWM up & running - I just want to update the duty cycle throught my program on the fly.

    Any top tips on the slickest way to update the duty cycle without causing any possible stuttereing 'behind the scenes'?

    If it helps, I'm dabbling with an 16f1824 ...specifically wanting leds to fade niceley without any flickering.

  2. #2
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default Re: A slicker way to be constantly changing the duty cycle?

    The most effective way would be to directly alter the values in the CCPRxL (and CCPxCON, bits 1:0) registers.
    Why pay for overpriced toys when you can have
    professional grade tools for FREE!!!

  3. #3
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default Re: A slicker way to be constantly changing the duty cycle?

    Thanks rmteo (I was kind of figuring that's what you might say!)

    I'm only wanting to use 8 bit PWM, but it seems I'm still going to have to update two registers to control the duty cycle (what were microchip thinking of?!)...

    CCP2 Duty Cycle = CCPR2L:CCP2CON<5:4>

    To my next question....how do I load a decimal value (0-255) across two registers...I've got to take the bottom two bits of the decimal to binary conversion & put them into CCP2CON<5:4> with the remaining bits going into CCPR2L.

    Never done this before - hand holding most welcome!

    (it may well be the solution is simple - dunno, but my immediate thought is wouldn't it be cool if you could construct a pseudo variable that relate to bits of target registers)

  4. #4
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,604


    Did you find this post helpful? Yes | No

    Default Re: A slicker way to be constantly changing the duty cycle?

    Hi Hank,
    Usually it's done like this:
    Code:
    CCP2CON.4 = Duty.0       'Bit 0
    CCP2CON.5 = Duty.1       'Bit 1
    CCPR2L = Duty >> 2        'Bit 2-7
    Now, the resolution you'll actually get depends on the frequency you're using as well as the prescaler ratio. You MAY end up with 9 or 10 bits resolution in which case you must scale up "your" 8 bit dutycycle value to match the resolution of the hardware. Otherwise you might not be able to "swing" the dutycyle all the way to 100% - if that's what you need.

    Have you checkes out Darrels MIBAM routine? Never played with myself but it's supposed to do wonders for multiple fading LEDs.

    /Henrik.

  5. #5
    Join Date
    Mar 2009
    Posts
    653


    Did you find this post helpful? Yes | No

    Default Re: A slicker way to be constantly changing the duty cycle?

    Quote Originally Posted by HenrikOlsson View Post
    Hi Hank,
    Usually it's done like this:
    Code:
    CCP2CON.4 = Duty.0       'Bit 0
    CCP2CON.5 = Duty.1       'Bit 1
    CCPR2L = Duty >> 2        'Bit 2-7
    Now, the resolution you'll actually get depends on the frequency you're using as well as the prescaler ratio. You MAY end up with 9 or 10 bits resolution in which case you must scale up "your" 8 bit dutycycle value to match the resolution of the hardware. Otherwise you might not be able to "swing" the dutycyle all the way to 100% - if that's what you need.

    Have you checkes out Darrels MIBAM routine? Never played with myself but it's supposed to do wonders for multiple fading LEDs.

    /Henrik.
    Many thanks Henrik........Deep down I knew the answer would be splendidly (embarrasingly!) simple - thanks for the lightning response.

    Sigh, as one case closes another opens.... I'm running a 16f1824 @4mhz oscillator, and I need the frequency of the PWM to be inaudible (therefore say about 20khz+) ....how can I be sure that my resolution remains at 8 bits.

    No, I was not aware of Darrels MIBAM routine....I'll seek it out.

  6. #6
    Join Date
    Oct 2005
    Location
    Sweden
    Posts
    3,604


    Did you find this post helpful? Yes | No

    Default Re: A slicker way to be constantly changing the duty cycle?

    Hi Hank,
    I usually cheat and use MisteE's PICMultiCalc tool to determine things like prescaler ratio and PWM resolution but I'll try to explain it. If nothing else as a learning exercise for myself....

    The PWM period start when TMR2 is 0 and ends when TMR2 matches PR2. When you're running at 4MHz TMR2 "ticks" at 1MHz (with a prescaler of 1:1) so if you write 100 (or 99 actually because we're starting at 0) to PR2 you'll get a PWM period of 100us so the PWM frequency is 10kHz. Put 49 in PR2 and you'll get a PWM period of 50us (20Khz) and so on.

    Now, you would think that if you put 99 in PR2 there are 100 "steps" to the "cycle"/period and that you therefor get 100 discrete dutycyles but this is not the case because TMR2 creates the 8 high order bits and the internal instruction clock creates the 2 low order bits of a 10bit timebase (alternatively 2 bits from the prescaler when using anything but 1:1).

    What this means is that the number of discrete dutycyles ratios you get is basically (PR2+1)*4 so if you put 99 in PR2 (for a PWM frequency of 10kHz) you'll get (99+1)*4=400 "steps" which you'll have to have 9 bits to store. If you put 49 in PR2 the frequency will be 20kHz and the number of dutycycle ratios will be (49+1)*4=200 which fits nicely in a byte.

    If you want to maximize the resolution while still keeping it inside a byte you could set PR2 to 63 which will give you a frequency of 15625Hz and a resolution of 8 full bits ( (63+1)*4=256 )

    Well, I hope I've got this close to reallity (if not I hope someone will correct me) and that it makes at least a bit of sense.

    /Henrik.

    PS. If "all" you're doing with the PWM output is fading LEDs why do you need it to be inaudible?

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts