Searching \ for '[PIC] Using PWM in hardware the right choice?' 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: 'Using PWM in hardware the right choice?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Using PWM in hardware the right choice?'
2008\10\14@111308 by James Cizek

flavicon
face


  I have been tinkering around with a new project that needs to send Extended NEC protocol
 over IR.  The protocol uses a time based unit consisting of a pulse 2.25ms long with the
 first 560uS containing the 38khz modulation and the rest of the 2.25ms with no output.
 Similiarly a logical "0" is a 1.12ms pulse with the first 560uS containing the modulation.

 I have never used a hardware PWM port on the PIC before and am wondering if that is a more
 efficient way to go than to generate the 38khz in software.  I have been looking specifically
 at the PIC16F628.  I have 2 questions for the group. 1) Do you recommend using the hardware PWM
 for the modulation to simplify coding and 2) What is the "appropriate" way of turning the
 38khz on and off?  It looks like maybe enabling and disabling the associated TMR will do it,
 but is that the right way?

 Many thanks.
 -James

2008\10\14@114141 by Wouter van Ooijen

face picon face
>   I have never used a hardware PWM port on the PIC before and am wondering if that is a more
>   efficient way to go than to generate the 38khz in software.  I have been looking specifically
>   at the PIC16F628.  I have 2 questions for the group. 1) Do you recommend using the hardware PWM
>   for the modulation to simplify coding and 2) What is the "appropriate" way of turning the
>   38khz on and off?  

1) unless you have something else for the chip to do, I would suggest
generating the carrier in software. It is pretty trivial, just
blink-a-led but a bit faster.

2) how about setting the I/O pin to input?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\10\14@114735 by Jan-Erik Soderholm

face picon face
James Cizek wrote:
>
> 1) Do you recommend using the hardware PWM
> for the modulation to simplify coding

Yes.

> 2) ...It looks like maybe enabling and disabling the
> associated TMR will do it,but is that the right way?

It's *one* way. And not a *bad* way at all.
If it's the *right* way is much harder to say... :-)

When I did something similar, I turned the PWM module
on/off right at the timer "edges" so I always got clean
38 KHz signal without any half pulses.

Jan-Erik.

2008\10\14@115641 by Timothy Weber

face picon face
Wouter van Ooijen wrote:
>>   I have never used a hardware PWM port on the PIC before and am wondering if that is a more
>>   efficient way to go than to generate the 38khz in software.  I have been looking specifically
>>   at the PIC16F628.  I have 2 questions for the group. 1) Do you recommend using the hardware PWM
>>   for the modulation to simplify coding and 2) What is the "appropriate" way of turning the
>>   38khz on and off?  
>
> 1) unless you have something else for the chip to do, I would suggest
> generating the carrier in software. It is pretty trivial, just
> blink-a-led but a bit faster.

38 kHz means a carrier state change about every 13 us.  That's probably
doable, but seems a little tight to me.  I think I'd rather use the PWM
and still be able to use the internal oscillator at 4 MHz.

... and hey - that's exactly what I'm doing for another IR project right
now!
--
Timothy J. Weber
http://timothyweber.org

2008\10\14@150016 by Wouter van Ooijen

face picon face
>> 1) unless you have something else for the chip to do, I would suggest
>> generating the carrier in software. It is pretty trivial, just
>> blink-a-led but a bit faster.
>
> 38 kHz means a carrier state change about every 13 us.  That's probably
> doable, but seems a little tight to me.  I think I'd rather use the PWM
> and still be able to use the internal oscillator at 4 MHz.

Your free to do whatever you want, but you were asking..

13 us for a state change. At 4 MHz that's 13 instructions. Even with a
shadow register a state change takes 3 instructions when the flush is
in-line (or just 2), or maybe 7 instruction-cycles when the shadow-flush
is a subroutine. I don't see how 13 can be too tight.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\10\14@151925 by Dr Skip

picon face
Why wouldn't this be a good application for a separate osc.? Even a 555 can be
freq and pwm varied by an input IIRC...

Assuming the pic will be doing a few other 'higher level' things, using it for
this too seems a waste of horsepower and added code complexity, which is
sometimes more risky than a simple bit o' hardware. If it's dedicated to this
function, the 555 is a cheaper substitute.

-Skip


Wouter van Ooijen wrote:
>
> Your free to do whatever you want, but you were asking..
>
> 13 us for a state change. At 4 MHz that's 13 instructions. Even with a
> shadow register a state change takes 3 instructions when the flush is
> in-line (or just 2), or maybe 7 instruction-cycles when the shadow-flush
> is a subroutine. I don't see how 13 can be too tight.
>

2008\10\14@173628 by Chris McSweeny

picon face
Am I missing something here? What is the possible objection to using the
hardware PWM? Really can't see any downsides to it - why add an extra 555
chip when you can set the PIC up to provide this square wave without it
adding at all to the code complexity or interfering with higher level
functions - simply set it up once and then turn on and off as necessary
(which is just as easy as setting an output pin to turn an external signal
on and off).
Chris

2008\10\14@181821 by Jan-Erik Soderholm

face picon face
Dr Skip wrote:
> Why wouldn't this be a good application for a separate osc.? Even a 555 can be
> freq and pwm varied by an input IIRC...
>
> Assuming the pic will be doing a few other 'higher level' things, using it for
> this too seems a waste of horsepower and added code complexity,

The complexity is just 5-10 extra instructions in some
initialization routine to setup the PWM module. After that
is done, there isn't one single instruction cycle "wasted"
on it any more.

> which is
> sometimes more risky than a simple bit o' hardware. If it's dedicated to this
> function, the 555 is a cheaper substitute.

Adding to something can never make the total sum less.

Jan-Erik.


2008\10\14@201341 by Dr Skip

picon face


Jan-Erik Soderholm wrote:
> Adding to something can never make the total sum less.

Indeed... but if you read the suggestion, it is offering a trade of code for
offloading a function to other hardware - a perfectly reasonable suggestion.
The discussion should address the tradeoff, not get mired in pedantic comments.
The sum is less if the functional risks cost more than the hardware.

If the original author decided to not use the PWM piece and do it in software,
there can be a point which it may not be adequate for all of the other tasks he
may want it to do. The discussion was about whether to use the PWM module,
which saves 'cost' in code, or not. I was pointing out that there are other
'cheap' ways to do it. Should timings be tight, doing it all in code (if there
was an aversion the the PWM module use) might have more risk than adding a
chip. If there were no question about using the module, this thread wouldn't exist.

-Skip

2008\10\14@201804 by gardenyu

picon face
part 1 1460 bytes content-type:text/plain; charset="gb2312" (decoded quoted-printable)

Do you mean using 555 as something like a sawtooth generator and then "AND" it with the incoming signal to get the required pulse?
 


> Date: Wed, 15 Oct 2008 00:18:20 +0200> From: spam_OUTjan-erik.soderholmTakeThisOuTspamtelia.com> To: .....piclistKILLspamspam@spam@mit.edu> Subject: Re: [PIC] Using PWM in hardware the right choice?> > Dr Skip wrote:> > Why wouldn't this be a good application for a separate osc.? Even a 555 can be > > freq and pwm varied by an input IIRC...> > > > Assuming the pic will be doing a few other 'higher level' things, using it for > > this too seems a waste of horsepower and added code complexity,> > The complexity is just 5-10 extra instructions in some> initialization routine to setup the PWM module. After that> is done, there isn't one single instruction cycle "wasted"> on it any more.> > > which is > > sometimes more risky than a simple bit o' hardware. If it's dedicated to this > > function, the 555 is a cheaper substitute.> > Adding to something can never make the total sum less.> > Jan-Erik.> > > -- > http://www.piclist.com PIC/SX FAQ & list archive> View/change your membership options at> http://mailman.mit.edu/mai
lman/listinfo/piclist
_________________________________________________________________
一点即聊,MSN推出新功能“点我!”
http://im.live.cn/click/

part 2 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2008\10\14@203501 by Dr Skip

picon face
I believe there is an enable input on it. I was thinking square wave out,
on/off with the enable input.

-Skip

gardenyu wrote:
> Do you mean using 555 as something like a sawtooth generator and then "AND" it with the incoming signal to get the required pulse?
>  

2008\10\14@205047 by Jinx

face picon face
> The complexity is just 5-10 extra instructions in some
> initialization routine to setup the PWM module. After that
> is done, there isn't one single instruction cycle "wasted"
> on it any more.

This outputs 38.036kHz (@ 4MHz INTRC) on the 628's B3

(yes, I'm aware I suggested an external 555 the other day)

Predicted was 1,000,000/26 = 38.461kHz, implying that the PIC is
actually running a little slow at 3.9558MHz

        banksel pr2
        movlw   d26          ;PWM period
        movwf   pr2

        banksel ccpr1l
        movlw   d13          ;PWM duty cycle, LSB
        movwf   ccpr1l

        banksel ccpr1h
        bcf     ccpr1h,5     ;PWM duty cycle, MSB
        bcf     ccpr1h,4

        banksel t2con
        movlw   b'00000000'  ;no scalers, TMR2 off
        movwf   t2con

        banksel ccp1con
        movlw   b'00001100'  ;PWM mode
        movwf   ccp1con

To enable -

        banksel t2con
        bsf     t2con,tmr2on

The OP can use a 560us TMR0 or TMR1 interrupt to get the
560us, 1120us and 2240us data periods

Depending on required transmission range, an external transistor
might be needed

2008\10\14@205144 by Jinx

face picon face
> I believe there is an enable input on it. I was thinking square wave out,
> on/off with the enable input.

/reset

2008\10\14@205521 by Timothy J. Weber

face picon face
Wouter van Ooijen wrote:
>>> 1) unless you have something else for the chip to do, I would suggest
>>> generating the carrier in software. It is pretty trivial, just
>>> blink-a-led but a bit faster.
>> 38 kHz means a carrier state change about every 13 us.  That's probably
>> doable, but seems a little tight to me.  I think I'd rather use the PWM
>> and still be able to use the internal oscillator at 4 MHz.
>
> Your free to do whatever you want, but you were asking..

That was me; I wasn't the OP.

> 13 us for a state change. At 4 MHz that's 13 instructions. Even with a
> shadow register a state change takes 3 instructions when the flush is
> in-line (or just 2), or maybe 7 instruction-cycles when the shadow-flush
> is a subroutine. I don't see how 13 can be too tight.

If you can afford to block other code and interrupts while you're
sending, you're right, you could put it in a tight loop and blast away,
should be fine.
--
Timothy J. Weber
http://timothyweber.org

2008\10\14@210431 by James Cizek

flavicon
face


   This was what I was hoping would work, just setting the pin to input to "turn it off"
 temporarily.  Unfortunately, it doesn't work.  setting the pin to an input in the middle
 of the code seems not to effect the output at all, I see 38khz on B3 after the command executes.
 
 I saw some excellent code from user Jinx a few posts ago that is very nicely setup.  But instead
 of programming by fumbling around in asm like i usually do, I'm trying to learn PICbasic PRO to blast out
 a few quick projects (it's amazing how learning a higher level language can sometimes be more difficult)
 Any other ideas on switching the PWM output on and off ?  I will probably use the TMR's to time
 the pulse, but I cant get past the actual turning on and off the output yet!  Changing the T2CON
 resgister does work, but depending on where the output is in cycle, it may leave the output high or
 low...   Is it an acceptable method to change the TMR2 control and then just low the port to make sure
 the LED is off??  Doesn't seem to "precise" to me......
 Thanks for you patience and help as I learn 8-)

 -James

 


{Quote hidden}

> --

2008\10\14@212513 by Jake Anderson

flavicon
face
just a thought
use the hardware PWM output then AND that with a hardware serial port.
if you happen to have a spare and gate floating around.

I haven't used the comparator module in a PIC before but I seem to
recall some of them had an external output that you could use something
like this I'd imagine.

James Cizek wrote:
{Quote hidden}

>> --

2008\10\14@221026 by Richard Prosser

picon face
You have resistive pullups disabled?

RP

2008/10/15 James Cizek <jcizekspamKILLspamyuma.acns.colostate.edu>:
{Quote hidden}

>> --

2008\10\14@230020 by Jinx

face picon face
> Is it an acceptable method to change the TMR2 control and then just
> low the port to make sure the LED is off??

James, you have to give control back to the port output latch. If you look
at the schematic for B3 in the manual you'll see that in PWM mode the
output depends on the toggling done by TMR2. Changes made to the
port with eg bcf portb,3 will have no effect

For example, this code stops PWM with portb,3 high, as the output goes
high when TMR2 = PR2

        bcf     pir1,tmr2if
        btfss   pir1,tmr2if   ;wait for TMR2 to match PR2
        goto    $-1           ;loop
        bcf     t2con,tmr2on  ;stop TMR2

Output will be high. bcf portb,3 has no effect because it's being over-ridden
by the state of the compare register. Which, as above, is high

You need to disable PWM mode for the port command to work

        clrf    ccp1con  ;or clear just bits 3 and 2

As noted in the manual, clearing CCP1CON sets the PWM comparator
output to 0. What appears on B3 now is whatever was previously, before
PWM was enabled. You can now use B3

        bcf     portb,3

Re-enable PWM by setting bits 3 and 2 of CCP1CON

2008\10\14@230430 by Isaac Marino Bavaresco

flavicon
face
This should stop the PWM (for a 16F627A/628A/648A):

       banksel CCP1CON
       clrf CCP1CON
       bcf PORTB,3 ; This is necessary, or else the pin will stay in
the last state.

To re-enable:

       banksel TMR2
       clrf TMR2      ;   To ensure deterministic delay
       movlw 0x0c    ;    == b'00001100' == d12
       movwf CCP1CON

James Cizek escreveu:
{Quote hidden}

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\10\14@233108 by James Cizek

flavicon
face


 OK!  That makes sense.  I went back and looked at the datasheet again.  Makes a lot more
 sense now!  I do have my PWM starting and stopping now.  The project is not working yet
 but I have run into a bit of a wall at this point as I don't have a storage scope or logic
 analyzer and obviously can't see the entire command pulse train I am sending out to make
 sure all the timing is right (always seems right no matter how long you look at the code!!  8-)

 Thanks to all of you that helped answer the PWM question.  At this point, I'm starting to
 think that it might be easier to write the extra code to generate the 38khz  just
 so I can keep my pulse timings more consistant!! I also have to verify that I am using
 the correct NEC protocol address for the device I'm trying to control (Olympus Evolt E-510
 digital SLR camera)  Lots of "reverse engineering" has gone into this project
 so there are lots of unknowns!  

 Thanks again to all,  -James



{Quote hidden}

> --

2008\10\15@043507 by Jinx

face picon face
> I have run into a bit of a wall at this point as I don't have a storage
> scope or logic analyzer and obviously can't see the entire command
> pulse train I am sending out to make sure all the timing is right

I could do that for you if you want. Doesn't sound too much of a fuss

e-mail me a .hex or .asm file and I'll put it into a 628 and send you an
analyser file back

> so I can keep my pulse timings more consistant !!

Be aware that INTRC does vary with voltage and temperature. If the
protocol can't take a +/- 1% variation - the parameter I think for more
recent PICs, not sure about the 628 - you might have to use a crystal

2008\10\15@064606 by olin piclist

face picon face
Jake Anderson wrote:
> use the hardware PWM output then AND that with a hardware serial port.
> if you happen to have a spare and gate floating around.

How is this better than just setting the duty cycle to 0 to turn it off?

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\10\15@071311 by Jake Anderson

flavicon
face
Olin Lathrop wrote:
> Jake Anderson wrote:
>  
>> use the hardware PWM output then AND that with a hardware serial port.
>> if you happen to have a spare and gate floating around.
>>    
>
> How is this better than just setting the duty cycle to 0 to turn it off?
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
>  
If your chip is busy doing something else its going to reduce the work
you need to do to run the stream.



2008\10\15@080814 by olin piclist

face picon face
Jake Anderson wrote:
>> How is this better than just setting the duty cycle to 0 to turn it
>> off?
>
> If your chip is busy doing something else its going to reduce the work
> you need to do to run the stream.

I thought this was about turning a 40KHz or so IR carrier on and off, with
the message being generated in the PIC.  If so, the PIC already knows when
the carrier should be on and off, so it would be simple to stuff the duty
cycle register with the 1/2 value and zero to turn the carrier on and off.
Since the duty cycle is double buffered, this also has the advantage of
outputting whole cycles.

It sounds like this is being made way more complicated than it needs to be.
Most likely the PIC has nothing else to do while the IR message is being
transmitted.  You decide due to buttons or whatever what to transmit, but
once that happens the message is sent almost instantaneously in human time.
It doesn't matter if the buttons are not being read duing that short time.
Using a CCP module would certainly work, but might be more trouble than it's
worth.  I've done several projects that included IR transmissions, and I
don't think I used a CCP module for any of them.  Some didn't even have CCP
modules, including one that worked just fine on a 10F202.

At 40KHz carrier you get 25 instructions per carrier cycle at 4MHz
oscillator.  You can easily write a subroutine that emits the number of
carrier cycles that is passed in.  I think I wrote another subroutine with
the same interface that emitted a number of empty carrier cycles, in other
words just a delay routine.  The next level up code called the two burst on
and burst off routines as needed to send the message.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2008\10\15@085543 by James Cizek

flavicon
face


  I'm using an 8MHZ crystal outboard, not the int rc although
 I don't know how forgiving the protocol is... i can't imagine
 it's TOO terribly picky as it is the one used by a TON of
 major consumer electronics manufacturers (vcrs, tv's, etc....)

  Thanks for the offer on the analyzer trace,  I'd like
 to take you up on that.  Being fairly new to the list, I wasn't
 sure about sending attachments to it, is that normal protocol
 or shall I send you my asm and hex to a private address?
 Running the risk of my address being added to another million
 spambot lists, here is my address:   james  at  colostate  dot edu

 Thanks again -James


{Quote hidden}

> --

2008\10\15@090838 by Isaac Marino Bavaresco

flavicon
face
James Cizek escreveu:
>   OK!  That makes sense.  I went back and looked at the datasheet again.  Makes a lot more
>   sense now!  I do have my PWM starting and stopping now.  The project is not working yet
>   but I have run into a bit of a wall at this point as I don't have a storage scope or logic
>   analyzer and obviously can't see the entire command pulse train I am sending out to make
>   sure all the timing is right (always seems right no matter how long you look at the code!!  8-)
>  

You may simulate your application in MPLAB-IDE. It have a nice simulated
logic analyzer.
As in this case you don't need to interface with complex real hardware,
just watch a single signal, it would be easy.
__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2008\10\15@091656 by Tech

flavicon
face
part 1 2366 bytes content-type:text/plain; format=flowed; charset="iso-8859-1"; (decoded 7bit)


----- Original Message -----
From: "Olin Lathrop"
To: "Microcontroller discussion list - Public."
Sent: Wednesday, October 15, 2008 6:07 AM
Subject: Re: [PIC] Using PWM in hardware the right choice?


{Quote hidden}

I agree - it doesn't take much. I've attached a simple routine for a 10F200
automatic IR light switch. The 40kHz carrier generator routine doesn't
eat up too much rime, and it works fine even on a lowly 10F200.

Regards,

Bruce
http://www.rentron.com

part 2 2380 bytes content-type:application/x-zip-compressed; (decode)

part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2008\10\15@094532 by Bob Ammerman

picon face
Why not just set the PWM duty cycle to 0% to turn it off, then back to 50%
to turn it back on. This has the advantage of never generating a chopped-off
cycle of carrier.

-- Bob Ammerman
RAm Systems

{Original Message removed}

2008\10\15@165905 by Jinx

face picon face

> Why not just set the PWM duty cycle to 0% to turn it off, then
> back to 50% to turn it back on. This has the advantage of never
> generating a chopped-off cycle of carrier

That's true. My reply looked past that to regaining control of the
port pin, which I see now was not the OP's original problem


2008\10\15@171539 by Jinx

face picon face
>    I'm using an 8MHZ crystal outboard, not the int rc

Sorry, on re-reading it wasn't you that mentioned INTRC

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