Searching \ for 'TMR0 interrupt (PIC16c84 and PWM)' 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/ints.htm?key=interrupt
Search entire site for: 'TMR0 interrupt (PIC16c84 and PWM)'.

Truncated match.
PICList Thread
'TMR0 interrupt (PIC16c84 and PWM)'
1997\05\14@104002 by Osama ALASSIRY

flavicon
face
I can't get TMR0 overflow interrupt to work at all.

I use it to increment a counter (PWMCOUNTER) which is compared with a
certain value (PWM), if PWMCOUNTER<PWM a bit in PORTB is set, otherwise it
is reset. (using 1/8 prescaler on RTCC, INTCON: GIE and T0IE are 1, all
others 0)

I can't get it to work: the output is always LOW, which means the interrupt
doesn't happen. It works in MPSIM.

does anybody have a working fragment of such a thing. (anything with a TMR0
overflow interrupt would be great)

thank you,
_____________________________________________________
Osama ALASSIRY  spam_OUTosamaTakeThisOuTspamqatar.net.qa .....osamaKILLspamspam@spam@alassiry.com
                             http://www.alassiry.com

1997\05\14@115214 by Jorge Miguel Cabral

flavicon
face
part 0 389 bytes
I can't get it to work: the output is always LOW, which means the interrupt
doesn't happen. It works in MPSIM.

does anybody have a working fragment of such a thing. (anything with a TMR0
overflow interrupt would be great)

thank you,


Did you clear the bit RTS (option.5) and set the PSA (option.3) and RTE
(option.4)?

If soo please email me the relevant part of the code!

Cabral.

1997\05\14@130735 by Jason E. Brown

flavicon
face
At 05:28 PM 5/14/97 +0300, you wrote:
>I can't get TMR0 overflow interrupt to work at all.
>
>I use it to increment a counter (PWMCOUNTER) which is compared with a
>certain value (PWM), if PWMCOUNTER<PWM a bit in PORTB is set, otherwise it
>is reset. (using 1/8 prescaler on RTCC, INTCON: GIE and T0IE are 1, all
>others 0)
>
>I can't get it to work: the output is always LOW, which means the interrupt
>doesn't happen. It works in MPSIM.
>
>does anybody have a working fragment of such a thing. (anything with a TMR0
>overflow interrupt would be great)
>
>thank you,
>_____________________________________________________
>Osama ALASSIRY  osamaspamKILLspamqatar.net.qa .....osamaKILLspamspam.....alassiry.com
>                              http://www.alassiry.com

If it works in MPSIM, I would suggest looking to make sure you are
initializing all of you variables and registers to a known value in some
starup code..

The PIC starts up with "random" values in all of it's RAM locations,
(except some registers, see data sheet)

MPSIM starts up with all of these values at zero..

I am programming a chip today to test my PWM code using TMR0 intterupts,
I'll let you know what I find out....


Jason E. Brown
Other Worlds
3801 Dayton Blvd
Chattanooga TN 37415
(423)870-1074

EraseMEothrwrldspam_OUTspamTakeThisOuTcdc.net = business.
jebrownspamspam_OUTcdc.net   = me.

1997\05\14@174622 by Osama ALASSIRY

flavicon
face
----
From: Jorge Miguel Cabral <@spam@Jorge.CabralKILLspamspamDEI.UMINHO.PT>
To: KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
Date: 15 May 1997 0:48 AM
Subject: Re: TMR0 interrupt (PIC16c84 and PWM)

>
<!--SNIPPED-->
> Did you clear the bit RTS (option.5) and set the PSA (option.3) and RTE
> (option.4)?
yes!

> If soo please email me the relevant part of the code!

it was something like this (original code not on my computer right now):
|   org 0
|   goto start
|   org 4
|isr
|  ;SAVE W and STATUS (from a microchip book)
|  BCF INTCON,IT0F (or something like that, clear overflow)
|  INCF PWMCOUNTER
|  ;COMPARE PWMCOUNTER with PWM
|  ;if < : bsf PORTB,0
|  ;if > : bcf PORTB,0
|  ;Restore W and STATUS (from a microchip book)
|   RETFIE
|start goto start ; infinite loop



I just  don't know what could be wrong...

1997\05\15@095859 by myke predko

flavicon
face
Osama,

Could you please post the *actual* code?  I find that little problems in
assembler that screw up the whole program can be stared at for hours by the
author without seeing them.

As well, have you run your code through the simulator (my first line of
defense/verification before I burn a part)?

myke
{Quote hidden}

"My ancestors didn't spend millions of years clawing their way to the top of
the food chain, just so I could become a vegetarian"

1997\05\15@111420 by Osama ALASSIRY

flavicon
face
the *ACTUAL* code is at the uni (closed Thursdays and Fridays :(  )  i'll
get it on Saturday and post it...

it does run on the simulator. (this is what puzzles me most! shouldn't
MPSIM be fully compatible with the real thing?)

thanks.
----
From: myke predko <TakeThisOuTmykeEraseMEspamspam_OUTPASSPORT.CA>
To: RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU
Date: 15 May 1997 23:46 PM
Subject: Re: TMR0 interrupt (PIC16c84 and PWM)

>Osama,
>
>Could you please post the *actual* code?  I find that little problems in
>assembler that screw up the whole program can be stared at for hours by
the
>author without seeing them.
>
>As well, have you run your code through the simulator (my first line of
>defense/verification before I burn a part)?
>
>myke

1997\05\15@170402 by myke predko

flavicon
face
Osama wrote:
>the *ACTUAL* code is at the uni (closed Thursdays and Fridays :(  )  i'll
>get it on Saturday and post it...
>
>it does run on the simulator. (this is what puzzles me most! shouldn't
>MPSIM be fully compatible with the real thing?)

What I mean to say there are a lot of cases where the simulator seems to
indicate that something is working, but when you get out into the real
world, it upchucks.

Last year, I spent about three weeks trying to nail down a problem that
worked fine in the simulator, but when I actually tried it out on hardware,
the device just sat there and did nothing.  I finally traced the problem to
how I was simulating it, I had a delay routine that I skipped over in the
simulator because it took about an hour and a half to run (it delayed the
PIC for about 3 seconds).

The problem ended up being that the interrupt routine that I was debugging
was active during this delay, but needed variables which were initialized
*after* the delay routine.  It worked fine when the delay routine was
skipped and the interrupt didn't happen until after the variables were
initialized, but wouldn't work at all when the delay routine was working.

It didn't matter how hard I stared at it - it worked fine in the simulator
and wouldn't work in the device.  Maybe this is a case that would be
immediately obvious if you had an emulator.


Just reviewing this and realizing there is one MAJOR difference between
MPSIM (and MPLAB-SIM) and a real PIC.  That's in how the registers come up
initialized.  In both simulators, they are initialized to 0x000 and in the
PIC, they can be anything.

I just went back to your original note and I'm thinking that this is
probably your problem.  In the code you wrote, you didn't show how the PWM
variables were initialized.  I suspect that you probably don't initialize
PWMCounter (because it shows up as 0x000 in the simulator) and when you run
your code it's actually greater than the test values (and nothing ever gets
output).


Just a question for everybody who's used a PIC emulator more than I have
(because I didn't think to look for this when I was lent a PICMaster), what
do the Register Values initialize to?


When you get the code, we should be able to find the problem,

myke
{Quote hidden}

"My ancestors didn't spend millions of years clawing their way to the top of
the food chain, just so I could become a vegetarian"

1997\05\17@042703 by Osama ALASSIRY

flavicon
face
part 0 3674 bytes content-type:application/octet-stream;thank you.
----
From: myke predko <RemoveMEmykeEraseMEspamEraseMEPASSPORT.CA>
To: RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU
Date: 16 May 1997 6:45 AM
Subject: Re: TMR0 interrupt (PIC16c84 and PWM)

>Osama wrote:
>>the *ACTUAL* code is at the uni (closed Thursdays and Fridays :(  )
i'll
{Quote hidden}

hardware,
>the device just sat there and did nothing.  I finally traced the problem
to
>how I was simulating it, I had a delay routine that I skipped over in the
>simulator because it took about an hour and a half to run (it delayed the
>PIC for about 3 seconds).
>
>The problem ended up being that the interrupt routine that I was
debugging
>was active during this delay, but needed variables which were initialized
>*after* the delay routine.  It worked fine when the delay routine was
>skipped and the interrupt didn't happen until after the variables were
>initialized, but wouldn't work at all when the delay routine was working.
>
>It didn't matter how hard I stared at it - it worked fine in the
simulator
>and wouldn't work in the device.  Maybe this is a case that would be
>immediately obvious if you had an emulator.
>
>
>Just reviewing this and realizing there is one MAJOR difference between
>MPSIM (and MPLAB-SIM) and a real PIC.  That's in how the registers come
up
>initialized.  In both simulators, they are initialized to 0x000 and in
the
>PIC, they can be anything.
>
>I just went back to your original note and I'm thinking that this is
>probably your problem.  In the code you wrote, you didn't show how the
PWM
>variables were initialized.  I suspect that you probably don't initialize
>PWMCounter (because it shows up as 0x000 in the simulator) and when you
run
>your code it's actually greater than the test values (and nothing ever
gets
>output).
>
>
>Just a question for everybody who's used a PIC emulator more than I have
>(because I didn't think to look for this when I was lent a PICMaster),
what
{Quote hidden}

in
{Quote hidden}

of
>the food chain, just so I could become a vegetarian"
>

Content-Type: application/octet-stream;
       name="Pwm.asm"
Content-Disposition: attachment;
       filename="Pwm.asm"

Attachment converted: wonderland:Pwm.asm (????/----) (00002DF8)

1997\05\18@005528 by Mike Smith

flavicon
face
----------
> From: Osama ALASSIRY <RemoveMEosamaKILLspamspamALASSIRY.COM>
> To: PICLISTSTOPspamspamspam_OUTMITVMA.MIT.EDU
> Subject: Re: TMR0 interrupt (PIC16c84 and PWM)
> Date: Saturday, 17 May 1997 17:46
>
> attached the code, I hope somebody can see what's wrong!!
>

Just for a start, DON'T re-enable GIE inside the ISR.  The RETFIE
instruction does this automagically, and, if you have had an int whilst
processing the isr, you'll blow your stack really quickly this way.  This
is the sort of thing a simulator will probably never find, BTW, as its very
time-sensitive.

MikeS
<spamBeGonemikesmith_ozSTOPspamspamEraseMErelaymail.net>

1997\05\18@204103 by John Payson

picon face
> Just for a start, DON'T re-enable GIE inside the ISR.  The RETFIE
> instruction does this automagically, and, if you have had an int whilst
> processing the isr, you'll blow your stack really quickly this way.  This
> is the sort of thing a simulator will probably never find, BTW, as its very
> time-sensitive.

As a slight clarification, never enable GIE within an ISR unless you are
absolutely sure you know what you're doing *AND* you have counted up the
stack overhead.  I have on a couple of programs used a short ISR which ran,
essentially, this:

       [ save W and PSW ]
       [ do a little bit of work]
       [ restore W and PSW ]
       decfsz  counter,f
        retfie
       bsf     gie
       [ save W and PSW to another pair of locations]
       [ set up counter again]
       [ do 'a lot' more work (more than a timer-ticks' worth ]
       [ restore PSW and W]
       retfie

My smaller interrupt routine does not make any sub-calls.  My larger one
does make one level of calls, but they are "guarded" with disable-timer
interrupt and enable-timer interrupt instructions.

For applications where an ISR has to do periodic "thinks" but mostly just
keeps a counter or two, I think this approach is an excellent one.  Has
anyone else used it?

1997\05\19@000311 by Mike Smith

flavicon
face
----------
> From: John Payson <KILLspamsupercatspamBeGonespamMCS.NET>
> To: EraseMEPICLISTspamEraseMEMITVMA.MIT.EDU
> Subject: Re: TMR0 interrupt (PIC16c84 and PWM)
> Date: Monday, 19 May 1997 09:58
>
> > Just for a start, DON'T re-enable GIE inside the ISR.  The RETFIE
> > instruction does this automagically, and, if you have had an int whilst
> > processing the isr, you'll blow your stack really quickly this way.
This
> > is the sort of thing a simulator will probably never find, BTW, as its
very
> > time-sensitive.
>
> As a slight clarification, never enable GIE within an ISR unless you are
> absolutely sure you know what you're doing *AND* you have counted up the
> stack overhead.  I have on a couple of programs used a short ISR which
ran,
{Quote hidden}

That's an interesting exception to the rule.  Must make a note of it.
Almost reminds me of Windows background processing <g>

MikeS
<@spam@mikesmith_oz@spam@spamspam_OUTrelaymail.net>

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