Searching \ for '[PIC]: The neverending interrupt...' 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: 'The neverending interrupt...'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: The neverending interrupt...'
2001\09\13@014232 by Tim Hamel

picon face
Hello,

I've been recently developing an "application" to simulate sunlight (ha!).
After the first pass at programming it didn't work. For me, when I want to
debug certain parts of the program I'll do a "bsf PORTB,2" in strategically
placed parts of the code and stick an LED on the pin. So, I've narrowed down
my problems to my ISR. At the beginning of the ISR, I turn on the LED and
upon exit I turn off the bit in hopes that the LED would go off.
Unfortunately, the the LED NEVER goes off which tells me that I'm losing my
marbles. Somewhere in the ISR, it "locks up" and doesn't do anything as my
crude PWM routine cancels out. So...here's my ISR (I apologize for the
length):

int:
   movwf   _w
   incf    min,f   ;Increment minutes
   bsf PORTB,2

   movfw   min
   sublw   .60

   btfsc   STATUS,C ;Has 60 minutes passed?
   goto    hours    ;Yes
   goto    day  ;No, but we need to see how many hours have passed.

---If I comment out the above 3 instructions and put the bcf PORTB,2
instruction in the "hours" routine below, the LED will go off. So, I think,
"well, maybe this will work," and happily remove that instruction and keep
the bcf instruction at the bottom of the ISR, however, the LED still never
goes off. Does the PIC not like me peeking at its flags? <g>

hours   clrf    min      ;60 minutes passed, increment hours
   incf    hour,f
   bcf PORTB,2
day
   movfw   hour
   sublw   .12
   btfsc   STATUS,C  ;has 12 hours passed?
   goto    check     ;Yes
   btfsc   incdec,0  ;No, determine if we increase/decrease brightness
   goto    lights    ;Increase brightness
   goto    dark      ;Decrease brightness

lights  movfw   ltlvl
         sublw   .20
         btfss STATUS,C
         incf   ltlvl,f
       goto    intend

dark    movfw   ltlvl
       btfss   STATUS,Z
         decf  ltlvl,f
         goto  intend


check   btfsc incdec,0  ;What state are we in?
         goto dim    ;Time for sundown!
         clrf  hour      ;Clear the hours
         bsf   incdec,0  ;Next time around we'll increment the brightness
         incf  ltlvl,f
         goto  intend


dim  decf ltlvl,f   ;Decrease brightness for sundown
    bcf      incdec,0  ;This tells "day" that we'll decrease brightness
    clrf     hour
   goto  intend

intend  bcf PORTB,2
         bcf   INTCON,INTF  <----Fails to happen...

   movfw   _w
   retfie

As always, I would greatly appreciate any insight into my apparent loss of
marbles...

-Tim Hamel

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


2001\09\13@022103 by Jinx

face picon face
> I've been recently developing an "application" to
> simulate sunlight (ha!).

Just a moment, I'll bend over. Leastways that where ma reckons
the sun shines from ;-)

Seriously, you should clear the IRQ flag at the start of the ISR. If
the period between IRQs is shorter than the ISR execution time
you'll never get to that bcf just before the exit

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


2001\09\13@023644 by Tim Hamel

picon face
In a message dated 9/12/01 11:21:57 PM Pacific Daylight Time,
joecolquittspamKILLspamCLEAR.NET.NZ writes:


> Just a moment, I'll bend over. Leastways that where ma reckons
> the sun shines from ;-)
>
> Seriously, you should clear the IRQ flag at the start of the ISR. If
> the period between IRQs is shorter than the ISR execution time
> you'll never get to that bcf just before the exit
>

I apologize. I forgot to mention that the interrupts will be occuring at 1s
intervals (for testing only) and will be bumped up to 1 minute.

-Tim Hamel

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


2001\09\13@025225 by Jinx

face picon face
Without checking all of the permutations of the various
counter registers, it appears that program flow does
always end up at "intend".

If the 1ppm pulse is longer than the ISR then perhaps
you should test the INT pin for level before you exit the
ISR (if that won't interfere with the PWM)

wait  btfsc intpin
        goto  wait

exit

I don't know which micro you're using but on the F84 the
Option register can be set for a falling or rising edge. It
doesn't cater for "level". Perhaps there's a little noise on the
signal that's causing ISR re-entry. With a cursory glance the
s/w looks OK, maybe you should have a look at the signal

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


2001\09\13@035337 by Jinx

face picon face
> Somewhere in the ISR, it "locks up"

Do you mean PC never returns to the main loop ? Have you
tried the LED test outside the ISR ? It looks as though you're
getting a 1ppm signal from somewhere and using to increment
the minute counter. Have you checked that signal ?

>     btfsc   STATUS,C ;Has 60 minutes passed?
>     goto    hours    ;Yes
>     goto    day  ;No, but we need to see how many hours have passed.

You could knock out an instruction here

btfss status,c
goto day

hours

>   btfsc   incdec,0  ;No, determine if we increase/decrease brightness
>   goto    lights    ;Increase brightness
>   goto    dark      ;Decrease brightness

and here

btfss incdec,w
goto dark

lights

> As always, I would greatly appreciate any insight into my apparent
> loss of marbles...

Have they rolled under the desk ?

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


2001\09\13@035343 by Tim Hamel

picon face
In a message dated 9/12/01 11:53:18 PM Pacific Daylight Time,
@spam@joecolquittKILLspamspamCLEAR.NET.NZ writes:


> Without checking all of the permutations of the various
> counter registers, it appears that program flow does
> always end up at "intend".

I hope it the code doesn't look too tacky =) I strive to be the resident
geniuses who can implement a realtime 3D mapping system in 40 lines of code <g
{Quote hidden}

I tried this at the the beginning of the ISR -- no go. It seems the code
doesn't wanna go beyond the first Carry bit test. I'm tempted to scrap the
code but this boggles my mind!

> I don't know which micro you're using but on the F84 the
> Option register can be set for a falling or rising edge. It
> doesn't cater for "level". Perhaps there's a little noise on the
> signal that's causing ISR re-entry. With a cursory glance the
> s/w looks OK, maybe you should have a look at the signal

Yes, I'm using the infamous 'F84. I've tried the Option register bit (no pun
intended) with no luck. FWIW, the pulse is coming from a 555. I scope it and
it appears "clean" as far as I can tell. If I can figure out what in the heck
is causing the PIC to lock up at the first Carry bit test then I believe my
program will work. Maybe I should try the Interrupt on PORTB change
thingamajig.

Much thanks for your help,

Tim Hamel

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


2001\09\13@041416 by Tim Hamel

picon face
In a message dated 9/13/01 12:55:26 AM Pacific Daylight Time,
RemoveMEjoecolquittTakeThisOuTspamCLEAR.NET.NZ writes:


> > Somewhere in the ISR, it "locks up"
>
> Do you mean PC never returns to the main loop ? Have you
> tried the LED test outside the ISR ? It looks as though you're
> getting a 1ppm signal from somewhere and using to increment
> the minute counter. Have you checked that signal ?

Hmm...how do I explain it. The LED test outside the ISR will work. The main
routine will execute, but when the ISR is initiated the PWM routine that's
done in the main part of the code is stopped because the PIC has gotten jamed
in the ISR.  I'm glad you've quoted the code below as it'll allow me to
further illustrate this problem. If I put the "bcf" instruction in either the
hours or day routine, it'll never happen. It's like the PIC is going uphill
and comes to the first (the one below) "btfsc STATUS,C" instrucion and gives
up and crashes.

I've got the 555 sending out a pulse every second or so (it's high for
roughly 5mS) to bit 0 of PortB. Upon this pulse, yes, a "minute" counter
incremented. This signal DOES look clean though rather sloped on the rising
edge (which is why I used the falling-edge detect in the first place).


{Quote hidden}

I could try eliminating these needless instructions and maybe (oh maybe!) it
might do something. I whipped this code up rather fast so haven't really sat
down to do any optimization.

{Quote hidden}

LOL...if I slip and fall on 'em....

-Tim H.

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


2001\09\13@055618 by Jinx

face picon face
> hours or day routine, it'll never happen. It's like the PIC is going
> uphill and comes to the first (the one below) "btfsc STATUS,C"
> instruction and gives up and crashes

Oooh, I know, it can be infuriating. Had my share of morning-
after epiphanies. Why do we do it to ourselves ?

Hmmm. Program flow must be going somewhere. Does the
program compile OK ? How about a disassembly - the "goto
hours" or "goto day" don't send program flow off into outer
space ?

Get ready to kick yourself when you find out. Or if you don't
think you can do that right either perhaps someone local from
the list can swing the boot for you ;-)

> I've got the 555 sending out a pulse every second or so (it's high for
> roughly 5mS) to bit 0 of PortB. Upon this pulse, yes, a "minute" counter
> incremented. This signal DOES look clean though rather sloped on
> the rising edge (which is why I used the falling-edge detect in the
> first place)

What about testing the code with the signal as just an
ordinary input without interrupts -

getpin    btfss portb,0
              goto  getpin

> I could try eliminating these needless instructions and maybe
> (oh maybe!) it might do something. I whipped this code up rather
> fast so haven't really sat down to do any optimization

I usually count down with clocks - just my preference. Start
the register with 60 and use decfsz. If you get fed up with
this "Carry-on" he he maybe try fresh approach with different
code. Depends whether you want to get on with the job and
worry about a post mortem later. Not a learning experience
as perhaps how you'd want it but sometimes you just have
to move on. PortB Change can be fraught with its own dangers,
PortB0 is good for what you're doing

BTW, this had better keep on being The Neverending
Interrupt or I'll sue your ass, like I did those crumbs that
made The Neverending Story when the damn thing ended

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


2001\09\13@075139 by Olin Lathrop

face picon face
> int:
>     movwf   _w
>     incf    min,f   ;Increment minutes

This irreversibly alters STATUS.  This will have the effect of randomly
changing STATUS at random locations in the main code.  You need to save
STATUS before changing it.  This is all well described in the manual - read
it.  I also have an example interrupt service routine in HAL_INTR.ASPIC at
http://www.embedinc.com/pic/hal.htm.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, RemoveMEolinspamTakeThisOuTembedinc.com, http://www.embedinc.com

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


2001\09\13@080647 by Jinx

face picon face
> > int:
> >     movwf   _w
> >     incf    min,f   ;Increment minutes
>
> This irreversibly alters STATUS

Yes, if you care about the contents of W and Status they
should be saved, but it wouldn't explain why the program
seems to choke after the btfsc

   movfw   min
   sublw   .60

btfsc   STATUS,C
   goto    hours
   goto    day

Tim, you should be aware that SUBLW actually performs
Subtract W from Literal, not Subtract Literal from W as
you'd expect (SUBWF is the logical Subtract W from F)

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


2001\09\13@080654 by Heinrich Raman

flavicon
face
Have anyone use the Pic16C745/65 before .I would appreciate it if someone
can give me some info on the PIC or maybe some same code.

{Original Message removed}

2001\09\13@092200 by Bob Barr

picon face
Jinx wrote:
>
> > I've been recently developing an "application" to
> > simulate sunlight (ha!).
>
>Just a moment, I'll bend over. Leastways that where ma reckons
>the sun shines from ;-)
>

Are you sure you didn't misunderstand your pa when he told you to 'stick it
where the sun *don't* shine'? :=)

Regards, Bob


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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


2001\09\13@095728 by Scott Dattalo

face
flavicon
face
On Thu, 13 Sep 2001, Olin Lathrop wrote:

> > int:
> >     movwf   _w
> >     incf    min,f   ;Increment minutes
>
> This irreversibly alters STATUS.  This will have the effect of randomly
> changing STATUS at random locations in the main code.  You need to save
> STATUS before changing it.  This is all well described in the manual - read
> it.  I also have an example interrupt service routine in HAL_INTR.ASPIC at
> http://www.embedinc.com/pic/hal.htm.


This was my first observation too. So to reiterater Olin and Joe (aka
Jinx), you need to preserve status and W upon entry into the ISR.

However, let me suggest a different way to approach this. It may be
convenient to place a chunk of code in an ISR, but often it's not the best
design choice. I can't really say for your particular case whether it's
appropriate or not. (The fact that you mention "PWM" suggests not.) My
inclination would be to put all of the processing outside of the interrupt
and just use the interrupt to record that something has occurred.

If all you're doing is monitoring 1-sec ticks on an I/O line (of PORTB)
then you can do this in the interrupt routine:


     org   4

     bsf   SOME_FLAG,bONE_SECOND_INT   ;record the event

     RETURN                            ;exit with interrupts disabled



and in the main code:


BIG_LOOP:


     ...


     btfss  SOME_FLAG,bONE_SECOND_INT ;Did we capture a one-second event?
      goto  next_task

     bcf    SOME_FLAG,bONE_SECOND_INT ;Maybe, but clear the flag anyways

     movf   PORTB,W                   ;Clear the pending interrupt

     BSF    INTCON,GIE                ;Re-enable the interrupt

     ; code to increment RTC registers...

next_task:
     ...


     goto    BIG_LOOP


Be very carful when writing code like this! There are several subtle
things happening. First, it's assumed that the current register bank is
is in view when the interrupt fires. If you're using the F84 or the F877,
then this isn't an issue. On the F877 make sure you place the variable
"SOME_FLAG" in one of the aliased registers. On the F84, all of the
registers are aliased. On the C64, etc, be very careful...

Another subtlety is that the status and W registers don't need saving
since they're not being modified.

Another subtlety is that the interrupt routine exits with interrupts
disabled! So care is taken in the main loop to disable the pending
interrupt and then re-enable interrupts. But be aware that the main loop
needs to run fast enough to ensure that an interrupt does not get missed.

Another tricky thing to do in the interrupt routine that would get around
this problem:

   org 4

   ;assume that we're looking for a rising edge on portb, pin SEC_EDGE

   btfsc    PORTB,bSEC_EDGE     ;Check i/o pin AND clear pending
                                ;interrupt. This is tricky in that
                                ;the portb interrupt on change is
                                ;cleared by reading portb.
    bsf     flag, bONE_SEC      ;I/O line is high

   RETFIE                       ;re-enable ints upon exit


----

In the past I've needed to determine approximately how fast an RC
oscillator configured PIC was running. If there's another external time
base such as an RTC then you can count TMR0 rollovers between one second
events. If you enable TMR0 interrupts, you can count roll overs like so:

   org  4

   bcf      INTCON,T0IF   ;clear the interrupt

   incfsz   count_lo,f    ;count the times it occurred
    incfsz  count_hi,f
     retfie
   retfie

This code has several tricks. One is that the Z bit in the status register
is not modifed by the incfsz instruction (unlike the incf instruction). So
this can be safely placed in an interrupt routine without having to save
the STATUS register. Second, this trick uses Andy Warren's devious 16-bit
increment mtrick. I won't explain it now until someone makes the false
claim it can't work. As Olin would say, "Search the archives."

Incidently, in one application I need a variable frequency PWM. Rather
than varying the frequency in software, I varied the PIC's oscillation
frequency with an RC oscillator where part of the 'R' was a potentiometer.
The PWM duty cycle remained constant (or actually under software control
- which was desired), but the frequency was variable with a knob (which
was also desired). At the same time it was necessary to perform some
polling at a relatively constant rate. The poll rate was determined by
counting the number of TMR0 roll overs in a second. In a more recent,
application I ran into a different set of circumstances that required the
same solution. Can't say what thouse circumstances are, but this solution
worked for me!

Scott

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


2001\09\13@130030 by Tim Hamel

picon face
In a message dated 9/13/01 2:57:01 AM Pacific Daylight Time,
RemoveMEjoecolquittTakeThisOuTspamspamCLEAR.NET.NZ writes:


> Oooh, I know, it can be infuriating. Had my share of morning-
> after epiphanies. Why do we do it to ourselves ?
>
> Hmmm. Program flow must be going somewhere. Does the
> program compile OK ? How about a disassembly - the "goto
> hours" or "goto day" don't send program flow off into outer
> space ?

I haven't thought of this yet but I'm going to give it a try. Maybe a
disassembly will reveal something that I haven't seen.

>
> Get ready to kick yourself when you find out. Or if you don't
> think you can do that right either perhaps someone local from
> the list can swing the boot for you ;-)
>

I'm so bruised from kicking myself that I now wear football gear! After I
experience this morning epiphany I'll start the slapping of myself...


{Quote hidden}

This might be what I have to do. I'll have to find an elegant solution to
test the pin yet not have the PWM loop stop running for a length of time that
the backend part of the circuit goes out (i.e., light).


{Quote hidden}

I could try decfsz as well. Aww heck, let's scrap the ISR and do it from
scratch!


> BTW, this had better keep on being The Neverending
> Interrupt or I'll sue your ass, like I did those crumbs that
> made The Neverending Story when the damn thing ended
>

So, if I opt to implement the pulse routines in the mainline program, does
this constitute a neverending interrupt? =)

-Tim

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


2001\09\13@130852 by Tim Hamel

picon face
In a message dated 9/13/01 5:07:27 AM Pacific Daylight Time,
RemoveMEjoecolquittKILLspamspamCLEAR.NET.NZ writes:


> Yes, if you care about the contents of W and Status they
> should be saved, but it wouldn't explain why the program
> seems to choke after the btfsc
>

Those were my thoughts exactly.


{Quote hidden}

I remember there being a quirk in one of the subtraction instructions that
wasn't WYSIWYG. My own logic says that I'm loading my minutes counter into W
and subtracing THAT value from .60. Of course, if I go the decfsz route then
I wouldn't have to worry about this.

-Tim

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


2001\09\13@133420 by Tim Hamel

picon face
In a message dated 9/13/01 4:52:28 AM Pacific Daylight Time,
spamBeGoneolin_piclistSTOPspamspamEraseMEEMBEDINC.COM writes:


> This irreversibly alters STATUS.  This will have the effect of randomly
> changing STATUS at random locations in the main code.  You need to save
> STATUS before changing it.  This is all well described in the manual - read
> it.  I also have an example interrupt service routine in HAL_INTR.ASPIC at
> http://www.embedinc.com/pic/hal.htm.
>

Olin,

My reasoning was, I'm not using STATUS in the main part of the code so why
save it? I imagine it's possible that the page bit would somehow be set and
thus my code would try to be working on the wrong page so I added a bcf
instruction to make sure I'm in the right page. But...if you insist...I'll
save STATUS.

-Tim

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


2001\09\13@135659 by Tim Hamel

picon face
In a message dated 9/13/01 6:58:44 AM Pacific Daylight Time,
EraseMEscottspamEraseMEDATTALO.COM writes:


> This was my first observation too. So to reiterater Olin and Joe (aka
> Jinx), you need to preserve status and W upon entry into the ISR.
>
> However, let me suggest a different way to approach this. It may be
> convenient to place a chunk of code in an ISR, but often it's not the best
> design choice. I can't really say for your particular case whether it's
> appropriate or not. (The fact that you mention "PWM" suggests not.) My
> inclination would be to put all of the processing outside of the interrupt
> and just use the interrupt to record that something has occurred.

So far, I've heard great work-arounds/solutions and I do appreciate it. All
of these I'm sure could be implemented w/out a hitch. I only did the bulk of
the processing in the ISR because I wanted the main program to concentrate on
my PWM routine instead of jumping around to different routines checking pins
and possibly having the PWM routine stopping long enough to see a delay (lamp
flicker). "Tim, this will only improve your coding efficiency!" I hear you
say, and most likely, you're right =)

{Quote hidden}

Well, I guess I chose the right chip (16F84).  I do like your approach here
though, it's using the interrupt for its intended purpose w/out the bulk of
the processing inside. I suppose I should start documenting this for future
reference.

On a different note, I have another project I put on the backburner in which
I ran into a similiar problem but without the intense processing in the ISR.
Seems when I initialized the int. vectors (org 4...goto....) the  PIC never
made it to main, even with ints. disabled! That's for another day....=)

>
> Another subtlety is that the status and W registers don't need saving
> since they're not being modified.
>
> Another subtlety is that the interrupt routine exits with interrupts
> disabled! So care is taken in the main loop to disable the pending
> interrupt and then re-enable interrupts. But be aware that the main loop
> needs to run fast enough to ensure that an interrupt does not get missed.


In the final application, the pulses will be coming in at roughly once per
minute so unless my coding is REALLY bad, I should be able to make it out in
time.

{Quote hidden}

So, the end result is to eliminate the bulk of the data processing from the
ISR to minimize the chances of some fool from emailing the PICLIST
complaining that he can't turn off an LED at the end of his ISR...I get it! <g
{Quote hidden}

Devious it is! I kind of wanted this design to be KISS as it's SORT of
intended for the beginner/intermediate crowd. Weird..I keep running those
above instructions through my head and can't figure it out! I would imagine
that this is a 16-bit counter yet timer_hi is (or appears to be) incremented
after the timer_lo is. Weird...

{Quote hidden}

Basically my setup is like so. I'm varying the brightness of an LED which
will eventually be taken place by an optotriac. While your duty cycle was
constant, mine has to change in order to vary the brightness of an
incandescent lamp.

It's a new day and I haven't looked at the code yet, but if I do and discover
I've done something REALLY goofy..boy oh boy...well, I'll donate my marbles
to science...fiction =)

Thank you,

Tim H.

>
> Scott
>

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


2001\09\13@144441 by parkiss

picon face
Tim-

Here's a chunk of your code with revised comments.  When you look
at it this way, it's clear this is not what you mean to do.  I
think it's helpful with sub** instructions to view the Carry bit
as a borrow bit--if it's set, there was no borrow; if it's clear
then there was a borrow out of the high order position.

Hope that helps,

Steve

int:
   movwf   _w
   incf    min,f      ; Increment minutes
   bsf PORTB,2

   movfw   min
   sublw   .60        ; subtract minutes from 60

   btfsc   STATUS,C   ; if 60 >= minutes (no borrow), goto hours
   goto    hours
   goto    day        ; else goto dayNo, but we need to see how many hours have passed.

hours
   clrf    min        ; 60 minutes passed, increment hours
   incf    hour,f
   bcf PORTB,2

day
   movfw   hour
   sublw   .12        ; subtract hours from 12
   btfsc   STATUS,C   ; if 12 >= hours (no borrow), goto check
   goto    check
   btfsc   incdec,0   ; else determine if we increase/decrease brightness
   goto    lights     ; Increase brightness
   goto    dark       ; Decrease brightness

...

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


2001\09\13@150753 by Olin Lathrop

face picon face
>       org   4
>
>       bsf   SOME_FLAG,bONE_SECOND_INT   ;record the event
>
>       RETURN                            ;exit with interrupts disabled

First, you still have to remove the interrupt condition.  Second, if you're
just going to set a flag in the interrupt routine then check that flag in
the foreground code, you might as well check the interrupt condition flag in
the foreground code directly with interrupts off.

Despite these specific points, I agree with the general strategy of doing as
little as possible in the interrupt routine.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, .....olinspam_OUTspamembedinc.com, http://www.embedinc.com

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


2001\09\13@151430 by Tim Hamel

picon face
In a message dated 9/13/01 12:08:42 PM Pacific Daylight Time,
TakeThisOuTolin_piclistKILLspamspamspamEMBEDINC.COM writes:


> First, you still have to remove the interrupt condition.  Second, if you're
> just going to set a flag in the interrupt routine then check that flag in
> the foreground code, you might as well check the interrupt condition flag in
> the foreground code directly with interrupts off.
>
> Despite these specific points, I agree with the general strategy of doing as
> little as possible in the interrupt routine.
>
>

Olin,

I'm starting to agree with the fact that I should do away with interrupts as
they're causing more problems than anything! I took another look at the code
this morning. The interrupt is neverending because the PC never wants to go
to "intend" no matter what! If I add bcf PORTB,2 after a few instructions in
the ISR and scope it, I'll see the expected waveform. However, if I replace
the bcf instruction with just a plain ole "goto intend" (where I've added the
bcf instruction) it'll never happen, what gives?

Regards,

Tim H.

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


2001\09\13@173258 by Jinx

face picon face
> >     movfw   min
> >     sublw   .60
> >
> > btfsc   STATUS,C
> >     goto    hours
> >     goto    day
>
> I remember there being a quirk in one of the subtraction

At face value there's nothing wrong (that I can see anyway)
with using C.

When min=59, W=59, SUBLW .60 , C=1
When min=60, W=60, SUBLW .60 , C=0

W will be altered in both cases but that's irrelephant in your
program. As for the amount of code being executed in the
ISR, it's not really that much, notwithstanding that you have
PWM running too. How quickly do you see the PWM stop ?
After the first EXTINT or after a certain number ?

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


2001\09\13@180754 by Olin Lathrop

face picon face
> My reasoning was, I'm not using STATUS in the main part of the code so why
> save it? I imagine it's possible that the page bit would somehow be set
and
> thus my code would try to be working on the wrong page so I added a bcf
> instruction to make sure I'm in the right page. But...if you insist...I'll
> save STATUS.

Unless you've got an extremely simple forground loop, it will use STATUS.
Personally, I would always write a "clean" interrupt routine that doesn't
trash any state unless it was absolutely imperative not to spend the cycles
or the code space, AND it was clearly documented in all the appropriate
places.  Otherwise, sooner or later you or someone else will make an
innocent little change that causes everything to break just because it
happened to use a condition bit in STATUS or whatever.  A well behaved
interrupt routine is simply good programming practise.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolin@spam@spamspam_OUTembedinc.com, http://www.embedinc.com

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


2001\09\13@182153 by Drew Vassallo

picon face
Just wanted to add that because your ISR "doesn't work" isn't really a good
reason to rewrite your code to eliminate the entire interrupt functionality
altogether.  ISRs are extremely useful and quite simple if treated properly.
 There is no reason that a simple chip like the 16F84 should present
problems with basic ISR usage.  Keep at it.  Reread the datasheets to make
sure you didn't forget to initialize something.

I don't remember the beginning of this thread, but if you post your entire
code to the PICLIST, someone may take a look at it and correct the problem
rather than just working around it.

--Andrew

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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


2001\09\13@183040 by Tim Hamel

picon face
In a message dated Thu, 13 Sep 2001  5:33:50 PM Eastern Daylight Time, Jinx <RemoveMEjoecolquittEraseMEspamspam_OUTCLEAR.NET.NZ> writes:

>
> At face value there's nothing wrong (that I can see anyway)
> with using C.
>
> When min=59, W=59, SUBLW .60 , C=1
> When min=60, W=60, SUBLW .60 , C=0
>
> W will be altered in both cases but that's irrelephant in your
> program. As for the amount of code being executed in the
> ISR, it's not really that much, notwithstanding that you have
> PWM running too. How quickly do you see the PWM stop ?
> After the first EXTINT or after a certain number ?

The PWM stops at the first int., which further confirms that the program is getting stuck in the ISR and never getting out. The main loop is very simple. I have a look-up table that counts by 5's to 100. These represent the % of on-time that the LED will be on. I subtract the on-time from 100 to give me the off-time. Then, I just load these values into W, call my delay loop that will perform the loop for on-value/off-value amount of times. That's really all there is to my PWM routine.

I disassembled the hex file using Dincer's J-script disassembler, all looks well until I get to my lookup table, at the very end, I see this:

ORG 0x2007
   addlw F9    ; d'249' b'11111001' a''

If I'm not mistaken, 0x2007 are ID bits correct?

The person who's "hired" me to do this code wants me to just drop the interrupt stuff and do polling. For me, I can't help wondering what's going on inside the ISR for it to lock up. Btw, if you saw my last message about adding an implicit "goto intend" upon entry into the ISR, that never happens (as I have a bcf instruction in intend).

The age old question, is it hardware or software?

Regards,

Tim Hamel
>
> --
> http://www.piclist.com hint: To leave the PICList
> @spam@piclist-unsubscribe-requestRemoveMEspamEraseMEmitvma.mit.edu

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


2001\09\13@183312 by jamesnewton

face picon face
And he worst part of that is that it can easily happen to only "break" once
every so many minutes, hours, days, etc... Not that I've ever made that
mistake myself <GRIN> but that sort of very intermittent bug is hell to
find.

Ok, ok, I did it... and it ended up looking like a hardware bug and the
hardware guys spent weeks on it before I noticed the problem (software
development was on-going) and corrected it quietly... One of the guys in the
hardware group co-incidentally replaced a component (for like the 3rd
time??) and "that fixed it... wow! 3 bad <whatevers>... who would have
thought?"

I figure it makes up for all the times I've been screwed by hardware people
not feeding me the signal they say they are or building glitchy power
supplies or ....

---
James Newton, Admin #3 @spam@jamesnewtonspam_OUTspam.....piclist.com
1-619-652-0593 VM 1-208-279-8767 FAX
PIC/PICList FAQ: http://www.piclist.com or .org

{Original Message removed}

2001\09\13@191326 by Tim Hamel

picon face
In a message dated 9/13/01 3:22:56 PM Pacific Daylight Time,
spamBeGonesnurpleEraseMEspamHOTMAIL.COM writes:


> I don't remember the beginning of this thread, but if you post your entire
> code to the PICLIST, someone may take a look at it and correct the problem
> rather than just working around it.
>
> --Andrew
>

I only hesitated in posting the entire code because I didn't want to
overwhelm anyone and I didn't want to suck up too much bandwidth with
"useless" parts of code. But, for those who are interested, I've put the code
on my server:

http://24.14.231.164/dawn.asm

Sorry, lost my domain name so we're stuck with IP addy's =)

Much appreciation to those who can "spot the bug!"

Regards,

Tim Hamel

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


2001\09\13@193637 by Jinx

face picon face
> Are you sure you didn't misunderstand your pa when he told
> you to 'stick it where the sun *don't* shine'? :=)
>
> Regards, Bob

Hmmm, wondered what that squirrel was doing round there
with a bag of nuts. Explains why the light suddenly went out ;-)

Tim, have you modified this piece of code for testing purposes ?

light movfw ltlvl
call light1
movlw 1
movwf onval
sublw .100
movwf dklvl

After the CALL, you explicitly load W with 1, even though a
different value may have been in it due to the RETLW

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-request@spam@spamspamBeGonemitvma.mit.edu


2001\09\13@203030 by Tim Hamel

picon face
In a message dated 9/13/01 4:40:20 PM Pacific Daylight Time,
.....joecolquitt@spam@spamEraseMECLEAR.NET.NZ writes:


{Quote hidden}

Yes, I did that purposely as the waveform I was seeing when I first powered
up the chip was 50% duty cycle which seemed odd. I loaded 1 so I would be a
1% duty cycle yet the waveform never changed; I've fixed that, it was a
problem with my delay routine.

-Tim

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


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