Pinchange interupts

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

This is probably going to turn out to be a realy stupid oversight on my part

when using multiple Pins to trigger a pin change interrupt how do i detect which pin(s) actualy triggered it?

 

I am pretty sure this is a generic question that relates to all AVR's but just in case my trarget is a tiny 2313A

This topic has a solution.

Last Edited: Tue. Oct 29, 2019 - 02:54 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Keep a copy of the PIN state from last time - EOR (^) with new state - bits that changed stand out.

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

So there is no register that atuomaticaly stores this state,shame. I thought that was going to be the answer.

many thanks

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

Something like:

ISR(PIN_vect) {
  static uint8_t last = 0x00;
  uint8_t current = PINx;
  uint8_t change = last ^ current;
  last = current;
  // act on 'change'
}

the "register" here is the static that maintains state from one ISR to the next.

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

Well, that does assume the pin signal is still sitting there by the time the IRQ tries reading it...what if it is just a 150ns pulse?  The IRQ will fire, but the pin signal maybe gone by the time it is read.

If there are only 2-3 pinchange irqs needed, they can be split into separated banks using PCMSK0, PCMSK1, PCMSK2 bank..then  if PC2 bank fires it can only be that one IRQ.

 

 

 

 

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

But each vector is 8 pins? I think yer man's question is how to know which one of 8.

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

IPguru wrote:
I am pretty sure this is a generic question that relates to all AVR's but just in case my trarget is a tiny 2313A

This is one of the new xTiny mcus right?  If that is the case reading PORTx.INTFLAGS or VPORTx.INTFLAGS will tell you which bit(s) caused the interrupt.

 

Upon further investigation it turns out that the 2313A is not an xTiny (not sure why I thought it was).  Sorry for the noise.

Letting the smoke out since 1978

 

 

 

 

Last Edited: Tue. Oct 29, 2019 - 11:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But each vector is 8 pins? I think yer man's question is how to know which one of 8.

He didn't mention 8....I don't think there is a way to know ...no memory is kept of the specific pin triggering (is that true?).  If you can separate IRQ's so only 1 on each PCMSK0, PCMSK1, PCMSK2, then you can tell which of the 3 IRQ's  were triggered.   Is 3 enough?

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

avrcandies wrote:
.no memory is kept of the specific pin triggering (is that true?)
My point entirely - it's up to YOU to hold "last state" so that when one of the 8 changes state you can determine which of the 8 possible sources caused the interrupt to happen.
avrcandies wrote:
If you can separate IRQ's so only 1 on each PCMSK0, PCMSK1, PCMSK2,
But in something like a 328 that would mean you could only have one pin on PORTB (PCMKS0), one pin on PORTC (PCMSK1) and one pin on PORTD (PCMSK2) active. The point is that B has 8 possible sources, C has 7 and D has 8. So you throw away a lot of potential functionality if you are going to limit yourself to one interrupt active pin per port. If you want to use all 7 or 8 pin changes per port you have to put some logic into your ISR to identify which of 7/8 it is each time.

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

If you want to use all 7 or 8 pin changes per port you have to put some logic into your ISR to identify which of 7/8 it is each time

Tis true, if you want a lot of IRQ pins, your are "stuck" in a hard place.  Note that you can still use each port fully & only enable one (or more) pins on each port to give PC IRQ....separating into 3 ports, give a max of 3 unique (identifiable) PC IRQ's.  If limited to 3, the issue evaporates in a cloud of AVR marketing haze.

Capturing & comparing to the previous pin state is "OK", provided the IRQ is not something like a fast pulse...by the time the IRQ responds the pulse is long gone, so there is nothing to compare with or detect what happened.  For "slow" things it is much much better, but you do need to be somewhat concerned with latency (at least check out any potential holdup issues)...how soon is the pin determination taking place relative to the IRQ trigger event?  ---Or perhaps I'm not seeing the obvious? 

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

As I marked this thread as solved I am supprised to see it still going but a number of good points are being raised, such as the status of the pin changing before it can be stored.

 

fortunately for me I was adding a quadrature decode inputs to a simple I2C motor driver board of my own making. i need to monitor 4 pins (2 quadrature inputs) but at relativley slow speeds arround 4KHz so storing the status is not an issue.

I have found that these interrupts can cause the I2c to fail occasionaly, again fortunately my main code loop does almost nothing nothing so migrating it to  the main loop & polling directly seems to work just as well if not slightly better.

 

 

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

As I marked this thread as solved I am supprised to see it still going but a number of good points are being raised, such as the status of the pin changing before it can be stored.

 

fortunately for me I was adding a quadrature decode inputs to a simple I2C motor driver board of my own making. i need to monitor 4 pins (2 quadrature inputs) but at relativley slow speeds arround 4KHz so storing the status is not an issue.

I have found that these interrupts can cause the I2c to fail occasionaly, again fortunately my main code loop does almost nothing nothing so migrating it to  the main loop & polling directly seems to work just as well if not slightly better.

 

 

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

IPguru wrote:
i need to monitor 4 pins (2 quadrature inputs) but at relativley slow speeds arround 4KHz so storing the status is not an issue.

Is that one encoder, or two?

 

Do you really need x4 quadrature (both signals, both edges) or will x2 do (one signal both edges)?

 

Remember that pin-change is not the only horse in the barn.  While the choice of AVR model (hmmm--what can you do with that model and two motors and I2C?) [does that model even have a TWI peripheral?] is limiting, there are many ways on an AVR8 to get external interrupts.  The obvious is external interrupt pins, of with you have two, with edge choice.  Then there are three banks of pin-change interrupts, so there is no decoding if you only use one per bank.  Now you are up to five.  There are additional edge-selectable external interrupt sources -- analog comparator (either or both edges!), T0/T1 pin (external timer clocking; only one edge at a time IIRC) and ICP1 (ditto).

 

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

Just point out that Xmegas actually have quadrature encoder peripherals. If they do there's a chance some of these new AVR-0/AVR-1 toys may have too.

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

clawson wrote:
Xmegas actually have quadrature encoder peripherals.
clawson wrote:
some of these new AVR-0/AVR-1 toys may have too.
theusch wrote:
While the choice of AVR model ... is limiting,

Indeed it is important what this app really "looks like".  If encoder is the primary factor, then indeed a high point of discussion might be model selection.  That said, 16-bit encoder position can be maintained at modest AVR clock rates to tens of thousands of edges per second.  Of course, latency must be kept to a reasonable value.  But hey -- 4K is 250us.  External interrupt vectors are fairly high on the AVR8 chain, so you'd actually have to try hard to hold off edge servicing for that long.  There is a hint from OP that indeed he is trying quite hard:

IPguru wrote:
I have found that these interrupts can cause the I2c to fail occasionaly, again fortunately my main code loop does almost nothing ...

So I'd guess that another ISR is sitting on the dock of the bay, wasting time.

Sittin' in the mornin' sun
I'll be sittin' when the evenin' comes
Watchin' the ships roll in
Then I watch 'em roll away again

 

I'm sittin' on the dock of the bay
Watchin' the tide, roll away
I'm sittin' on the dock of the bay
Wastin' time

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

asnweres to some of the questions:-

I am reading 2 quadrature decoders

I think i need bot signals & both edges as I need to be able to decoded direction as well as absolute movement

This functionality is being added to an existing motor controller board for a hobbyist project so I would prefer not to change micro if possible (although it is also not set in stone as it is only for myself)

Tiny2313a has USI not TWI (although my experiments with TWI on a mega 328 suggest that the processing time in the data read interrupt is similar).

as to speed it seems that if I was processing a clock edge & the wrong moment the raspberry pi reading the I2c would report an error, I am reasonably convinced this is due to the poor i2c implementation on the raspberry

interestingly slowing the raspberries I2C rate from 400khz to 200kh seems to ease the problem.

 

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

Show your circuit

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

IPguru wrote:
I think i need bot signals & both edges as I need to be able to decoded direction as well as absolute movement

You can get direction and speed/position with x1, x2, or x4.

 

While it is often desired to get the best resolution, it depends on the needs of your app. For you, pin selection may be the overriding factor.

 

https://www.motioncontroltips.co...

 

 

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

Jack Ganssle's Embedded Muse is doing some features on encoders at the moment ...

 

http://www.ganssle.com/tem/tem384.html#article4

 

http://www.ganssle.com/tem/tem385.html#article2

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...