Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Interrupt handling

  1. Interrupt handling

    I am trying to get rid of a little but in my wheel encoder code dealing with interrupts.

    I have an int that keeps track of the number of encoder bars that have passed that is updated by an interrupt.

    Then I have a function that does stuff with that int. A problem arises when, at the exact instant I am doing stuff with that int the interrupt occurs.

    So I was planning on doing something like

    Code:
    foo()
        disable encoder interrupt
        doStuff()
        enable encoder interrupt
    but then if the interrupt occurs while the interrupt is disabled, it will simply get ignored right? Is there a way to still catch the interrupt but simply delay processing it till after doStuff() is done?

  2. #2
    Join Date
    May 2008
    Posts
    2,228
    Images
    155
    Rep Power
    124

    Re: Interrupt handling

    I would do the following:

    foo(){
    disable_interrupt;
    x = counter_value;
    enable_interrupt;
    do stuff with x.....

    }

    Then you really have the interrupt disabled for what, 3-5 clock cycles? That's almost nothing.. If foo() is called at a regular interval, and the counting values are fairly high every time foo is called, then its pretty much insignificant if you miss a pulse.

    Quote Originally Posted by Resilient View Post
    Is there a way to still catch the interrupt but simply delay processing it till after doStuff() is done?
    <EDIT: SEE BELOW>

    -Fergs
    Last edited by lnxfergy; 05-24-2009 at 09:41 AM.

  3. Re: Interrupt handling

    Thanks for the information. Its kind of what I had guessed. I was just sort of curious if there were a better way from a theoretical standpoint.

    And yeah, it's AVR.

    Thanks!

  4. #4
    Join Date
    Apr 2008
    Location
    Sacramento, CA, USA Area
    Posts
    5,341
    Rep Power
    173

    Re: Interrupt handling

    Not all AVR are created equal. Some have many more hardware interrupts than others, allowing for a more functionally parallel execution path.
    I Void Warranties´┐Ż

  5. #5
    Join Date
    May 2008
    Posts
    2,228
    Images
    155
    Rep Power
    124

    Re: Interrupt handling

    Quote Originally Posted by Adrenalynn View Post
    Not all AVR are created equal. Some have many more hardware interrupts than others, allowing for a more functionally parallel execution path.
    Regardless of how many interrupts are possible on the chip... I believe that all 8-bit AVR architectures disable GIMSK when they jump into an ISR, and reenable it on the way out of the ISR.

    And now as I think about it more, I realize I mispoke above... During the execution of an ISR, if another condition occurs that would normally trigger an interrupt, the flag will still be set, however because GIMSK is disabled, the interrupt will not occur then. That means as you exit the ISR, and GIMSK is re-enabled, the interrupt will occur. HOWEVER -- if the interrupt should have been triggered twice or more, it will only occur once, at the end of the other ISR... so you may still miss some counts.

    Also, as an ISR exits, it clears the flag for the interrupt it just executed, so if you have an interrupt counting pulses, and it takes too long, it won't see a second pulse during execution of the ISR (since although the flag will be set again, it will be cleared on exit from the ISR).

    -Fergs

  6. #6
    Join Date
    Jul 2008
    Location
    Belgium
    Posts
    633
    Images
    2
    Rep Power
    59

    Re: Interrupt handling

    I don't know how the interrupt handling of an AVR works specifically, but with PIC and 8052 cores I do know that an instruction in-progress will be completed before jumping to the ISR, if the interrupt happened right after the instruction was fetched.

    Personally I always use - as Fergs suggests above - a 'shadow variable' that is loaded once with the value of the register that's changed by the ISR (eg. X = counter_value as per Fergs). Since that instruction will still be executed, you'll know it can be used for anything else.
    It gets tricky if you're using a core without a single-instruction move though. But then, given a correct ISR save/restore, that shouldn't be an issue.

    In most cases though there's a slight hardware latency for a given interrupt so the core might actually process another two or three instructions if you're running the thing fast enough.
    Artificial Intelligence is no match for Natural Stupidity

    "For a list of all the ways technology has failed to improve life, press three" - Alice Kahn

    Resistance is futile! (if < 1)

  7. Re: Interrupt handling

    I was reading through the mega640 data sheet and it looks like there are two kinds of interrupts, some that throw a flag and others that dont.

    I am a little confused as to which is which. It sounds to me like if it is set up to be edge triggered, then it will set a flag when it detects an edge even if it is disabled. Whereas if it is level triggered, then it will only throw an interrupt if it is enabled and the level is held low for at least 5 clock cycles.

    So it sounds like what I want is an edge triggered interrupt so that I can disable it, read the value, enable it and then it can handle the interrupt if the flag was set while reading the value. Can anyone confirm or deny this?

    I read it here: http://www.atmel.com/dyn/resources/p...ts/doc2549.pdf

    Pages: top of 18 and 112

  8. #8

    Re: Interrupt handling

    What if you were to add a chip to take care of encoder counts on its own, and read from when needed ?
    http://usdigital.com/products/interfaces/ics/lfls7166/
    http://usdigital.com/products/interf...cs/lfls7266r1/

  9. #9
    Join Date
    Jul 2008
    Location
    Belgium
    Posts
    633
    Images
    2
    Rep Power
    59

    Re: Interrupt handling

    What I think is usually completely different from what I post, especially when not in my native tongue, but with my previous post I kinda sorta left out the part 'meaning you do not need to disable the interrupt if you use a shadow variable, if the instruction 'move regA to regB' is a single-clock instruction.
    However I'm by no means an AVR expert so can anyone back this up?

    Robologist's solution is a very fine one indeed though!
    Artificial Intelligence is no match for Natural Stupidity

    "For a list of all the ways technology has failed to improve life, press three" - Alice Kahn

    Resistance is futile! (if < 1)

  10. #10
    Join Date
    May 2008
    Posts
    2,228
    Images
    155
    Rep Power
    124

    Re: Interrupt handling

    Quote Originally Posted by ScuD View Post
    What I think is usually completely different from what I post, especially when not in my native tongue, but with my previous post I kinda sorta left out the part 'meaning you do not need to disable the interrupt if you use a shadow variable, if the instruction 'move regA to regB' is a single-clock instruction.
    However I'm by no means an AVR expert so can anyone back this up?
    The issue here is that on the AVR architecture (8-bit), an integer in AVR-GCC defaults to 16-bits... there are only 3 "virtual 16-bit" registers (X,Y,Z), which are typically used for memory addressing. Those are the only registers where you could put a 16-bit value and read in 1 clock cycle. I'm not entirely sure of the internals of AVR-GCC, but I really don't think it can optimize code in this way, and I would think it would be tough to write an assembly program that does such, since X,Y,Z are fairly well used for their specia 16-bit properties already.

    Regardless, if he is reading a 16-bit timer count register, there is no instruction that can read both the H & L bytes in a single instruction. So you really do want to stop ints, copy, and re-enable interrupts.

    -Fergs

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. How to deal with unexpected stops.
    By Resilient in forum Software and Programming
    Replies: 2
    Last Post: 04-01-2009, 08:27 AM
  2. Question(s) Encoder Board / Microcontroller
    By metaform3d in forum Arbotix, Microcontrollers, Arduino
    Replies: 7
    Last Post: 08-26-2008, 06:18 PM

Posting Permissions

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