I have already seen a lot of sketches that involve using interrupts. I'm just very curious as to why all of those that I have seen don't put code inside their ISR function except for changing the associated Boolean value to false. They just put a while() loop within the main loop to wait for the interrupt. Why not just put the desired post-interrupt code in the ISR?
Why not just put the desired post-interrupt code in the ISR?
ISRs are meant to be short routines that flag the fact that the interrupt has happened and maybe the time it happened and/or the state of another pin. By its nature the interrupt can happen at any time so it is usually better to react to it in the main program at a suitable point. In addition, there are things that you cannot do in an ISR, such as using Serial.print() because interrupts are disabled when in an ISR and Serial.print() uses interrupts.
They just put a while() loop within the main loop to wait for the interrupt.
This is an unusual way to write a program. If there is a while loop waiting fro an interrupt it might just as well monitor the interrupt pin itself.
Interrupt routines should be as short and fast as possible. The serial communication, the I2C communication and the system time with millis() are using interrupts. The Arduino Uno is only 16MHz, so to keep it running smooth, the interrupt routines should be very short.
When a ISR is busy, any new interrupt has to wait until the first ISR has finished. It is possible to enable interrupt in a ISR, but then the limited amount of ram for the stack could be a problem.
Tutorial about interrupts : Gammon Forum : Electronics : Microprocessors : Interrupts
I didn't know that an interrupt could be enabled inside an ISR. You said that when an ISR is busy, new interrupts would have to wait. Then how would another interrupt occur within an ISR?
Btw, thanks for mentioning something about the stack overflow due to RAM limits.
raxkaynan:
I didn't know that an interrupt could be enabled inside an ISR. You said that when an ISR is busy, new interrupts would have to wait. Then how would another interrupt occur within an ISR?
Usually, it shouldn't. Interrupts are normally serviced on a first come first served basis.
MCU disables interrupt automatically just before jump into ISR but can be enabled by code inside of ISR as was written above. The stack and related things works by the same way as in main program. If in that case another interrupt occurs the return address and registers are normally saved in stack and are used in return after another ISR ends and code execution will continue from the place of the second interrupt occurrence.
Even though the interrupts can be enabled, it is not possible to make a timing critical interrupt execute always regardless of an ISR being busy.
You should not enable interrupts in a interrupt. I think it is used inside an Arduino library, but it has consequences for the stack, and for the code.
On the other hand, the microcontrollers have for example hardware timers, with inputs and outputs. To count pulses without missing something is typical the task of a hardware timer (the Arduino Uno has 3, and TIMER0 is in use by the Arduino timing system).
I think these things are normal for a microcontroller with only little ram and flash memory, it is not a computer.
Just note that on ATmegas there is internal status register with flags for each interrupt type to be queued during ISR or when the interrupts are disabled. One interrupt for each type is queued and any other occurrence is missed.
Koepel:
I think these things are normal for a microcontroller with only little ram and flash memory, it is not a computer.
I find that definition of "computer" very strange.
aarg:
I find that definition of "computer" very strange.
;D I remember the time of 8bit PCs with little bit more memory but less clock frequency than ATmega has.
Budvar10:
;D I remember the time of 8bit PCs with little bit more memory but less clock frequency than ATmega has.
You must be pretty young then. I remember the PET - Commodore PET - Wikipedia and the biggie http://archive.computerhistory.org/resources/text/EAI/ElectronicAssoc.EAI640.1966.102646101.pdf . Even the best EAI640 had less total memory and was slower than my Mega2560 . And what about the Apple II and the BBC micro!