which port on interrupt on a JeeNode?
The 4 ports of a JeeNode all have the same interrupt available. If one of the ports triggers the interrupt, is there a reliable way to figure out which of the ports was involved?
RE: which port on interrupt on a JeeNode? - Added by martynj over 6 years ago
Assuming you have a priori knowledge of what peripheral(s) are expected to pull down the common INT line, then the interrupt service routine needs to check through a list of status registers that contain latched information - ‘yes, I’m interrupting and this is why’. Conventionally, this status should not clear until the register is read, then a specific volatile flag is set for some base level loop to pick up (to keep the interrupt level service routine as short as possible), then flags cleared and interrupts are re-enabled.
There any many subtleties in writing a bullet-proof interrupt handler. For example, since that INT line is OR’ing multiple sources, there may well be a further interrupt hidden behind the first detected. The interrupt service routine will execute again almost immediately (the processor design guarantees that at least ONE base level instruction will execute before re-entering the service routine). In general, pin change interrupts are harder to deal with (an interrupt is generated by either transition on a designated pin) since more state save is required and the pin transition may not be latched.
Nested interrupts are possible - where the lower priority service routine can itself be interrupted by a higher priority interrupt. Great care is needed with where/when global interrupts are re-enabled and a good ‘system view’ kept in mind e.g. the Brown Out detector or a delay timer can trigger at any time. Recall that your view when coding in a high level language does not see the multiple individual instructions generated for some constructs - meaning that the normal logic flow can jump out to a service routine seemingly part way through an innocuous statement.
Debugging is difficult - printing off trace information will usually disturb timing enough to mask or completely change the problem.
The good news is that it all can work, 100% reliable if you follow the rules. The bad news is that there is a interrupt Murphy’s law - if you have left even the narrowest timing window, interrupt service will crash and burn sooner or later.
It’s even more fun with peripherals that can directly access memory ‘behind your back’ - but that’s for grander architectures than the ATMega.