What examples have you got for using attachInterrrupt with LOW?
Transitional change checks like CHANGE, RISING and FALLING seem pretty obvious but a steady state condition like LOW??? Once there it 'sticks' in the interrupt preventing the loop from running.
You generally use this with hardware that releases the interrupt in responce to a pulse from a pin or access to a register. It is used as a sort of handshaking.
Grumpy_Mike:
You generally use this with hardware that releases the interrupt in responce to a pulse from a pin or access to a register. It is used as a sort of handshaking.
My brain is clattering away on that one... where/how does this work better that a CHANGE, RISING or FALLING?
You would generally use it in sleep mode. The LOW signal can cause an external interrupt where the others don't.
Once there it 'sticks' in the interrupt preventing the loop from running.
In the ISR detach the interrupt then it won't stick.
Example here (Sketch J):
Good question!!! I think it fires each time it runs the loop method. But I never tested, always used rising.
If you don't detach it in the ISR it will fire on every second machine instruction. The hardware guarantees that at least one instruction is executed after leaving an ISR.
Grumpy_Mike:
You generally use this with hardware that releases the interrupt in responce to a pulse from a pin or access to a register. It is used as a sort of handshaking.
I don't agree with this one Mike. The LOW interrupt is not queued and is not appropriate for detecting edges like that. It is really for waking from sleep.
To summarise it is used in the special case of 'sleep'' mode (which I shall have to look up and find out about) which means the other interrupt types don't work - so Hobson's choice. Thereafter you have to 'release' it by detaching it otherwise you're locked out of loop().
Don't remember reading anything about that in the library documentation... okay, okay someone prove me wrong, it's there somewhere I guess.
Once there it 'sticks' in the interrupt preventing the loop from running.
It doesn't stick in the interrupt, it re-interrupts the moment you leave the ISR (and one more instruction later). Thus it would slow down the CPU performance very much, if you don't cancel it before you leave the ISR.
Again, the difference between LOW and FALLING is that FALLING detects a transition, whereas LOW keeps firing until such time as the LOW signal is removed (or the interrupt is disabled, whichever occurs first).
acboother:
To summarise it is used in the special case of 'sleep'' mode (which I shall have to look up and find out about) which means the other interrupt types don't work
Pin change interrupts work in sleep mode. But they don't have LOW/RISING/FALLING/CHANGE configurations.
Thanks Nick, I got the difference between the state changes and LOW and I kinda guessed it came out and back in straight away but didn't mention it as its not what 'appears' to happen. Will put 'sleep' on my bucket list
acboother:
Don't remember reading anything about that in the library documentation... okay, okay someone prove me wrong, it's there somewhere I guess.
You are right it is is not mentioned, but why should it be?
In the first micros there was only an active low, then they added active high and finally edges. Yes it used waking up from the sleep mode but it is also used in interrupt piority encoder chips which is an example of my first reply.
Remember this processor is not about an Arduino, it is a fully grown up processor.
acboother:
Don't remember reading anything about that in the library documentation... okay, okay someone prove me wrong, it's there somewhere I guess.
You are right it is is not mentioned, but why should it be?
I am going to have to disagree with Grumpy Mike on this one. I am a very experienced firmware engineer, and using Arduino for some fun projects outside of work. I haven't had the time to dive into the implementation details, but I know interrupts inside and out, no doubt about that.
I was looking in the API documentation for some mention of this problem with a level-triggered interrupt (which is apparently what LOW gives you) and it's not there. I myself suspected that LOW is in fact setting a level-triggered interrupt, and it was not until I found this forum article that I found the information confirming this suspicion.
I have to insist, it is essential the documentation be made very explicit about this problem. It's really not enough to have some (very useful and generously-provided) side-notes by Mr. Gammon; the problem with LOW should be stated right there, in the attach_interrupt() reference. Otherwise, it's really left up to the reader to deduce the existence of the problem from this single sentence:
LOW to trigger the interrupt whenever the pin is low
I will suggest an update to the reference page in the forum.
Mr. Boother is right... the API should mention this "feature" of using LOW.
but I know interrupts inside and out, no doubt about that.
In which case you will know what a LOW trigger does. Why do you think it deserves special mention in the API documentation?
If it is just that beginners could be confused then there are far more important things that this to worry about.
A LOW trigger "does what it says on the can", triggers when the interrupt is low. End of story. If you don't want that then don't choose LOW. As I have already said I have used them when adding a priority encoder chip ( although not on this processor ).
From the ATmega328p Data Sheet:
The INT0 and INT1 interrupts can be triggered by a falling or rising edge or a low level. This is set up as indicated in the specification for the External Interrupt Control Register A – EICRA. When the INT0 or INT1 interrupts are enabled and are configured as level triggered, the interrupts will trigger as long as the pin is held low. Note that recognition of falling or rising edge interrupts on INT0 or INT1 requires the presence of an I/O clock, described in ”Clock Systems and their Distribution” on page 26. Low level interrupt on INT0 and INT1 is detected asynchronously. This implies that this interrupt can be used for waking the part also from sleep modes other than Idle mode.
The I/O clock is halted in all sleep modes except Idle mode.