How many interrupts is too many interrupts?

[ay2b]

I've had a robot with 6 encoders working fine (we later changed the design and used fewer in the final design). The main thing is to count the number of interrupts per second. Typically the limit is about 4000-5000 interrupts per second. This, of course, depends on how much you do in each interrupt service routine. Don't forget to also count interrupts for each character printed, and for any timers.

A robot with 6 inch wheels, running at 12 ft/s and 256-count encoders in a 1:1 ratio with the wheel will generate about 2000 interrupts per second per encoder. Three of those is probably too much. The easiest solution would probably be to use a lower-count encoder, or to use an encoder divider like the one from Bane Bots

[Qbranch]

Ok, this is not exactly in the case of a robot, but it shows how far/fast an 18F8722 processor can go.

At work, we made a crab drive AGV to load parts into various production machines automatically. We used stepper motors to drive the robot due to their inability to run away and ability to be controlled with swiss-watch precision. While running, the 18f output two completely seperate motor command pulse trains to two motors.

The ISR for each side included a table lookup (acceleration table) and some bit shifting, but made great use of the CCP registers (you won't believe how much more you can do with those things once the chip isn't hindered by IFI's hardware configuration of it in the robot controller).

Anyhow, both of these ISRs run up to 12,500steps/second (that's 25KHz interrupt together) and keeps the robot in communication with the plant coordination computer (there are multiple AGVs) over Zigbee at the same time. Oh yeah and the Local_Keypad_Service() loop (which runs on 26.2ms (yes I did that for old time's sake)) which just watches for the overflow flag on the freerun timer feeding the CCPs runs at the same time. Beleive me... any glitches would be instantly noticed with these stepper motors... running at these high speeds they stall if you have the tiniest hiccup in your pulse timing.

As long as you're smart about your code... you can make these things fly.

By the way, does the third thing you're encoding go around infinitely many times or is it limited? You can get multi-turn potentiometers.

-q

p.s. If you have huge problems with high frequencies on your encoder interrupts, you can always get a microchip development board for one of their new 16-bit or 32-bit core processors which have built in programmable quadrature decoder modules that run up to several MHz/channel... and you don't have to do a thing with them until you want a number. I believe they are DMA-compatible modules, so you can make the register (essentially) as big as you like.

[dcbrown]

At 20,000 interrupts per second, you would need a interrupt code path length of 500 instruction cycles or less (processor is capable of 10,000,000 instruction cycles/second). In almost all cases with the robot, the interrupt code path should be well under 500 cycles leaving upwards of half of the cycles for non-interrupt code.

Typically in MPLAB/IFI default code the interrupt code paths I've measured are <250 cycles total as long as context save/restore is managed well and closer to 500 for WPILib based projects - mostly due to the larger context save/restores needed for accepting anyone's service routine. Probably the longest code path I've seen is in adc interrupt handlers becuase of array indexing and averaging which isn't needed for most other device interrupt routines, but still the average is <300 instructions (~110 cyles per sample and a max of about 1800 cycles for processing 16 channels at sample set boundaries for an average around 215-220 cycles).

Which means, with tuning you'd be easily able to process in excess of 40,000 interrupts per second before you'd start max'ing out the processor.

The down side is, as the process runs more and more at interrupt level there is less and less time at user level and you can get the red light of death because the user code isn't exchanging data in a timely manner with the master processor. You can get around this issue by doing the Getdata/Putdata at interrupt level tied to the system clock for example.

[wireties]

There are many things to consider when asking how many interrupts is too many. It takes some time for the processor to get into and out of interrupt context. The PIC is pretty fast, 5us or so I think. Then when you get into interrupt context, it takes some time to save the registers and restore them. This maybe adds another 5us, probably less. So if it takes 10us per interrupt and you generate 100,000 per second you are hosed. One assumes we want to do something in the ISR, lets say that you do 40us of work in the ISR. Now you have 50us total per interrupt so if you generate 20,000 per second you are hosed.

So consider how much time you spend in interrupt context and how many interrupts are generated per unit time. Then you have other considerations. How much of the total bandwidth can you spare? You can't miss the deadlines sending messages back to the OI so add up the amount of time you spend in your slow routine plus the fast routine plus the max amount of time in ISRs during any 23ms period. If the WORST CASE numbers add up to more than 23ms, you have to change something. Make sense?

We have no troubles with encoders generating 4,000 interrupts per second and the serial port another 1200 or so per second. The only really complicated stuff going on in our normal code are a couple integer PID calculations.

HTH

[marccenter]

Quick question for this thread, does a single quadrature encoder count as one irq or 2 irq's ? My quick calculations show that a wheel speed of 8 feet/sec with a 256 pulse/rev encoder yields about 1000 interrupts per second or is it really 2000 interrupts per second because the encoder has two channels? The addition of a second encoder can now push the processor to 2000/4000 interrupts per second. So, if 2 irq's per encoder, the processor will be operating nearly 4000 interrupts per second?

[dcbrown]

Quad encoders represent 1 interrupt, the phase b line is polled during the interrupt caused by a phase a transition. The phase b is used to determine direction but shouldn't be tied to another interrupt line.

[Kevin Watson]

Originally Posted by dcbrown

Quad encoders represent 1 interrupt, the phase b line is polled during the interrupt caused by a phase a transition. The phase b is used to determine direction but shouldn't be tied to another interrupt line.

This is the case with interrupts 1 and 2, but 3 through 6 generate two interrupts per quadrature cycle.

-Kevin

[dcbrown]

Originally Posted by Kevin Watson

This is the case with interrupts 1 and 2, but 3 through 6 generate two interrupts per quadrature cycle.

-Kevin

True. I forgot that PORTB<4:7> aren't edge triggered, just change triggered.

This thread is rapidly disappearing into the tech rat-hole that the original posted requested it not. So backing up a couple levels. I've run IFI default code with ~8500 interrupts/sec without any issue. The code should be able to handle upwards of 20,000 interrupts/sec based upon the typical interrupt handlers I've seen. But...

There are tech gotchas that start coming into play above 10,000 interrupts per second with the standard IFI robot code framework. But those are best left for another thread. Maybe we should start a separate tech thread on the subject.

[ay2b]

Originally Posted by marccenter

Quick question for this thread, does a single quadrature encoder count as one irq or 2 irq's?

It can be implemented either way. Personally, I usually put an interrupt on only one channel and use that to count steps, and look at the other channel to determine the direction.

Originally Posted by marccenter

My quick calculations show that a wheel speed of 8 feet/sec with a 256 pulse/rev encoder yields about 1000 interrupts per second or is it really 2000 interrupts per second because the encoder has two channels?

Assuming 18 inch circumference wheels:

8 ft/sec = 96 in/sec
96 in/sec at 18 in/rev = 5.333 rev/sec
256 pulses/rev at 5.333 rev/sec = 1365 pulses/sec

At 12 ft/sec, this becomes 2048 pulses/sec.

If you have an ISR for each channel, then double the above numbers.

[Mark McLeod]

The number of interrupts you want to generate is dependent on the accuracy you design for. Any quadrature encoder you choose can be quadrupled in accuracy by discriminating programming.

An encoder rated to return 128 counts per revolution (cpr) assumes the use of an interrupt only on “output A,” and triggering an interrupt only on one edge, rising or falling, of output A, e.g., Digital Inputs 1 & 2.

You can double the effective resolution (a 128cpr encoder will give 256cpr) by alternating the interrupt trigger within the ISR to tick on both the rising and the falling edges of output A, a la Digital Inputs 3-6.

Further, you can quadruple your effective resolution (a 128cpr encoder will produce 512cpr) by also interrupting on “Output B” and triggering on both rising and falling edges.

BTW: Never use the combination of interrupting on both A & B, but only on one edge (rising or falling), since "ticks" would then vary in distance rather than be of constant length.

Originally Posted by marccenter

Quick question for this thread, does a single quadrature encoder count as one irq or 2 irq's ? My quick calculations show that a wheel speed of 8 feet/sec with a 256 pulse/rev encoder yields about 1000 interrupts per second or is it really 2000 interrupts per second because the encoder has two channels? The addition of a second encoder can now push the processor to 2000/4000 interrupts per second. So, if 2 irq's per encoder, the processor will be operating nearly 4000 interrupts per second?