16F676 Interupt on Change pin determination


Closed Thread
Results 1 to 18 of 18

Hybrid View

  1. #1
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    OK, so let's look at how the whole process of ON INTERRUPT works.

    When an Interrupt occurs, the hardware turns off the GIE bit, pushes the current address on the stack and then vectors to address 4.

    At address 4, PBP only puts 1 opcode. RETURN

    This pops the hardware generated address from the stack and immediately returns execution to where it was before the interrupt. But leaves the GIE bit turned off, so that no other interrupts can occur until the last one is handled. Because, it can only be Handled, after PBP is done with whatever it was doing at the time.

    Then in-between each and every line of code (that's not DISABLED) it does a CALL to the interrupt "Checker" which simply checks to see if GIE is a 0 or not. If it is 0, it means an interrupt occurred and it does the GOTO that you see in the ONINT?LL macro;

    It's that CALL to the checker that puts the address on the stack, so that it can return back to the point in-between lines that it jumped from.

    So again, if a return never happens, the stack builds up.

    An interesting side note is that many people think you can turn OFF all interrupts by clearing the GIE bit (myself included previously). But what that really does with ON INTERRUPT is to make PBP think that an interrupt has happened, it calls the handler (which shouldn't do anything since no Flags are set) and then turns GIE back on again. In order to turn off interrupts globally, that section of code must be DISABLED.

    Can't figure how any other code I've written with ON INTERRUPT continues to work.
    It all boils down to the one statement in the manual that seems so innocuous.
    All previous return addresses will be lost in this case.

    As long as you never want to go back to the sections of code that got interrupted, then the stack simply wraps around, and only NEW gosubs past that point will be returned to. That's not something that any of my programs would be able to tolerate.

    On that little sample above - I don't think the DISABLE / ENABLE are needed, as the interrupt handler comes before the ON INTERRUPT statement (at least that's what the manual says).
    Yup, you're right, anything before the ON INTERRUPT statement is considered DISABLED. My Bad.

    HTH,
      Darrel

  2. #2
    Join Date
    May 2004
    Location
    New England
    Posts
    164


    Did you find this post helpful? Yes | No

    Default

    Hi Darrel,
    Thanks for explaining further - I think the idea has finally got through my thick skull.

    It all boils down to the one statement in the manual that seems so innocuous.
    All previous return addresses will be lost in this case.

    As long as you never want to go back to the sections of code that got interrupted, then the stack simply wraps around, and only NEW gosubs past that point will be returned to. That's not something that any of my programs would be able to tolerate.
    This must be why my programs keep working - once interrupted, everything the progam was doing is dropped, and the code never has to return back to before the interrupt, so the stray return addresses piling up on the stack just get overwritten when there are new GOSUBs or CALLs.

    I'll have to keep this issue in mind if my code ever gets more complex! The PBP manual really should mention something about the potential stack problems with RESUME(label).

    Thanks again,
    Arch

Similar Threads

  1. Is this a K Type sensor?
    By jessey in forum mel PIC BASIC Pro
    Replies: 20
    Last Post: - 21st November 2009, 14:55
  2. HELP !!! How change the voltage of a pin ????
    By stormdacta in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 21st August 2007, 21:55
  3. Microcontroller with 2 way paging application problem
    By oneohthree in forum mel PIC BASIC Pro
    Replies: 30
    Last Post: - 20th April 2007, 18:27
  4. Another RTC, DS1287
    By DavidK in forum Code Examples
    Replies: 0
    Last Post: - 12th December 2006, 18:07
  5. 16F676 Interupt
    By BGreen in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 5th March 2006, 21:56

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts