David, That would make sense, I am in fact passing the same message
pointer to QueuedSend. The message data must be getting changed while
the Send is in progress. Your transceiver component sounds intriguing.
I could very well be wrong, but looking at the code, it seems that since
I only get 1 pointer per AM type, I will run into somewhat of a problem.
requestWrite will keep returning the same TOS_MsgPtr (if I only have 1
AM type). Should I simply modify the code in requestWrite() to return
&msg[nextWriteMsg].tosMsg regardless of whether the AM msg type is
unique? Thank you very much for your help and code contribution.
-Matthew Nassr
On Wed, 2006-03-08 at 12:03 -0700, David Moss wrote:
> Are you using the passing the same TOS_Msg into QueuedSend each time?
>
> QueuedSend only stores pointers to messages to queue up. So if you really
> want to write more than one message at once, I think you have to be writing
> to more than one TOS_Msg. I've only rarely used QueuedSend, so someone can
> correct me if I'm wrong. But I think you may be mangling the send data
> while it's being sent.
>
>
> Here's something you may be interested in... I uploaded a Transceiver
> component to tinyos-1.x/contrib/rincon/tos/lib that provides the
> functionality you are probably looking for.
>
> This Transceiver component combines the functionality of GenericComm,
> UARTComm, AMStandard, and QueuedSend into one clean, compact component.
> It's a single interface to use to send/receive messages over Radio and UART
> while decreasing RAM consumption for applications by providing a circular
> buffer of TOS_Msg's set at compile time. Said another way, each component
> in your application that sends messages doesn't need to allocate its own
> TOS_Msg.
>
> Read the README.txt in that contrib/rincon/tos/lib directory for more
> information, and there are example implementations provided in
> /contrib/rincon/apps
>
> * Example usage:
> * <code>
> * TOS_MsgPtr *tosPtr; // global
> * YourStruct *yourStruct; // global
> *
> * // Easy way to allocate and initialize a message for
> * // your whole application:
> * result_t newMessage() {
> * if((tosPtr = call Transceiver.requestWrite()) != NULL) {
> * yourStruct = (YourStruct *) tosPtr->data;
> * yourStruct->msgID = msgID++; // auto init example
> * yourStruct->from = TOS_LOCAL_ADDRESS; // auto init example
> * return SUCCESS;
> * }
> * return FAIL;
> * }
> *
> * void sendSomethingOverRadio() {
> * if(newMessage()) {
> * // This AM type has a message allocated and initialized
> * yourStruct->value = getCurrentReading(); // example.
> * call Transceiver.sendRadio(TOS_BCAST_ADDR, sizeof(YourStruct));
> * }
> * }
> *
> * void sendSomethingOverUart() {
> * if(newMessage()) {
> * call Transceiver.sendUart(sizeof(YourStruct));
> * }
> * }
> * </code>
>
> -David
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Matthew S.
> Nassr
> Sent: Wednesday, March 08, 2006 11:44 AM
> To: [email protected]
> Subject: [Tinyos-help] QueuedSend deadlock problem update
>
>
> In a previous message I assumed that my QueuedSendM in tos/lib/Queue
> wasn't working because the queue was full. This is not true. It can
> happen regardless of where the pointer to the circular queue is, and it
> seems to happen when a rapid succession of Sends are called. Has anyone
> else had this problem? I have a feeling that I will need to make
> QueuedSendDone asynchronous, but that's a wild guess. I could understand
> if a message here and there failed to send, but the deadlock is a
> horrible issue.
>
> -Matthew Nassr
--
Matthew S. Nassr <[EMAIL PROTECTED]>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
