Updating HPWM frequently, safe?

[skimask]

How often is safe to update the HPWM duty cycle when running a 12f683 at 4mhz?

I see that doing it constantly confuses the uC, so whats the safe "wait period" ?

Thanks!

What do you mean by 'safe' and 'confuses the uC'?

[peu]

What do you mean by 'safe' and 'confuses the uC'?

Hi Skimask,

I mean if I update the HPWM inside the main loop of a program, is it safe to update it every time the loop loops?

From my experimentation (Im controlling LED brightness using this hpwm) if I do this the LED flickers.

On the contrary, if I create a 3 lines new program with just one HPWM line and a loop:gotoloop, the LED does not flicker at all, its stable as it should be.

thanks

[skimask]

Hi Skimask,
I mean if I update the HPWM inside the main loop of a program, is it safe to update it every time the loop loops?
From my experimentation (Im controlling LED brightness using this hpwm) if I do this the LED flickers.
On the contrary, if I create a 3 lines new program with just one HPWM line and a loop:gotoloop, the LED does not flicker at all, its stable as it should be.
thanks

PIC12F683 datasheet, Section 11.3.3

[peu]

here is the gist of the code im running:

@ device pic12f683,INTRC_OSC_NOCLKOUT , wdt_on, mclr_off, protect_off
DEFINE OSC 4
DEFINE ADC_BITS 10
DEFINE ADC_SAMPLEUS 50

ANSEL = %00000010 ' GPIO.1 A/D in, rest digital
TRISIO = %00010010 ' GPIO.1 lectura AD,
cmcon0 = %00000100 ' AD via gpio1 and internal reference
vrcon = %10001010 ' set vref=2.25v

.
.
.

loop:
oldpote=pote
ADCIN 1, pote ' (0-65535)

if oldpote <> pote then
hpwm 1,inverduty,frecu 'these values are calculated in other section

endif
goto loop

maybe the problem is that im using ADC and HPWM simultaneously?

I don't undertand what you implied by reading that section of the DS.

Thanks!

[Darrel Taylor]

.... I don't undertand what you implied by reading that section of the DS. ...

That's just his little way of saying "I don't Know, go read the datasheet or something."<hr>

When an HPWM command executes, it treats it like it's the First time, and sets up every register needed to run PWM with the CCP module.

Changing CCP and TMR2 registers while the CCP is running PWM will cause "false pulses", Cycle Resets or elongation.

It would be nice if there was an HPWM_UPDATE command that only changed the dutycycle, without messing with the other registers. But there isn't.

If you need a totally "Glitch Free" PWM signal, then you'll have to modify the dutycycle manually. You can still use HPWM to set everything up. And then just modify the dutycycle later, after the PWM is running.

If you haven't already, you should get a copy of mister_e's PicMultiCalc.exe

It'll help figure out what values to use for the dutycycles.
http://www.mister-e.org/pages/utilitiespag.html

HTH,

[peu]

Thanks for the reply Darrel, now that explains many things

After many tries I managed to make the mister-e app work, it gave me an unregistered class error, but after a little googling I solved, it.

baaaack to the protoboard!

[peu]

well, now I have a new difficulty, trying to understand the calculator

Running OSC at 4mhz and PWM at 1khz I get:


And I found a post where Mister_e explains how to use it:

'
        '       38KHz PWM @ 4MHZ using a PIC16F877
        '       ----------------------------------
        @  __CONFIG _XT_OSC & _LVP_OFF
        '
        '
        TRISC = 0
        Duty        var byte
        
        '
        '       PWM SETUP
        '       =========
                ' PicMultiCalc says..
                '   Duty value for 50%=52
                '   PR2 = 25
                '   PRESCALLER 1:1
                '   
                '
        duty = 52                           ' duty value for 50% duty cycle
        PR2 = 25                            '
        T2CON = %00000100                   ' timer2 on, prescale 1:1
        CCPR1L = duty>>2                    ' MSB of duty cycle value
        CCP1CON=%00001100 | (dUTY<<5)       ' set PWM mode and store the 
                                            '   2 LSB of duty        
SpinInRound:
        goto spininround

If I understand correctly what you posted, I can start the HPWM before the main loop by using for example: HPMW 0,0,1000 and then within the loop adjust just the dutycycle.

Now what I dont understand is how I change the duty cycle, by using the calc I get 1000 values, but the duty variable is defined as BYTE

I could use some help/hint

Thanks!

[skimask]

That's just his little way of saying "I don't Know, go read the datasheet or something."<hr>

True, but the point was exactly as you posted, about the glitches and false pulses, etc. But you spelled it out, so now there's no need to read the datasheet.

[Acetronics2]

That's just his little way of saying "I don't Know, go read the datasheet or something."<hr>
HTH,

Hi, Darrel ,

I do not know if you're right here ...

The fact is I used HPWM without pain for years ... but NOT aboard any '683
and it REALLY seems there's a HARDWARE ( say CCP functionning ) issue.

The µChip section Skimask pointed at shows " PMW module *might* be disabled before changing the dutycycle ". I read some Other Pics Datasheets and this GREY section didn't appear elsewhere ...

IF I'm right, this "funny feature" happens whatever you use, assembler or Basic (!) ... The way HPWM command works doesn't matter here !!!

So, a ( Which other Basic do you think to ??? .... mmmmmh ? ) HPWM_UPDATE command wouldn't solve the question !!!

µChip clearly says : Changing the dutycycle while PWM running (and only dutycycle is enough ) will produce unwanted effects ...

The only way I see to keep ( is it really necessary ??? Good Q.) a "neat" PWM output would be to switch between HPWM, to the last produced fixed freq. and duty, soft PWM ... while disabling CCP, changing Dutycycle and re-enabling the CCP.

Quite a funny little sub to write, no ???


Back to our Friend Skimask ... I really do not know ... if he really doesn't know the "what is wrong".

I'm Ok ... this is not giving the solution, nor ... BUT ... His first answer could have been " Won't work with the '683 ( FINAL POINT )"


Would be kind to leave guns, knives, scissors and umbrellas out before entering the saloon ... just a thought.


Alain

[peterdeco1]

Here is a snippet of code from a motor speed controller for a small electric cart. The HPWM command is constantly repeated and has never caused any problems. In fact, in the beginning, I took the value of the speedpot once and just let the motor run and it caused problems. Intermittently the motor would "jump" into full speed. In spite of double regulation and a lot of filtering, motor noise sometimes caused the HPWM to go OUTPUT HIGH. I know it was motor noise because it never happened when controlling a 12V lamp.

ON:
ADCIN 2, SPEEDPOT 'READ VALUE OF SPEED CONTROL POT
IF SPEEDPOT > 150 Then LET SPEEDPOT = 150 'LIMIT SPEED OF MOTOR
IF LEFTRAMP < SPEEDPOT Then LET LEFTRAMP = LEFTRAMP + 1 'INCREASE SPEED SLOWLY
IF LEFTRAMP > SPEEDPOT Then LET LEFTRAMP = LEFTRAMP - 1 'DECREASE SPEED SLOWLY
Pause 1 'CONTROLS RATE OF SPEED INCREASE/DECREASE
HPwm 1,LEFTRAMP,10000 'OUTPUTS THE DUTYCYCLE CONTROLLED BY SPEEDPOT
IF PORTB.5 = 1 Then ON 'SWITCH PUSHED KEEP MOTOR RUNNING
GOTO START 'STOP EVERYTHING

[peu]

The only way I see to keep ( is it really necessary ??? Good Q.) a "neat" PWM output would be to switch between HPWM, to the last produced fixed freq. and duty, soft PWM ... while disabling CCP, changing Dutycycle and re-enabling the CCP.

The circuit Im using controls the feedback node of a switcher which its used to drive a power LED, any small glitch in the duty cycle is "visible" in the light output.

What puzzles me is the minute I stop using the ADCIN command, all the problems dissapear:

if calibrapin=0 then
ADCIN 1, pote
endif

if I put this calibrapin to 1 the output is steady. When it was bedtime yesterday (yes I keep thinking about problems in bed ), I tought: why not use software PWM, that may solve this issue. Well seeing it was suggested here too, makes me want to try it and I will

Regarding the DS section 11.3.3: "The PWM module may generate a premature pulse when changing the duty cycle."

Its the MAY word that puzzles me, I would expect more certainty here.

I still need to test Mister E suggestion, and speaking of it:

mm, you didn't disable the analog comparator.. maybe it worth to do it first?

In fact Im using the internal comparator, thats why I didnt disable it, if you check my 1st code post you will see:
vrcon = %10001010 ' set vref=2.25v

I need to put this value there so I can get more samples from my limited range sensor.

Also I tough it may be simply a reading problem, but this wasnt the case, I filled the available eeprom space with the read values and they were steady.

THANKS for the help guys! Back to the protoboard!


Pablo

[skimask]

The µChip section Skimask pointed at shows " PMW module *might* be disabled before changing the dutycycle ". I read some Other Pics Datasheets and this GREY section didn't appear elsewhere ...

And I just downloaded the latest/greatest 12F683 datasheet and it DOESN'T have that statement in there. What's up with that?

µChip clearly says : Changing the dutycycle while PWM running (and only dutycycle is enough ) will produce unwanted effects ...
The only way I see to keep ( is it really necessary ??? Good Q.) a "neat" PWM output would be to switch between HPWM, to the last produced fixed freq. and duty, soft PWM ... while disabling CCP, changing Dutycycle and re-enabling the CCP.

Couldn't you update the duty cycle right after T2 has overflowed? As long as the duty cycle wasn't too low or too high, wouldn't this almost eliminate all false glitches?

Back to our Friend Skimask ... I really do not know ... if he really doesn't know the "what is wrong".

I got a good handle on "what's wrong" 'cause I ran into the same problem with my multi-channel software PWM program I wrote to run a bunch of lights awhile back. And my fix for the problem was to only update the PWM duty cycle for each channel in between cycles, so basically, I ended up with PWM that couldn't do 100% duty cycle, but only about 0%-95% duty cycle. The extra 5% at the top end was used to update the software registers.