Clean way to turn interrupts on and off?

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!

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.

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.

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.

dhenry:
Yes, there is - all outlined in the datasheet.

It would be less typing to actually give the answer:

noInterrupts ();

dhenry:

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.

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.

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).

vvmvbb:
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?

dhenry:
... 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:

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

vvmvbb:
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?

PeterH:

vvmvbb:
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?

vvmvbb:
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...

vvmvbb:
analogRead() seems to be fast enough. ... But we're drifting off topic...

Well, not really, because timing seems to be important to you.

vvmvbb:
-My sample clock wants to be 125us which I think will be another timer interrupt (I'll write that part tomorrow).

A normal analogRead (save fidding with registers) will take 104 uS. So most of your 125 uS is gone in doing the analogRead alone. I'm drawing that to your attention in case you think it is instant, and that you have something like 110 uS over between reads.

One possible thing you could do which would remove the worry about interrupt latency, and also whether or not another interrupt was active, would be to use the external ADC trigger (page 252 and 266 of the datasheet). You could start the conversion highly reliably on a timer compare match event, and then just use an interrupt to gather the ADC results, when available. This also means you don't wait 104 uS doing nothing. Win win!

Avoiding other issues...

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

Why do you have this "minimal avr register writes" desire? To turn off an INDIVIDUAL interrupt, you typically have to change a single bit setting in one register:

TIMSK1 &= ~(1<<OCIE1B);  // Turn off timer interrupt
  :
TIMSK1 |= (1<<OCIE1B); // Turn timer interrupt back on

Those should run about 3 Instructions each, and this isn't some multi-GHz chip where accessing an IO register might be unusually "expensive" because it stalls the pipeline and invalidates caches or something. If you want control of the individual interrupts, I don't think that you can get any "slicker." Now do you need to.
Note that you do NOT need to reinitialize the rest of the timer just to turn interrupts on and off, but that may mean that you will get an interrupt as soon as you re-enable it...

Yeah, I was measuring ~120us max latency in the analogRead(), plus whatever to write an int to an array (I didn't measure that yet). This drove the 125us sample time goal. There's time between bursts to process the array of samples as little, and as much time as it takes to post process it after the scan.

--> I really like the auto triggered ADC and will certainly do that. Very helpful, many thanks.

westfw:
Avoiding other issues...

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

Why do you have this "minimal avr register writes" desire? To turn off an INDIVIDUAL interrupt, you typically have to change a single bit setting in one register:

TIMSK1 &= ~(1<<OCIE1B);  // Turn off timer interrupt

:
TIMSK1 |= (1<<OCIE1B); // Turn timer interrupt back on



Those should run about 3 Instructions each, and this isn't some multi-GHz chip where accessing an IO register might be unusually "expensive" because it stalls the pipeline and invalidates caches or something. If you want control of the individual interrupts, I don't think that you can get any "slicker." Now do you need to.
Note that you do NOT need to reinitialize the rest of the timer just to turn interrupts on and off, but that may mean that you will get an interrupt as soon as you re-enable it...

Yes, that's what I was after, thank you. By minimal register writes this is what I had in mind (I was hoping (assuming) that I wouldn't need to re-setup all the registers, or figure out what exactly detachInterrupts() does). Cheers.

I'm just wondering if you'll be using millis() or micros() while interrupts are off?

There are fast read ADC chips you could add and 328P's have a fast read 8 bit ADC mode.
Most code runs at clock MIPs but I/O takes a bit longer.

I have timing code that does a digital read, counter increment, and counter timeout check all in just under 1 usec per while loop with zero interrupts since I'm using micros() for time as well.

Change that to an analog read and I'm 105 usec per loop.

IIRC whole sections of the MCU shut down during ADC so as to not affect the conversion, or is that a non-default option?

You should be playing with sound chips at those speeds anyway. 8k samples per ain't much to those, even at higher resolution.