On Fri, Aug 7, 2009 at 12:35 PM, Chieh-Jan Mike Liang <[email protected]>wrote:
> Hi Jacob, > > I believe Packet.clear() is supposed to clear the packet header and > metadata only. There was a discussion some time ago. That is what Phil Levis has stated. The code reflects a different reality. Some of the code clears the entire message buffer, other code does as advertised. eric > > > Mike > > Jacob Sorber wrote: > > So, the problem is that Packet.clear does different things in > > SerialActiveMessageP and XE1205SendReceiveP. In the first it just > > clears the headers, in the later it clears the entire message_t. So, > > instead of resetting the headers as is intended in BaseStation, it > > blows away the payload it is trying to forward. > > > > Nice. What are the semantics for the Packet.clear command supposed to > > be? From the comments in Packet.nc (tos/interfaces) it seems that the > > XE1205SendReceiveP has it right and BaseStation is using clear > > incorrectly, but since it isn't completely explicit, I guess it could > > go either way. > > > > I'll hack something up for myself, but I am interested to know what > > the "right" way to fix it is. > > > > Thanks, > > > > Jacob > > > > On Tue, Aug 4, 2009 at 4:22 PM, Jacob Sorber<[email protected]> > wrote: > >> Ok, so the problem seems to be the BaseStation app. Relaying packets > >> from Radio to UART works fine, but UART to Radio seems to lose the > >> payload. I'm not yet sure why. > >> > >> Jacob > >> > >> On Tue, Aug 4, 2009 at 10:45 AM, Jacob Sorber<[email protected]> > wrote: > >>> Just curious if anyone has seen this behavior. I have been using > >>> tosthreads with tinynodes a bit lately and I noticed that when I use > >>> BlockingAMReceiverC, receive returns SUCCESS when a packet is sent to > >>> the mote, but the packet payload seems to be all zeros instead of the > >>> data I'm sending. It may be a problem with my code (which I will > >>> continue to explore), but since tosthreads is relatively new, I > >>> figured it might also be a bug. > >>> > >>> If anyone has seen this, or has any ideas, please let me know. > >>> > >>> Also, I just noticed the following code in BlockingAMReceiverImplP.nc. > >>> Line 12 (146 in the file) caught my attention. Can you copy a > >>> message_t struct like that? [*(p->msg) = *m] > >>> > >>> 1: event message_t* Receive.receive[uint8_t am_id](message_t* m, > >>> void* payload, uint8_t len) { > >>> 2: syscall_t* s; > >>> 3: params_t* p; > >>> > >>> 4: if(blockForAny == TRUE) > >>> 5: s = call SystemCallQueue.find(&am_queue, INVALID_ID); > >>> 6: else > >>> 7: s = call SystemCallQueue.find(&am_queue, am_id); > >>> 8: if(s == NULL) return m; > >>> > >>> 9: p = s->params; > >>> 10: if( (p->error == EBUSY) ) { > >>> 11: call Timer.stop[s->thread->id](); > >>> 12: *(p->msg) = *m; //Can you copy a struct like this? > >>> 13: p->error = SUCCESS; > >>> 14: call SystemCall.finish(s); > >>> 15: } > >>> 16: return m; > >>> 17: } > >>> > >>> > >>> Thanks, > >>> Jacob > >>> > > > > _______________________________________________ > > Tinyos-help mailing list > > [email protected] > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > -- Eric B. Decker Senior (over 50 :-) Researcher Autonomous Systems Lab Jack Baskin School of Engineering UCSC
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
