Hi folks,
Ravi, You're right man!
Although I use the boomerang distribution, the UserButtonM is a bit different.
So I use the MSP430InterruptC to receive interrupt from the hard-button instead and "the event preempt that infinite task" now.
So I use the MSP430InterruptC to receive interrupt from the hard-button instead and "the event preempt that infinite task" now.
Thanks,
Chalermphol
On 7/5/06, Ravi Prasad <[EMAIL PROTECTED]> wrote:
Check the following code extracted from UserButtonM.nc:
//---------
event result_t Timer.fired()
{
atomic
{
call MSP430Interrupt.clear();
call MSP430Interrupt.enable ();
}
return SUCCESS;
}
task void debounce()
{
call Timer.start( TIMER_ONE_SHOT, 100 );
}
async event void MSP430Interrupt.fired()
{
atomic
{
signal UserButton.fired();
// debounce
call MSP430Interrupt.disable();
post debounce();
}
//----------
Here for debouncing the button it disables the interrupt and uses a task (task debounce) to re-enable the interrupt. Now as our infinite task is running, this will never happen and thus no interrupt will occur again. Thats why it works for exactly ONE time (after our infinite task has been posted). and then stops.
you can modify the code for async event void MSP430Interrupt.fired like below :
//----------
async event void MSP430Interrupt.fired()
{
atomic
{
signal UserButton.fired();
// debounce
call MSP430Interrupt.disable();
//post debounce();
//I am implementing debounce here.
//A bad code but good fix for testing the concept :-)
TOSH_uwait(50000);
call MSP430Interrupt.clear();
call MSP430Interrupt.enable();
}
//---------
I am only having the micaz motes and not the telos motes so I cannot test my suggested code. But it should work.
Chalermphol Thammapalerd <[EMAIL PROTECTED] > wrote:Sure man,Please check info.txtChalermphol
On 7/5/06, Ravi Prasad < [EMAIL PROTECTED]> wrote:
Can u send me the code. May be I can figure out the problem
Chalermphol Thammapalerd <[EMAIL PROTECTED] > wrote:Yes, it simply toggle the LED.Note that I'd be happy to share my code because it's very important part of the system to prove.Regards,Chalermphol
On 7/4/06, Ravi Prasad < [EMAIL PROTECTED]> wrote:
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 EventSomeExternalInterrupt.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_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1�/min.
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min.
How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
