Hi! On Wed, 17 Mar 2010, Zheng Manchun wrote:
> Hi Razvan, > > In the nesC paper, http://nescc.sourceforge.net/papers/nesc-pldi-2003.pdf > it is said that an interrupt handler can preempt the execution of a task. > I just doubt that if an interrupt only posts a task to execute the > corresponding event of a specific interface, the preemptive ability of > interrupt handlers goes away. > > I'm confused by the concepts of interrupt, event, task, command of nesC. > Pls help me to clarify them. > You can consider tasks as manually implemented software interrupts. Imagine that you have a vector of bits with one bit reserved for each task. When you post a task to flip the bit to 1 to indicate that the task needs to be run. Now imagine that there is a loop that iterates over this vector and each time it encounters a 1 it resets it to 0 and executes the task that corresponds to that position in the vector. To make the picture complete, when the vector contains only zero the looping suspended by putting the MCU to sleep. If an interrupt occurs the current state is saved and the interrupt handler is executed. Most interrupts are short but not all of them. A signal is just a function call. :-) All the best! Razvan ME > Thanks & Best Regards, > Manchun > > > ------------------------------------------------------------------------------------ > Hi! > > On Mon, 15 Feb 2010, Mido wrote: > >> * Would it be possible that an interrupt is triggered during the execution of > *>* an event (e.g. fired), and that interrupt posts a task that will signal > the > *>* next event before the current event completes? > *>* > *>* For example, if a timer has a very high frequency, and the fired() event > is > *>* doing long processing. > *>* > * > As you said, an interrupt handler usually is very short and it posts a > task. That task usually signals the appropriate events. While this task is > executed it is possible that the original interrupt is fired again. The > task will be interrupted, the task handler will be executed and the task > will be scheduled again for execution. > > -- Razvan ME > >> * -----Original Message----- > *>* From: tinyos-help-bounces at millennium.berkeley.edu > <https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help> > *>* [mailto:tinyos-help-bounces at millennium.berkeley.edu > <https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>] > On Behalf Of Razvan > *>* Musaloiu-E. > *>* Sent: Monday, February 15, 2010 2:48 AM > *>* To: Arik Sapojnik > *>* Cc: Tinyos-help > *>* Subject: Re: [Tinyos-help] Tasks and interrupts > *>* > *>* Hi! > *>* > *>* On Wed, 10 Feb 2010, Arik Sapojnik wrote: > *>* > *>>* Hello, > *>>* > *>>* I'm trying to understand the interrupts in TinyOS. > *>>* It looks like even when an interrupt is occurred (for instance a timer), > it > *>>* only posts the desired task (for instance Timer.fired() ) to be executed > *>>* somewhere in the future. > *>>* Hence the interrupt preempts the task only to post it's task (a VERY > short > *>>* period of time). > *>>* Is it really so? > *>>* > *>* > *>* Yes, that is correct. > *>* > *>* -- Razvan ME > *>* > * > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
