pin change IRQ --what is considered a change?

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I use the pin change interrupt (mega88) & am responding to a pin change interrupt (this is working so far), obviously no nested interrupts will occur (unless I enable interrupts in an interrupt--BAD BAD). However, if the SAME pin changes state while I'm busy processing the first PC interrupt, will another PC interrupt fire at the return from the first interrupt? That is, does the PC interrupt capture changes on a given pin whilst it is being handled? I really need to detect/remember changes such as these so I don't "miss" any edges. I suppose I could simply poll after the interrupt is complete, but there might be a long poll delay compared with the IRQ quick response.

The data sheet is not clear on what/when a "change" is detected (or more exactly, when a change is NOT noticed).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the pin change is latched. this latch is reset when the isr is actioned, therefore one would expect if you're in the pin change isr and another occurs, it will be latched - you can read the state of the pin change flag and reset it via code rather than exit the isr and re-enter.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not just try it?

You should find that a pin-change while you are in the ISR() will give you a pending IRQ.

I am not sure whether a double pin-change would give you a pending IRQ.

Most pin-change ISR()'s will read the relevant sfr as the very first instruction (after pushes). Which services the IRQ.

So you are only talking about a very small window to miss a double pin-change.

You should be able to devise a suitable test program with one, two, three pin-changes when you are deliberately creating a 'window'.

In practice you should be just fine if the changes are more than one or two microseconds apart.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman stated

Quote:
this latch is reset when the isr is actioned

To try and pin that down precisely to machine cycles it would be nice to determine "when" that occurs. I have always assumed that the I flag is cleared AND the PC is loaded with the reset vector AND the flag causing the interrupt cleared simultaneously in the same machine cycle.
Kartman's explanation logically follows on from that.

You could perhaps prove this by generating some fast pulses
with a controller running at say 20 Mhz. interrupting a controller at 1 Mhz. and see what you interrupts you miss & get. I look forward to seeing your results.

Edit.
Looks like we were simultaneous David.

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One would consider the flag a RS flip flip - the change setting the f/f and the interrupt acknowlege resetting it or the write action to the flag register. With a Z80 we had an interrupt ack cycle that would be used to reset such a thing but as to what happens internally in the AVR, we can only guess - my guess is when the vector is fetched.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

if you're in the pin change isr and another occurs, it will be latched

The datasheet says
Quote:
the Program Counter is vectored to the actual Interrupt Vector in order to execute the interrupt handling routine, and hardware clears the corresponding Interrupt Flag.

so if the minimum event is 1 clock cycle wide (I cannot find that either offhand, but I'd expect 1+ clocks) then I guess there might be a small window: hit, reverse, hit in 3 or 4 or 5 AVR clock cycles.

One could argue whether an AVR is the right vehicle to explore sub-microsecond pulse trains with ISRs. To address the original question, "normal" pin changes that don't have insanely short periods don't get lost. Now, some of that is up to you and your app: >>You<< have to have an ISR skinny enough that two additional events don't occur while you are processing the first. This also involves watching your interrupt latency: other ISRs have to be skinny, too.

I see the question area; I'm pretty sure the answer is "a few AVR clock cycles". In practical terms, however, it boils dow to a situation similar to quadrature decoding: latency has to be kept down so that no edges are missed at max rate.

lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think that you all are reading in too much in the OPs question. I believe that he is simply asking "If another edge happens while the ISR is running, will the interrupt flag be set?". The answer to that is yes. The only times you will miss an edge is A) if a second edge happens before the ISR is run B) more than one edge happens while in the ISR.

Besides, I don't see how any of your arguments on when or what order things happen has any relevance. If a second trigger event happens before the interrupt flag is cleared, it will be missed. If it happens after, it will not.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the replies...however...

I do not care about missing multiple edges, just need to track the "LAST" edge, even if I am still responding to an earlier edge. edges should be no closer than a few microseconds, worst case. My irq is a few ms.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then in the ISR, keep track of what that "LAST" edge is and clear the interrupt flag before leaving the ISR.

Quote:
My irq is a few ms.
Then it is too long.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Again, I just want to always respond to the last/latest edge (it will always be at least a few microseconds separated from prior edges). My interrupt requires about 10 ms to do its thing. Any responses to edges prior to the latest can be ignored or results tossed, since they no longer matter once a new edge comes in. It is important to always follow the latest on/off control edge, since edges may stop coming in at any time.

I do want to respond as fast as possible to edges, so I do need an interrupt. The main loop is much too long to poll.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

My interrupt requires about 10 ms to do its thing.

Why can't it just set a flag to say that the code has to "do its thing" then RETI (which re-enables I to allow watching for further edges). The in the mainline code, when it gets a chance, the state of that flag is inspected and, if set, it "does its thing" then resets the flag.

(though there is an issue there where another interrupt DOES occur before the 10ms is up, it sets the flag but the mainline then resets it - so maybe have the mainline reset the flag as soon as its determined it is set)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(though there is an issue there where another interrupt DOES occur before the 10ms is up, it sets the flag but the mainline then resets it - so maybe have the mainline reset the flag as soon as its determined it is set)

There is a quick-and-dirty that I have found useful in these situations. Suppose I have a "fast tick" timer like +/- 1ms; a timekeeping tick e.g. Or maybe a fairly frequent event as discussed here--say a revolution pulse from a motor/fan.

It isn't imperative the the event be processed "right now", but the occurrence should not be lost.

So the detecting ISR simply increments a count variable, and the mainline decrements when processed. (Watch for atomicity.)

How can this happen in practice? Easily, even in a well-written app. Consider what happens when the mainline needs to e.g. write a 16-bit variable to EEPROM. A few ms will go by before the mainline is free to get back to work.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Again, I just want to always respond to the last/latest edge (it will always be at least a few microseconds separated from prior edges).
Then what is the problem? If there is an edge that happens during the ISR, then at the end of the ISR the interrupt flag will be set. Just leave it alone and the ISR will fire again.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Then what is the problem? If there is an edge that happens during the ISR, then at the end of the ISR the interrupt flag will be set. Just leave it alone and the ISR will fire again.

Well, this is the crux of my question...will it catch another edge & make it pending while it is busy processing the original IRQ? So far the opinions seem to lean this way.

If there is only a single edge, then I want the IRQ to start dealing with it in a few microseconds...that's why doing it from main won't do.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If there is only a single edge, then I want the IRQ to start dealing with it in a few microseconds...that's why doing it from main won't do.

Well it does depend what the activity is that you are trying to achieve(which I don't think you have said). For example if each time an interrupt occurs it is supposed to say cause a stepper motor to advanced by a certain number of degrees, you could simply increment a counter in the ISR and then let main worry about turning that into a stepping activity/activities which could take some time.
In any case, keep the ISR short & fast!

I think we have come to the conclusion that the interrupts will easily capture "contact bounce" :)

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
will it catch another edge & make it pending while it is busy processing the original IRQ?
Yes.
Quote:
So far the opinions seem to lean this way.
This is not an opinion, it is how interrupts work.
Quote:
If there is only a single edge, then I want the IRQ to start dealing with it in a few microseconds...that's why doing it from main won't do.
But with a long ISR, if there is a second edge a few microseconds after the first, then it will be milliseconds before that one is handled.

Regards,
Steve A.

The Board helps those that help themselves.