PWM Duty cycle problem

[picer]

Code first.....

[rwyoung]

For better readability of code, use the "code" buttons. Otherwise it seems to loose the indentations and everything ends up jammed against the left margin. Also, the #use fast_io(B) should be fine but put the "set_tris_b(0);" line in your main().

I'd count down instead of up, each time the counter "zeros" use the "output_toggle" function to change the signal. You can also juggle between two different reload values to do something other than 50% duty cycle.

0% and 100% are special cases since they represent an always low or always high state for the output pin.

1% increments of what? 1% of 650Hz? In that case it is 6.5Hz "steps" or 1% of 50Hz for 0.5Hz "steps". Or do you mean you want to decrease (increase) the frequency 1% each time? 650Hz, 643.5Hz, 637.05Hz, 630.694Hz, etc.

Also, I'm not really following your logic behind using a 39.4kHz clock. But then I probably shouldn't be looking at this at 1am.

Take a look at the example program "EX_PATG.C" that should have come with your compiler. I think it will help sort out your issues for generating multiple PWM frequencies and dutycycles from the same master clock. It is set up for a 50% but several different output frequencies. A good start.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[Mark]

You could reduce the code a bit from

[picer]

I didn't optimize anything yet, thanks. For instance, I want to set PWM1 to 50Hz and need to control duty cycle from 0%-100% in 1% increments and set PWM2 to 200Hz duty 0%-100% 1% increments and PWM3 to 650Hz, same thing for duty cycle. Once I get above 200Hz I cannot do 1% increments anymore. The loop count came out with 20MHz clock, 385 for 50Hz, 192 for 100Hz, 96 for 200Hz. Doing calcs for 400Hz:

[Mark]

First thing you need to do is to decide what frequencies you need. Are they constant or can they change as well?

[picer]

There are a set of constant freqs I want to use, 50Hz is one, 300, 600 but want to be able to select different ones as well, 650Hz would be the highest hense the added PWM outputs. ex_patg.c seems pretty slick if I can figure out how to do the duty cycle. Havn't done C in over a year so brushing up.

Thanks.

[picer]

I've searched all day for something and came up with squat on how to fix my problem. Is duty cycle not as controlable as I thought? Keep looking....

[Bill Boucher]

i'm a newbie to CCS C but have been programming PICs daily in assembler for all sorts of PWM projects for about 14 years. You could try to generate the lower freqs in software using a fast loop and at the same time generate the higher freqs in hardware CCP. To get freqs as low as 300 or 600Hz in hardware, you'd have to drop the osc. freq and that will be the opposite of what you'd want to do with regards to the software based PWM outputs.

Anyway, using a 20MHz pic (i.e. 16C711), I have built true PID loop position controllers for linear solenoid EEGR valves. The controller reads an analog position sensor, a pot position reference, coil current, 4 mode switches, controls 4 LEDs, reads the dutycycle of an input reference PWM and generates a fixed freq output PWM to drive the solenoid coil. All this runs continuously at up to 256Hz PWM with 8-bit (0.39%) resolution. Granted, this was done in assembler and pushed the 711 to the limit.

Here's what you do. First off, forget the timer interupt. It wastes time saving and restoring context every time it overflows and at this speed, you don't want that. Create a main loop that runs at a multiple of your fastest output PWM freq. The rate for 1% resolution would be 100x the PWM freq of 600Hz, so 60,000 Hz. That leaves you 85mc per loop with 5 MIPS. Not a lot, but if I can make a box that does all of what I quoted above in that much time, then we should be able to manage 3 PWM outputs. To do this, simply enter the loop, exec your PWM code, and wait at the bottom until the T0IF bit is set. Then fall through, clear the flag, move a constant into TMR0, and jump back to the top of the loop. If you want to, use an interupt to run code that changes the PWM freq and %DC. That will cause some PWM output flutter, but otherwise you'd have to interleve code into your fast loop to monitor switches or something to control the freq & %DC.

Inside your fast loop, create two counters for each PWM output. Use the "register" type of var so it accesses afap. One is OnTime, one is OffTime. Load these with values to set freq & %DC. Then when running, if Ontime>0 then output = high and dec OnTime. If OnTime=0 and OffTime>0 then output=low and dec OffTime. When both=0 then reload both.

To figure out OnTime and OffTime from Freq & %DC, well, with just one PWM output, I'd make the fast loop 256x the PWM frame rate. Using an 8b ref value for OnTime, then OffTime is the compliment of OnTime. With multiple PWM output freqs, I'd probably want to do the "reference conversion" in a separate PIC, then load them into the PWM-gen PIC using its hardware PSP or SPI or I2C. Something fast enough and int-driven so as not to flutter the PWM outputs too much when new values are loaded. Also, if you had 2 PICs doing this job, you could make a software generated 4-wire communication between them to synchronously shift the OnTime1/OffTime1/OnTime2/OffTime2/OnTime3/OffTime3 values for each channel from the PWM master to the Ref-converter slave. The master could produce an enable output & clock output. The slave presents the data and an ack output. This gets a little complicated but basically the PWM PIC will sample 1 bit of data each time it sees the ack line go high. Then it would toggle the clock state, wait for ack to go away, toggle clock, wait for ack, then sample. The trick is to write this code to execute 1 stage per main loop pass. This requires a few counters and bit flags to keep track of where it is in the communications. I've done exactly this sort of thing several times in assembler. The main advantage of this is totally glitch-free PWM while loading in the PWM reference values.

Sorry I didn't present any C code here, just ideas, but this is basically how I've scanned & generated fixed-freq 8b & 10b PWM in software for years with great success.