someone else (phil?) already sent some better ideas about task
(non-)pre-emption problems. My suggestion was about the code
that you believe is blocking the receive....
In any case, assuming things are mostly the same as the micas',
byte-by-byte reception should be occurring in an interrupt routine,
and the last of those receptions should (maybe, I hope) call your
Message.receive() method -- still in the interrupt context.
So, if interrupts are shut off for some reason -- e.g. atomic{} --
then you'll never get a receive().
On the other hand if the Meassage.receive() is called from a task
that has been posted by the lowlevel radio code, you could be blocking
it by hogging things with another task that doesn't finish. I don't think
this is the case because I wouldn't expect Message.receive() to be
labeled an event...as usual I'm probably wrong...
good luck....
MS
Andrea Pacini wrote:
NO, I didn't use any atomic statement. Just a normal receive:
event TOS_MsgPtr ReceiveMessage.receive(TOS_MsgPtr m) {
}
but this event is not triggered when other mote sends a message.
Michael Schippling wrote:
you didn't put the for loop in an atomic{} block did you?
That would shut off interrupts...
MS
Andrea Pacini wrote:
I am using Tmote Sky motes and I noticed that , when a node is doing
something (e.g. when it is doing a for cycle) it can't receive
message, that is Receive.receive() event is not triggered.
Instead , if the node is doing nothing , the receive event is fired
and all woks.
Note that the sender sends only one message . How is possible ?
Doesn't exist a queue of WAITING EVENTS ?
Thanks
Andrea
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
