Searching \ for '[PIC]:Timer2 IRQ on F628' 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/time.htm?key=time
Search entire site for: 'Timer2 IRQ on F628'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:Timer2 IRQ on F628'
2002\04\16@173756 by Jinx

face picon face
I'm having trouble getting a TMR2 interrupt.The code below
outputs a 240Hz / 50% PWM from Portb.3  The intention is
to use the TMR2 IRQ as a signal to read external pots (via a
4051 and TLC549) that are adjusted to modify the frequency
/ duty cycle. A match is occuring between TMR2 and PR2 as
the PWM maintains itself. I've used Timer0 as an alternate
source and the ISR does get entered as expected

The concept is fairly similar to Olin's HAL project, in that during
the ISR a new value may be loaded into CCPR1L. However, as
Olin's writing style is quite different to mine I may have missed
something with the IRQ set-up. Microchip seem not to have any
examples of TMR2 IRQ code (they poll TMR2IF), so I'm looking
for help

TIA

===================================================

        list p=16F628
        #include <p16F628.inc>

led equ 0x07

      __config _intrc_osc_noclkout & _wdt_off & _pwrte_on & _lvp_off &
_boden_off

        org 0x00
        goto entry

        org 0x04
        goto irq

entry    clrf   porta
        movlw  0x07
        movwf  cmcon
        clrf   status        ;set rp0, rp1 = 0 = Bank0

        bsf    status,rp0    ;tris registers in bank1
        bcf    status,rp1

        movlw  b'00000000'   ;oooo oooo , Porta all o/p
        movwf  trisa

        movlw  b'00100000'   ;ooio oooo all o/p except Serial Data
        movwf  trisb

        movlw  0x86                ;TMR0 pre-scaler= 128 =30Hz IRQ
        movwf  option_reg

        bcf    status,rp0
        bcf    status,rp1

        clrf   porta           ;4051 A = B = C = 0
        clrf   ashad         ;clear shadow

        movlw  b'01010000'   ;TLC549 Clock high, CS high
        movwf  portb
        clrf   fsr

        clrf   ccp1con       ;CCP Module off, set up PWM
        clrf   tmr2
        movlw  b'11111100'   ;TMR2 - PR2 match value
        movwf  pr2
        movlw  b'01111111'   ;duty cycle MSBs
        movwf  ccpr1l
        clrf   intcon
        bsf    status,rp0
        clrf   pie1
        bcf    status,rp0
        clrf   pir1
        movlw  b'00011100'   ;DC LSBs <5:4>, 11xx = PWM mode
        movwf  ccp1con
        bcf    t2con,t2ckps0 ;PS 00 1: 1
                                          ;       01 1:4  selected
        bsf    t2con,t2ckps1 ;       1x 1:16
        nop
        bsf    t2con,tmr2on  ;Timer2 enabled

        bsf    intcon,peie       ;enable peripheral IRQs
        bsf    pie1,tmr2ie      ;enable TMR2 IRQs
        bcf    pir1,tmr2if        ;reset TMR2 IRQ flag

;         bsf    intcon,t0ie
         bsf    intcon,gie        ;enable IRQs

loop     goto   loop

;=============================
;        ISR
;=============================

irq      bcf    pir1,tmr2if        ;reset IRQ source flags
        bcf    intcon,t0if

        bsf    portb,led            ;ISR activity indicator
        nop
        bcf    portb,led

        retfie                            ;temporary return

        movwf  wtemp
        swapf  status,w
        movwf  stemp

        call   readadc              ;get pot value

        movf   dbuff,w
        movwf  ccpr1l              ;into PWM DC register

        swapf  stemp,w
        movwf  status
        swapf  wtemp,f
        swapf  wtemp,w
        retfie

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


2002\04\16@185553 by Olin Lathrop

face picon face
> The concept is fairly similar to Olin's HAL project, in that during
> the ISR a new value may be loaded into CCPR1L. However, as
> Olin's writing style is quite different to mine I may have missed
> something with the IRQ set-up.

I know you don't like the way I write code, but you could really use
something like my DBANKIF macro.  All those hard coded BSF STATUS,RPn make
me very nervous and they are too time consuming to check by hand.  I'd
rather have the assembler calculate that stuff for me.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2002\04\16@193903 by Jinx

face picon face
I found the problem - banking

"D'oh" just isn't enough. Justifies a "Shazbat" I think

Olin, in his example, precedes the setting of PIE1 with

dbankif pie1

which allows access to PIE1 in bank1.

The amended code

         bsf    intcon,peie       ;enable peripheral IRQs

         bsf    status,rp1         ;added
         bsf    pie1,tmr2ie      ;enable TMR2 IRQs
         bcf    status,rp0         ;added

         bcf    pir1,tmr2if        ;reset TMR2 IRQ flag

does now generate TMR2 interrupts @ 1/16th (or any other
division ratio as set by the postscaler) of the PWM frequency

Thanks to all, especially me for finding it first ;-) ;-(

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


2002\04\16@194720 by Jinx

face picon face
> I know you don't like the way I write code, but you could
> really use something like my DBANKIF macro.  All those
> hard coded BSF STATUS,RPn make me very nervous
> and they are too time consuming to check by hand.  I'd
> rather have the assembler calculate that stuff for me

I don't mind your writing style at all - it's just different to
the way I do it. As you'll see from my other post, I found
the problem. Olin 1 Jinx 0 ;-)  I take your point about
using bank-switching macros, but in this case it was
simply a case of not RTFM properly on my part and
missing the fact that the answer was right in front of
me in your code

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


2002\04\17@035433 by Alan B. Pearce

face picon face
>I found the problem - banking
>"D'oh" just isn't enough. Justifies a "Shazbat" I think
>Olin, in his example, precedes the setting of PIE1 with
>dbankif pie1
>which allows access to PIE1 in bank1.

Now you know why Olin's macros are so good. Just put a dbankif in front of
every register reference, and if it is not needed no code is generated.

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


2002\04\17@040743 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Alan B. Pearce [SMTP:EraseMEA.B.Pearcespam_OUTspamTakeThisOuTRL.AC.UK]
> Sent: Wednesday, April 17, 2002 8:52 AM
> To:   PICLISTspamspam_OUTMITVMA.MIT.EDU
> Subject:      Re: [PIC]:Timer2 IRQ on F628
>
> >I found the problem - banking
> >"D'oh" just isn't enough. Justifies a "Shazbat" I think
> >Olin, in his example, precedes the setting of PIE1 with
> >dbankif pie1
> >which allows access to PIE1 in bank1.
>
> Now you know why Olin's macros are so good. Just put a dbankif in front of
> every register reference, and if it is not needed no code is generated.
>
>
Hmm, surely this can't work for goto's and calls can it?  The assembler
dosen't (AFAIK) follow the flow of the code so it can't know if any
particular bit of code has already had the banks bits set before a branch
somewhere else in the program, or am I missing something obvious (as usual).

Mike

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


2002\04\17@041153 by Jinx

face picon face
> Now you know why Olin's macros are so good. Just put
> a dbankif in front of every register reference, and if it is
> not needed no code is generated

Think I've been bitten once too often now. BTW, not my
day is it - that banking correction I posted had a typo in
it. Sigh. I wrote bsf status,rp1 instead of bsf status,rp0.
Had too many 1's on my mind

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


2002\04\17@050251 by Alan B. Pearce

face picon face
>Hmm, surely this can't work for goto's and calls can it?  The assembler
>dosen't (AFAIK) follow the flow of the code so it can't know if any
>particular bit of code has already had the banks bits set before a branch
>somewhere else in the program, or am I missing something obvious (as
usual).

You are correct, but have gone somewhat further in the process than the
discussion had. If you use Olin's macros then at each global call the
assembler banking assumptions get invalidated, and so the dbankif macro puts
code in to be failsafe. However if you are aware that a certain bank will
always be selected on entry, then the invalidation can be over-ridden.

It is worth downloading Olin's code development suite and having a pass
through it to see just how it works. I do not claim it is a panacea for all
woes, but it certainly helps to protect against the loop that Jinx has just
been through.

You may decide to not use it as it stands, but it will certainly give some
useful tips.

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


2002\04\17@062420 by Jinx

face picon face
I've uploaded the fruits of today's labours to

http://home.clear.net.nz/pages/joecolquitt/mixer.html

Not finished or polished by any means, still testing, but it's
something to work from. A couple of questions -

As noted, the lowest PWM frequency with a 4MHz clock is
(I believe) 244Hz. The only way I can think of to slow this
down to, say, 0.5Hz is to reduce the clock to (0.5/244) x 4MHz
or 8196Hz. Now, this can be done manually with a pot or
preferably with digital selection, ie the PIC is told to alter
its own clock frequency, perhaps by switching resistors with
a 4016 or by using a pot IC. Assuming make-before-break
switching so that a resistor is always present, any problems ?

Any other ideas to reduce the frequency off-PIC and maintain
the duty cycle ? Perhaps even another PIC as a stretcher ?

The granularity or resolution of the frequency and duty cycle
becomes calculably coarser with increasing frequency. As
the program stands now it's possible (bearing in mind that
granularity) to set by pot the duty cycle at any frequency. At
the lower frequencies the full angular range of the DC pot
is usable, but of course the higher the frequency, the less
the pot needs to travel from the 0% to the 100% position. Is
a table going to be the best solution to scale the pot reading
so that at any frequency the full travel of the pot is usable
(although the % change per degreee will increase as the
frequency increases) ?

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


2002\04\17@071013 by Michael Rigby-Jones

flavicon
face
{Quote hidden}

Well, the book says PWM period = (PR2+1) x 4 x Tosc x TMR2Prescale

At 4MHz (Tosc = 0.25uS) this gives a minimum frequency of:

1 / ((255+1) x 4 x 0.25E-6 x 8) = 488Hz so I'm probably doing something
wrong...

As you noted, there is a tradeoff between resolution and frequency.  What I
don't quite understand is that on your web page you mention that your upper
frequency is limited to 6700Hz due to having to read the ADC.  However, the
CCP module runs totaly independantly of the code, so this should not limit
you in any way.  In fact using the above formula:

1 /  ((0+1) x 4 x 0.25E-6 x 1) = 1MHz.  Unfortuanetly this won't be very
usefull as you will have zero control of the duty cycle :o)  However, you
can hit 15Khz with 8 bit resolution.

If you don't need the higher frequencies you could just use a lower
frequency clock e.g. 500Khz would give you a lowest frequency of 61Hz and a
max frequency of just under 2KHz (for 8 bit resolution).

Cheers

Mike

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


2002\04\17@074039 by Jinx

face picon face
> PWM period = (PR2+1) x 4 x Tosc x TMR2Prescale
>
> At 4MHz (Tosc = 0.25uS) this gives a minimum frequency of:
>
> 1 / ((255+1) x 4 x 0.25E-6 x 8) = 488Hz so I'm probably doing
> something wrong...

The pre-scaler has 1:1, 1:4 and 1:16 flavours, there's no 1:8

> As you noted, there is a tradeoff between resolution and
> frequency.  What I don't quite understand is that on your web
> page you mention that your upper frequency is limited to
> 6700Hz due to having to read the ADC.

It's not so much that the frequency can't go higher, it's that the
wave breaks up with the code the way it is. One thing I'd need
to do if I wanted higher speed PWM (which I don't in this case)
is to tidy up the ADC routine as much as possible and read just
one pot per ISR iteration, cycling through however many are
attached on successive IRQs. The PWM doesn't have to be
modified on each cycle, although at low frequencies the time
between readings for a particular pot may be too long, so the
s/w needs to know the frequency in order to adjust measurement
timing

> If you don't need the higher frequencies you could just use a lower
> frequency clock e.g. 500Khz would give you a lowest frequency of
> 61Hz and a max frequency of just under 2KHz (for 8 bit resolution)

If I did run the PIC at 8196Hz to get the lowest PWM required of
0.5Hz (with a 1:16 prescaler), the maximum speed attainable would
be ((0.5/244) x 6700) x 16 = 220Hz (by changing to a 1:1 prescaler).
This is too low for the top end, so I still need to decrease Tosc

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


2002\04\17@075123 by Michael Rigby-Jones

flavicon
face
> -----Original Message-----
> From: Jinx [SMTP:RemoveMEjoecolquittTakeThisOuTspamCLEAR.NET.NZ]
> Sent: Wednesday, April 17, 2002 12:38 PM
> To:   spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU
> Subject:      Re: [PIC]:Timer2 IRQ on F628
>
> > PWM period = (PR2+1) x 4 x Tosc x TMR2Prescale
> >
> > At 4MHz (Tosc = 0.25uS) this gives a minimum frequency of:
> >
> > 1 / ((255+1) x 4 x 0.25E-6 x 8) = 488Hz so I'm probably doing
> > something wrong...
>
> The pre-scaler has 1:1, 1:4 and 1:16 flavours, there's no 1:8
>
Ahh, it would help if Iooked the the TIMER2 details instead of TIMER1.
You'd have though 15 cups of coffee would be enough wouldn't you?

Cheers

Mike

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


2002\04\17@075955 by Bob Ammerman

picon face
At low PWM frequencies you can switch from using hardware PWM to doing it
with some software assist (ie: in an interrupt handler). You'll probably end
up with a bit of jitter in the result, but it will usually be acceptable for
most applications.

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Michael Rigby-Jones" <TakeThisOuTmrjonesEraseMEspamspam_OUTNORTELNETWORKS.COM>
To: <RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Wednesday, April 17, 2002 7:08 AM
Subject: Re: [PIC]:Timer2 IRQ on F628


> > {Original Message removed}

2002\04\17@082705 by Jinx

face picon face
> At low PWM frequencies you can switch from using hardware
> PWM to doing it with some software assist (ie: in an interrupt
> handler)

Yes, that was something I'd considered and had started to
put TMR0 code in. Jitter or frequency accuracy isn't an issue
for this application. It has actually turned into "learn PWM",
which is no bad thing although, truth be told, I could do the
whole lot with TMR0. One or two aspects of this project could
even have 555s as voltage-controlled PWM generators,
voltage coming from the PIC via RC

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


2002\04\17@100702 by Olin Lathrop

face picon face
> > Now you know why Olin's macros are so good. Just put a dbankif in front
of
> > every register reference, and if it is not needed no code is generated.
> >
> >
> Hmm, surely this can't work for goto's and calls can it?  The assembler
> dosen't (AFAIK) follow the flow of the code so it can't know if any
> particular bit of code has already had the banks bits set before a branch
> somewhere else in the program, or am I missing something obvious (as
usual).

You're right, its not totally idiot proof.  You have to cooperate to tell
the assembler that it doesn't know what the bank settings are.  Some of my
other macros do this implicitly, like those that define a subroutine entry
point or do a call.  See the MCALL (local call within a module), GCALL
(global call, outside module), GLBENT (global subroutine entry point) and
related macros.  These take care of most of the cases except local jump
points.  When cycles and memory aren't much of an issue, I usually just put
a UNBANK at each label.  In critical places like interrupt routines I
sometimes go to a bit more trouble to know what the bank setting will be at
a jump target and then use DBANKIS to tell the assembler.

You do have to take care in a few places, but all in all it is still *much*
superior to manually writing instructions to diddle the RPn bits in STATUS.
You don't even have to know (and therefore can't get it wrong) what bank a
special function register is in.  You just DBANKIF to it then access it.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

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


2002\04\17@101951 by Scott Dattalo

face
flavicon
face
On Wed, 17 Apr 2002, Bob Ammerman wrote:

> At low PWM frequencies you can switch from using hardware PWM to doing it
> with some software assist (ie: in an interrupt handler). You'll probably end
> up with a bit of jitter in the result, but it will usually be acceptable for
> most applications.


I agree. I have a couple comments (and I haven't read the whole thread so
these comments may not be appropriate).

Varying the PIC's oscillator frequency is a perfectly reasonable approach
to obtain a lower frequency PWM. In one application I needed a constant
duty cycle, but variable frequency PWM. The frequency was controlled via a
POT as part of the R in an RC oscillator.

For the software approach, I can imagine several different solutions. One
is to manipulate the PWM registers in such a way that the oscillator
frequency can be made slower. For example, you (Jinx) could re-write TMR2
or change the mode of the capture/compare/pwm (e.g. disable the PWM
functionality until it's needed).

Another software approach is to write an interrupt driven software PWM
routine. It would be much coarser than the hardware PWM. Furthermore, it
will not transition smoothly between software - hardware - software PWM
control.

If you want smooth transitioning, then you can implement a single
cycle resolution PWM routine:

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

But I think that may be a little overkill :). OTOH, you could ditch
hardware PWM altogether with this routine and control the PWM with any
dutycycle/frequency you'd like. The only problem with this routine is that
it's been known to induce migraines. BTW, as listed this routine is only
an 8-bit PWM. However, I've used it to generate 12-bit pwm too. Extending
it to 16 or 24-bits is, well not trivial, but doable. A 24-bit PWM driven
by a 20-MHz crystal will yield an oscillation frequency of 0.298 Hz. If
that'a not low enough, you can add 8 more bits and drop it down to 1mHz!


Scott

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


2002\04\17@192854 by Jinx

face picon face
> Varying the PIC's oscillator frequency

> software approach, I can imagine several different solutions

Thanks for the comments Scott. I'm generally happy with what
I've got as a starting point, but some tweaking is needed that
may call for s/w to augment the h/w PWM mode

For example better resolution at low duty cycles, as the
difference between 1% and 2% DC has a more pronounced
effect (in this application) than the difference between, say,
81% and 82% DC

I doubt RC mode will go up to 20MHz, probably half that. A
variable external clock might be the answer. I'm looking at
the MAX038. It can have up to a 350:1 range by applying a
voltage of 20mV - 7500mV or using a potentiometer. It looks
able to provide any frequency from 8kHz to 20MHz with a
10-turn pot

http://dbserv.maxim-ic.com/quick_view2.cfm?qv_pk=1257

I think someone at Maxim has a downer on electrolytics -

"Polarised capacitors are generally not recommended
because of their outrageous temperature dependence
and leakage currents"

Outrageous ? ;-)

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


2002\04\17@200450 by Tony Nixon

flavicon
picon face
Jinx wrote:

> "Polarised capacitors are generally not recommended
> because of their outrageous temperature dependence
> and leakage currents"
>
> Outrageous ? ;-)

Watching too much Monty Python perhaps...

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesEraseMEspam.....bubblesoftonline.com

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


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