next topic »

[on:]

Greetings. 1st post.

I've got two interrupts running: an external and a timer, both set up using <avr/interrupt.h> register writes since I'm used to that level of control and know I will need it as this gadget evolves.
No problems there.
The timer interrupt is slow (1s) to service a temperature control loop, and the external is a once-around pulse on a slow running motor (~3.5Hz).
I need to turn off the temperature control loop from time to time to act on some motor events.
And I'll ultimately need to turn of the external motor interrupt when I add a faster timer interrupt (say 125us) to sample some data.
There must be a slick way to turn interrupts on and off individually with minimal avr register writes. Or something.
Any good ideas?

Many thanks!

[Reply #1 on:]

Yes you simply disable them.
This is normally done by setting / clearing a flag in the appropriate register for the device generating the interrupt. See the data sheet of the processor for the name of the memory location and the bit to use.

[Reply #2 on:]

The timer interrupt is slow (1s) to service a temperature control loop, and the external is a once-around pulse on a slow running motor (~3.5Hz).
I need to turn off the temperature control loop from time to time to act on some motor events.
And I'll ultimately need to turn of the external motor interrupt when I add a faster timer interrupt (say 125us) to sample some data.

That makes zero sense.

There must be a slick way to turn interrupts on and off individually with minimal avr register writes. Or something.

Yes, there is - all outlined in the datasheet.

[Reply #3 on:]

Check out the link in my signature, I have a class that works on global interrupts for atomic blocking. The 'Atomic_Force' mode emits only 2 instructions for interrupts off/on, you'd be up for a challenge writing code faster than it.

It has a 'Protect' function so you can make variable reads/writes, and function calls all protected from interrupts.

[Reply #4 on:]

Yes, there is - all outlined in the datasheet.

It would be less typing to actually give the answer:

Code:

noInterrupts ();

[Reply #5 on:]

The timer interrupt is slow (1s) to service a temperature control loop, and the external is a once-around pulse on a slow running motor (~3.5Hz).
I need to turn off the temperature control loop from time to time to act on some motor events.
And I'll ultimately need to turn of the external motor interrupt when I add a faster timer interrupt (say 125us) to sample some data.

That makes zero sense.

There must be a slick way to turn interrupts on and off individually with minimal avr register writes. Or something.

Yes, there is - all outlined in the datasheet.

hmmm... Seems perfectly clear to me. Let me try again.
-Temperature control loop interrupt fires every second.
-Motor control loop interrupt fires ~3 times per second
-My sample clock wants to be 125us which I think will be another timer interrupt (I'll write that part tomorrow).
Sometimes, depending on what is happening in the main loop,  I want to respond to a motor interrupt by starting to sample an analog signal.
When that happens, I don't want the slower, relatively less critical ISRs to cause me to miss the faster critical timing interrupts, so I'd turn off only the ones I want to ignore, then turn them back on when I care less.

[Reply #6 on:]

When that happens, I don't want the slower, relatively less critical ISRs to cause me to miss the faster critical timing interrupts, so I'd turn off only the ones I want to ignore, then turn them back on when I care less.

That  makes absolutely zero sense, if you have understood the interrupt section of the datasheet.

1) global interrupt is disabled once you are in an isr. So unless you do something weird, you will miss (as in not servicing their respective isrs) when one isr is being serviced. There are ways around this, but unless you know more than what you are doing, don'g go there.
2) your other isrs will not be missed, however, in the sense that the flags remain set after the interrupts have arrived, even if you are in the middle of another isr. So once you exit the isr, your execution will jump back to the pending isr.

In a properly designed system, you will never have an isr that takes too much time. ISRs are all about being quick and small. The fact that you are even facing such issues suggests a fundamental lack of understanding of how interrupts should be used.

[Reply #7 on:]

No, I understand what I'm doing. But thanks for the insults ;~)
If I get a motor interrupt while in the middle of a PID calculation in my temperature control ISR, by the time I service the pending motor interrupt, it will be too late (motor will have moved).
So I'll turn off the temperature control interrupts to prevent that. Similarly,  I may need to turn off the motor interrupts so my sample timing is deterministic (so I can implement good digital filters).
It looks like I can just reset the appropriate bits in the mask registers (TIMSKO and EIMSK for the timer and external interrupts, respectively).

[Reply #8 on:]

When that happens, I don't want the slower, relatively less critical ISRs to cause me to miss the faster critical timing interrupts, so I'd turn off only the ones I want to ignore, then turn them back on when I care less.

...

I add a faster timer interrupt (say 125us) to sample some data.

What is the nature of this sampling, out of curiosity? Counting pulses? ADC conversion? Something else?

[Reply #9 on:]

... you will miss (as in not servicing their respective isrs) when one isr is being serviced. ... your other isrs will not be missed, ...

Well, I'm confused. Will they be missed, or not?

Hints about interrupts:

http://www.gammon.com.au/interrupts

[Reply #10 on:]

When that happens, I don't want the slower, relatively less critical ISRs to cause me to miss the faster critical timing interrupts, so I'd turn off only the ones I want to ignore, then turn them back on when I care less.

...

I add a faster timer interrupt (say 125us) to sample some data.

What is the nature of this sampling, out of curiosity? Counting pulses? ADC conversion? Something else?

Short bursts of ADC from a rather novel optical scanner of my design (I've done a lot of scanners...).

[Reply #11 on:]

No, I understand what I'm doing. But thanks for the insults ;~)

I don't understand why you're using interrupts to trigger the temperature control processing or the motor control. Is there some unusual latency requirement which requires this?

[Reply #12 on:]

No, I understand what I'm doing. But thanks for the insults ;~)

I don't understand why you're using interrupts to trigger the temperature control processing or the motor control. Is there some unusual latency requirement which requires this?

It's just the best way to do background-running real time feedback loops in my experience.
There's quite a lot happening in the main loop, and if we neglect the temperature or speed longer than spec'd we'll have errors in temp or speed. Plus the code is way cleaner (and finishable) without all the polling of inputs.

Or did you have a better alternative?

[Reply #13 on:]

Short bursts of ADC from a rather novel optical scanner of my design (I've done a lot of scanners...).

Using analogRead? SPI? I2C? Just wondering how the data gets to you.

[Reply #14 on:]

Short bursts of ADC from a rather novel optical scanner of my design (I've done a lot of scanners...).

Using analogRead? SPI? I2C? Just wondering how the data gets to you.

analogRead() seems to be fast enough. Sensor is ballsy optical receiver of my design (optics, PIN diode preamp, 20KHz homodyne modulation (chop) on the light source and receiver). I might try to demodulate in the avr if i can live with ~8KHz chop. But we're drifting off topic...