I'm cc'ing this back to the list to keep a record of my mistakes... I think this's the question you asked originally isn't it? Interrupts can come in at any time since they are almost always caused by external events which may/not have a regular pattern. Without specific knowledge of the hardware in question (pretty much at the micro-second level) you can only model them stochastically.
Then, depending on how the int handler deals with things, interrupts may be blocked until a handler returns, or some may be allowed to pre-empt a running handler...I'm not sure that the ATMEGA or MSP have interrupt priority levels, so it's more likely all or none. Most interrupts are "edge-sensitive" in that they latch ON and don't go away until the software does something about them -- so they stack up like planes at an airport -- but it's not clear in what order they will be serviced. On top of that, there is a small class of interrupts that are "level-sensitive" and only have an effect when their external signal is ON -- they can go away at the whim of the external hardware if they are not serviced in time. So, basically, assume that there may be a concurrency issue with any variable that is used both in a task and an event... further analysis may show that single instruction reads (e.g., of a 1 byte flag) won't create havoc, but just about any mutex or condition-variable sort of operation will involve read-modify-write which doesn't happen in a single instruction with our controllers... MS Bin Lei wrote: > Dear Michael, > > Thanks a lot. I didn't go to the controller's interrupt manual coz I > am not farmiliar with hardware and it's too hard for me :-( > > I got another question with interrupt, is it possible for a device > signal another interrupt > before the first interrupt service routine hasn't finished execution? > > I am working on an program analysis tool to find concurrent faults in > nesC programs, and the answer is a key point. So as the previous > question. > > _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
