Searching \ for '[PIC:] Slow PWM signal in hardware' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=pwm
Search entire site for: 'Slow PWM signal in hardware'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Slow PWM signal in hardware'
2004\04\22@121732 by Robert B.

flavicon
face
I need a PWM signal with the following specifications (from the
manufacturer):  period 17ms, minimum duty 1ms, maximum duty 2ms.

I'm using a PIC16F873A on this project, and would really really really like
to generate the PWM in hardware.  Reading the chip's datasheet implies that
the slowest PWM signal on the CCP1/2 is 1.2kHz (about 20x too fast).  Are
there any clever tricks that can slow it down to about a 17ms period?  All
the timers and interrupts are free for use, but like I said if there's a way
to get the PWM module to do it that would be ideal.  If all else fails I can
cobble together an interrupt to do it, but the code is fairly time critical
so it would need to be really quick.

Thanks!

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\22@123842 by Andrew Kieran

picon face
It sure sounds as though you're controlling a servo  ;-)  I'm
using TMR1 to do this.  It generates the 17ms interupt.  On
interupt, it begins counting down a variable and setting the
output bits controlling four servos.  This takes 1ms.  Then it
sets up a 1 ms interupt and processes the main code loop in the
meantime.  After this 1ms delay, the servo control bits are set
low and TMR1 is set to generate an interupt in 17ms.

I know that this isn't what you want but I couldn't think of a
way to use the PWM generator that was any easier.  Let me know
if you'de like my code.

Andrew
akieran_at_ureach.com



________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag


---- On    , Robert B. (spam_OUTpiclistTakeThisOuTspamNERDULATOR.NET) wrote:

> I need a PWM signal with the following specifications (from
the
> manufacturer):  period 17ms, minimum duty 1ms, maximum duty
2ms.
>
> I'm using a PIC16F873A on this project, and would really
really really like
> to generate the PWM in hardware.  Reading the chip's datasheet
implies that
> the slowest PWM signal on the CCP1/2 is 1.2kHz (about 20x too
fast).  Are
> there any clever tricks that can slow it down to about a 17ms
period?  All
> the timers and interrupts are free for use, but like I said if
there's a way
> to get the PWM module to do it that would be ideal.  If all
else fails I can
> cobble together an interrupt to do it, but the code is fairly
time critical
> so it would need to be really quick.
>
> Thanks!
>
> --
> http://www.piclist.com hint: The list server can filter out
subtopics
> (like ads or off topics) for you. See
http://www.piclist.com/#topics
>
>

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\22@124538 by hael Rigby-Jones

picon face
{Quote hidden}

Sounds like a model servo control pulse...

Sorry to be the bearer of bad news but the only way to slow the hardware PWM
is to run a lower clock frequency.  I've had this exact same problem before
and wished for a bigger pre-scaler on the PWM.

The good news is that if you can spare two CCP's I *think* you should be
able to run a software PWM under interrupts with minimal CPU overhead.

1) Configure both CCP's for compare mode.

2) Configure CCP1 to compare at a timer count relating to 17ms and use the
special event trigger to reset Timer1 and also set the CCP1 pin high.

3)Configure CCP2 to compare at a timer count relating to 1-2ms.
Unfortunately you can't make it clear the CCP1 pin automaticaly, so you will
need to use an interrupt.  However, this will be very quick and only occurs
once per 17ms.

In operation, when CCP1 is triggered by a match after 17ms, the CCP1 pin
will be set high and the timer will be reset.  After a period of 1-2ms CCP2
will be triggered by a match and you clear the CCP1 pin in your interrupt.

This gives you 16 bit resolution from 0-100% duty cycle, or about 11.5 bit
resolution for your 1ms range.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
.....postmasterKILLspamspam.....bookham.com.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\22@173113 by Jinx

face picon face
> Are there any clever tricks that can slow it down to about a 17ms

No, I don't think so, you'll probably have to use the timer(s) or s/w. Like
MR-J said, a bigger pre-scaler on the PWM module would be nice,
because.....

.....I've got a project part-done that requires, amongst other things,
pot-controlled frequency and PWM of two (at this stage) independent
channels from 0.1Hz to 300Hz. Processing time needed for this is
starting to impinge on other functions and I'm thinking of bit-banging
the frequency/duty cycle from the PIC over to a couple of Scenix's or
satellite PICs, let them do all the donkey work in s/w

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\22@222325 by Robert B.

flavicon
face
Thanks for the suggestions.  I wound up just doing it in software with (as
usual) a crude hack that works pretty well.  It was way less painful than I
thought it would be, actually!  Is there a reason Microchip doesn't make
this a little easier? It seems it would be a fairly common task at least.


{Original Message removed}

2004\04\23@024453 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Robert B. [EraseMEpiclistspam_OUTspamTakeThisOuTNERDULATOR.NET]
>Sent: 23 April 2004 03:23
>To: PICLISTspamspam_OUTMITVMA.MIT.EDU
>Subject: Re: [PIC:] Slow PWM signal in hardware
>
>
>Thanks for the suggestions.  I wound up just doing it in
>software with (as
>usual) a crude hack that works pretty well.  It was way less
>painful than I thought it would be, actually!  Is there a
>reason Microchip doesn't make this a little easier? It seems
>it would be a fairly common task at least.
>
>

Microchip optimised the CCP to give as high frequency as possible whilst
still maintainging good resolution, which is generaly more usefull for the
majority of applications that would use the PWM as an analog output.
However, adding an extra few stategs on the pre-scaler would certainly have
increased it's usefulness for this type of application.

BTW, I tried my suggestion using the simulator and couldn't get it to work.
Microchips documentation isn't overly clear, but it looks like if you
configure both CCP's for compare mode, they will both use the special
trigger mode which clears Timer1.  That or my test program was complete
rubbish and I'm not ruling that out!

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
@spam@postmasterKILLspamspambookham.com.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\04\23@032305 by Robert B.

flavicon
face
Your idea seemed really novel, but I didn't think I could make it work in a
timely fashion.  Instead I just used a pretty simple interrupt routine on
timer1.  Since it's a fixed period of 60Hz, I just subtract off the duty
time (stored as a number of timer cycles) to make two variables, "high_time"
and "low_time" (both also some relevant quantity of timer cycles), then have
the interrupt change a single pin between a high/low state and reset the
timer for the corresponding up/down time.  This way I can set the duty cycle
from anywhere in the code by writing to a single variable.  The interrupt
always resets the timer, so the PWM should theoretically always be running.

I realize it's not perfect, and that with repeated successive writes to the
duty variable my period could be modified to about 58 or 62Hz, but I'm not
concerned about it since the max error is fairly small.  Also the system
runs closed loop so it will automaticall correct for any errors the slightly
incorrect timebase might incur.

A few people mentioned I might be driving an RC servo, and indeed it's not
too far off.  The pwm signal is interfacing a serious high-current motor
controller which is driving a 50A DC gearhead motor.  The motor controller
has about 8 FET-looking devices in it, all attached to a heatsink with a fan
blowing across them.  I'm guessing there's probably just an H-bridge in
there with a uChip interface for the PWM.

This is my first attempt at using interrupts for anything really useful, and
I must say it was easier than I anticipated.

Thanks again to everybody who responded!

----- Original Message -----
From: "Michael Rigby-Jones" <KILLspamMichael.Rigby-JonesKILLspamspamBOOKHAM.COM>
To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
Sent: Friday, April 23, 2004 1:44 AM
Subject: Re: [PIC:] Slow PWM signal in hardware


> >{Original Message removed}

2004\04\23@040327 by Jason S

flavicon
face
Does it have to be done in your 16F873A?  You can program a 12F629 to be a
slow PWM module (doing the work in software) fairly easily and then control
the 12F629 from the main pic.

Jason

{Original Message removed}

2004\04\23@040741 by Robert B.

flavicon
face
Yeah the circuit is already built and put together, and the board is out of
room so I'm pretty much stuck with the 873A.  It's working now, but out of
curiosity how would you recommend controlling the slave chip?  It seems like
whatever code would be needed for controlling another chip could just as
easily generate the slow PWM instead.  Are you thinking like a serial line?
or just a faster PWM from the 873A's CCP module?


{Original Message removed}

2004\04\23@044557 by Jason S

flavicon
face
The control of the slave chip depends on exactly what you're doing which is
why I didn't go into more detail.  If the PWM is always a period of exactly
17ms and a fixed on time, the control can be as simple as 1 IO line to turn
it on or off.  If the duty cycle will be variable, you have 5 input lines to
specify 1 of 32 possible conditions.  If your needs are even more complex,
it's easy enough to clock in serial data.

The key point is that the slave chip effectively gives you another running
thread, so once you tell it the specs of the PWM, it will continue doing it
with no action from the main chip.  You said the code in the main chip is
fairly time critical, so it seems like having the PWM be set-and-forget
would be a big help.  If you're chaging the PWM settings a lot, this
probably wouldn't be a good solution.

Jason


{Original Message removed}

2004\04\23@061354 by Jinx

face picon face
> If the duty cycle will be variable, you have 5 input lines to specify
> 1 of 32 possible conditions.  If your needs are even more complex,
> it's easy enough to clock in serial data

One way I'm looking at is to use a 4-bit parallel transfer and connect
the two chips' INTB0 together. INTF in each can be used as as flag
that data is ready or has been picked up

>If you're changing the PWM settings a lot, this probably wouldn't be
> a good solution

For any cycle you have at least 50% of the time available to look for
update data, more if you identify which, if either, state is on for longer.
The rate of change then becomes the issue. Do you wait until the
current cycle is finished or segue into the new frequency or duty cycle ?
This would depend on the smoothness required of changing from one
to another (for example smooth control with pot control going from
slow to fast)

Another possibility could be to generate analogue voltages to control
something a VCO like the ICL8038. Filtering would smooth out the
digital steps and probably give good results

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\04\24@061148 by Gerhard Fiedler

picon face
One way to use PIC hardware to get a jitter-free slow PWM is to use the
Compare function of the CCP module. It will set the CCP pin to low or high
when the CCP register matches Timer1, and trigger an interrupt. In that
interrupt you reload the CCP register and change the mode (to toggle the
CCP pin in the other direction this time).

This is not less software effort than doing it all "by hand" in a timer
interrupt, but it is jitter-free because the actual pin control is done by
hardware at the timer match.

Gerhard


> Thanks for the suggestions.  I wound up just doing it in software with (as
> usual) a crude hack that works pretty well.  It was way less painful than I
> thought it would be, actually!  Is there a reason Microchip doesn't make
> this a little easier? It seems it would be a fairly common task at least.

>>> Are there any clever tricks that can slow it down to about a 17ms
>>
>> No, I don't think so, you'll probably have to use the timer(s) or s/w.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\04\24@133239 by Robert B.

flavicon
face
When you say "Jitter Free", do you mean that my software interrupt could be
causing jitter?  I am getting an *almost* insignificant amount of jitter on
the motor output, about 2-3 degrees rotation over the span of 2-3 seconds.
On the scope the PWM output looks nice and clean, but it jumps around every
once in a while.  I have an old-fashioned scope, so I can't actually save
the trace to see what's causing the jump, but it appears as though I rapidly
adjusted the trigger knob so the trace scrolled for just a split second,
then resumes normal tracing.  I'm wondering if this could be the jitter
you're talking about?


{Original Message removed}

2004\04\25@084428 by Gerhard Fiedler

picon face
>> One way to use PIC hardware to get a jitter-free slow PWM is to use the
>> Compare function of the CCP module.

> When you say "Jitter Free", do you mean that my software interrupt could be
> causing jitter?  I am getting an *almost* insignificant amount of jitter on
> the motor output, about 2-3 degrees rotation over the span of 2-3 seconds.
> On the scope the PWM output looks nice and clean, but it jumps around every
> once in a while.  I have an old-fashioned scope, so I can't actually save
> the trace to see what's causing the jump, but it appears as though I rapidly
> adjusted the trigger knob so the trace scrolled for just a split second,
> then resumes normal tracing.  I'm wondering if this could be the jitter
> you're talking about?

Possibly. But it could also be as trivial as something with the trigger
function of your scope -- try experimenting with the holdoff.

The jitter I am talking about is the difference in the time to respond to
an interrupt and actually toggle the pin, which is not constant and varies
between a minimum and a maximum. The minimum depends mostly on your
interrupt code for that particular function and the maximum depends mostly
on whether you disable interrupts and on how much time you spend in other
interrupt handlers.

The effect is this: Let's say you switch on always at the start of the
period. Then all off>on transition points should be exactly one period from
each other. Because of the jitter I was talking about, the time between
them will vary, because even though the interrupt occurs at the exact time,
the code doesn't react to it instantly -- it reacts in a time between your
minimum and your maximum. The same goes for the on>off transitions. For a
given duty cycle, they should be always at the same point in the PWM
period. But due to the varying interrupt reaction time, the point where the
pin gets toggled will vary.

If you have other interrupt routines that take up considerable amounts of
time (considerable in terms of the jitter requirements of your PWM) or if
you disable interrupts somewhere for relevant amounts of time, this can
cause your PWM to jump around a bit. If that is long enough, it may look
like what you are describing, even though my first impression was that this
is caused by something else.

Using the CCP Compare method, you don't get any of this -- under the
condition of course that your code can react to the CCP interrupt
sufficiently before the next toggle should take place, to be able to set it
up properly. The bit gets toggled by hardware at the exact point in time
you set it up to toggle. You just have to make sure you get around soon
enough to be able to configure the next toggle.

Hope that was clearer...

Gerhard

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestEraseMEspamspam_OUTmitvma.mit.edu

2004\04\26@235938 by Scott Dattalo

face
flavicon
face
On Thu, 22 Apr 2004, Robert B. wrote:

> I need a PWM signal with the following specifications (from the
> manufacturer):  period 17ms, minimum duty 1ms, maximum duty 2ms.

I'm not seriously suggesting this, but as an extreme alternative you may
wish to experiment with this all-software PWM generator. It has single
instruction cycle resolution and doesn't use interrupts. In fact, it even
works on a 12-bit core! So you can do way with those expensive new-fangled
pics and go totally retro. After you get it working, I promise it will
make you really appreciate hardware PWM peripherals!

http://www.dattalo.com/technical/software/pic/pwm256.txt


Scott

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\04\27@002258 by David VanHorn

flavicon
face
>
>pics and go totally retro. After you get it working, I promise it will
>make you really appreciate hardware PWM peripherals!
>
>http://www.dattalo.com/technical/software/pic/pwm256.txt

Implementing an SMPS with this, would be really sick.
:)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\27@003437 by Scott Dattalo

face
flavicon
face
On Mon, 26 Apr 2004, David VanHorn wrote:

> >
> >pics and go totally retro. After you get it working, I promise it will
> >make you really appreciate hardware PWM peripherals!
> >
> >http://www.dattalo.com/technical/software/pic/pwm256.txt
>
> Implementing an SMPS with this, would be really sick.
> :)

Now David, I'm sure you meant to write "really slick"! Andrew Errington
(an old time Pic Lister) was using this code to PWM the voltage to some DC
motors (IIRC) on one of his robots. He also added his own code to do some
feed back control too. But Alice (another old time Pic Lister) claims that
that code is the perfect recipe for a migraine headache!

Scott

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\27@015309 by Robert B.

flavicon
face
Believe it or not I actually did implement almost precisely what you have
described at one point.  I had a problem with the interrupt routine I was
using, and got so pissed off that I just figured I could probably do it
linearly and hope for the best.  It was working well, but it screwed with
the rest of the code's somewhat delicate timing.  About that time I
discovered that "-" != "+", and fixed the interrupt.  As you predicted I
have a new appreciation for the new-fangled contraptions.  Generally I'm the
sort of guy who, when instructed to dig a trench, would rather use the well
understood (though slow, difficult, and generally crappy) shovel instead of
going out to rent-a-digger and getting a backho to do it.  At least if I
break the shovel then I know how to fix it!


{Original Message removed}

2004\04\27@021426 by David Duffy

flavicon
face
Scott Dattalo wrote:

>On Mon, 26 Apr 2004, David VanHorn wrote:
>
>
>
>>>pics and go totally retro. After you get it working, I promise it will
>>>make you really appreciate hardware PWM peripherals!
>>>
>>>www.dattalo.com/technical/software/pic/pwm256.txt
>>>
>>>
>>Implementing an SMPS with this, would be really sick.
>>:)
>>
>>
>
>Now David, I'm sure you meant to write "really slick"!
>

He probably meant sick. It means good. Or so my sons tell me! :-)
David...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...