On Jun 15, 2007, at 4:16 PM, Ben Buckner wrote: >>> From: "Ian Welch" <[EMAIL PROTECTED]> >>> Subject: [Tinyos-help] Timer and Atomic Help >>> >>> Hello, >>> I'm implementing a clock on my mote and it seems to drift, I >>> think the >>> issue is to to too many or too long atomic sections. I was >>> wondering if >>> someone could explain to me how atomic sections effect interrupts >>> (events) >>> from the timer module. >> >> This is more a general microprocessor programming question than a >> TinyOS >> question, but, as the documentation says, an atomic section prevents >> interrupt execution, so if your timer fires an interrupt during >> execution of >> atomic code, the interrupt will either not be processed or (less >> likely) >> will be queued until the atomic section is finished. I don't know >> of TinyOS >> being implemented on a controller that can queue interrupts, so it >> will >> probably be lost (definitely lost on Mica*s), but that could be a >> platform >> dependent behavior.
>Almost all processors today (and all for the sake of this discussion) >work in a simple way: > >1) when a condition to cause an interrupt occurs, the processor sets >the interrupt pending bit in a control register > >2) if an interrupt is enabled and its pending bit it set, the >interrupt fires and the handler executes > 2a) depending on the hardware and interrupt source, the pending >bit may be automatically cleared when the interrupt fires > >So you only lose an interrupt if it is disabled long enough that the >pending bit is already set when the condition occurs again. In >essence, the processor has a 1-deep queue for each interrupt source. ... >Phil I'm reading the ATMega docs more closely, and that is true for some interrupts on it but not all. "There are basically two types of interrupts. The first type is triggered by an event that sets the interrupt flag. For these interrupts, the Program Counter is vectored to the actual interrupt vector in order to execute the interrupt handling routine, and hardware clears the corresponding interrupt flag. Interrupt flags can also be cleared by writing a logic one to the flag bit position(s) to be cleared. If an interrupt condition occurs while the corresponding interrupt enable bit is cleared, the interrupt flag will be set and remembered until the interrupt is enabled, or the flag is cleared by software. Similarly, if one or more interrupt conditions occur while the global interrupt enable bit is cleared, the corresponding interrupt flag(s) will be set and remembered until the global interrupt enable bit is set, and will then be executed by order of priority." "The second type of interrupts will trigger as long as the interrupt condition is present. These interrupts do not necessarily have interrupt flags. If the interrupt condition disappears before the interrupt is enabled, the interrupt will not be triggered." (p 13 ATmega 128L manual) This particular counter interrupt could perhaps be this vaguely described non queuing kind. I would have thought that if any interrupt was going to be queuable, it would be a counter output compare (and the non-queuables would more likely be something like level-triggered external interrupts), but I don't see anything in the timer section that says anything definitive. I'm pretty sure I have lost OC interrupts on a Mica2 though. When I timed the ADC near its max sampling rate, I would get occasional and suspiciously periodic drops when I didn't have all the other counters shut off, but I guess that could have just been the extra latency pushing it into the next counter cycle. Easy enough to test. Regards, Ben Buckner _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
