Is the event B is doing its job inside an ISR  or a lower level event called from ISR ?? OR it is trying to post a task for its job??

It seems your's is the second case.

I suggest you to simply toggle an LED in your event.


Chalermphol Thammapalerd <[EMAIL PROTECTED]> wrote:
Hi folks,
 
Thanks for the answer, but I'm sorry for my vague question.
Ravi, In your excellent case, the task is absolutely preempted.
But how about the unfinished task(actually I mean to the never-finish task)?
My test is,
 
A. A never-finish task which is periodically posted
   {
   while(1) {
   //do a thing
   }
   }
 
B. Asynchronous Event
    SomeExternalInterrupt.fired {
    //do another thing
    }
 
In this case, B is able to generate the event to "do another thing" but only once and the mote seems like hang.
I'm not sure if this kind of programming should never be used or there're some trick(s) to avoid this deadlock? or is it a deaklock anyway?
 
Regards,
Chalermphol
 
On 7/4/06, Ravi Prasad <[EMAIL PROTECTED]> wrote:

Make an application as follows:

1. Implement a task
       task free_run_timer(){
          a. initiate a  _free_  runing timer to count.
          b. wait a fixed amount of time.
          c. stop timer.
          d. Read and send the value of timer/counter to radio/uart.
       }
**Do not use any atomic statement in this task.

schedule a timer to post this task periodically.



2. Implement an event which is having a fixed delay in it. A short cut is to use the UART as an interrupt source. Everytime you send a character to mote from a PC by serial port it will generate an interrupt and thus an event.Remember to use the uart/radio interface in your application and start it properly.


Now if there is no event generated (do not send any radio or UART packet to mote) then the counter value will be same every time. When you generate an event(possibly by sending a uart packet) you can easily see the counter value to be changed which proves the task was preemted to serve the event.
**Probably you will have to genererate a series of events so that few of them fall inside the time when task is running.



Chalermphol Thammapalerd <[EMAIL PROTECTED] > wrote:
Hi,
 
I tried to prove one of the TinyOS concept, "Events preempt tasks, tasks do not", by using external event to preempt unfinished task.
However, the task is not seem to be preempted at all.
Are there any example(s) that prove this concept?
 
Regards,
Chalermphol

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com



How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to