What's the harm in disabling interrupts in setup?

M

madmyers

Active member
Theoritical and kind of real world question.

What harm is there in disabling interrupts in setup() and leaving them off? Obviously this prevents functions from running that use interrupts.

But is there anything about the Teensy 4.1 that demands interrupts are enabled?

Is there a list of functionality that breaks w/interrupts disabled?

I don't think I need any functionality based on interrupts, but cannot say for sure unless there's a list of the functionality that requires interrupts.

The only annoyance I've seen

1. I need to manually press the Teensy button to upload firmware.
2. No USB serial output

Thanks!
 
Last edited:
A better question might be what works without interrupts.
Serial output will eventually stop working. millis() will never update, affecting anything that relies on it or delay(). Anything related to audio or USB definitely won't work.
 
Thanks for the reply. The good news, for me, is that I don't use mills() or delay() and don't need serial. So I'm wondering what other surprises are out there...
 
Until a device is activated the Millis_Tick is the only thing running on interrupt.
Losing Button update is known - but USB is disabled with a 'NO USB' build.

No active interrupts can be seen with : asm(" wfi");

Even the Millis_Tick "ISR" won't wake that as it isn't setup as such an interrupt as it works.

pseudocode - this will light LED and it will never go OFF:
setup()
pinmode(13,output)
digwrite(13,high)
asm(" wfi");
digwrite(13,low)

Add an interrupt that can be triggered (pinChange?) and it will wake

So the only active interruption is the short millis_tick:
extern "C" void systick_isr(void)
{
systick_cycle_count = ARM_DWT_CYCCNT;
systick_millis_count++;
}
 
Thanks!

That would seem to mean that disabling then systick_isr (not sure how) would allow me to keep interrupts enabled but avoid any periodic ones, while keeping the automatic firmware download operational. I believe USB serial / automatic firmware download doesn't require random/periodic interrupts unless you actually try to do a download.

That seem right?
 
madmyers said:
I believe USB serial / automatic firmware download doesn't require random/periodic interrupts unless you actually try to do a download.

That seem right?
Click to expand...
No. Any usb serial communication requires interrupts, including the systick timer. Lots of code relies on the systick timer, either directly or via delay().
 
Not sure the value in getting the systick turned off - it will trigger 1K interrupts per second - but they couldn't be much shorter. Reading the ARM_DWT_CYCCNT takes about 3 cycles and ++ of the count about the same?

The ARM_DWT_CYCCNT count is running for precise timing if needed.
 
I read elsewhere than an interrupt takes around 240ns give or take based on cpu speed. Is that right?

That’s functional breaking random delay for me. I completely understand many situations wouldn’t care at all about this.

I could try and keep interrupts off almost all the time and enable at a brief spot where I could support 240ns. But why bother if none of the functions they are used for are needed by me.
 
Last edited:
Almost all projects require interrupts, for pretty basic stuff like USB communication and the timing functions like millis(), elapsedMillis, etc.

But if you truly don't need any of that stuff and your code is doing to really tight timing, sure, might as well turn off interrupts.

Without USB communication Teensy can't respond when you try to initiate code upload from your PC, but you can simple press the pushbutton. Every Teensy has that pushbutton specifically to allow entering programming mode even when software running on Teensy is utterly unresponsive to the USB request to go into programming mode.
 
madmyers said:
I read elsewhere than an interrupt takes around 240ns give or take based on cpu speed. Is that right?

That’s functional breaking random delay for me. I completely understand many situations wouldn’t care at all about this.

I could try and keep interrupts off almost all the time and enable at a brief spot where I could support 240ns. But why bother if none of the functions they are used for are needed by me.
Click to expand...
I'm curious what you're doing that has such tight timing requirements?
Lots of other things can delay execution by up to 200ns. PSRAM access to uncached data is a big one, accessing flash is another.
 
You must log in or register to reply here.
Back
Top