You're right - one message is allocated per AM type with the Transceiver. Feel free to edit the component to meet your demands, but there were some considerations that led us to design it that way.
Here was the reasoning behind that approach - After calling sendRadio or sendUart, the Transceiver will look up the TOS_Msg to send based on its AM type and mark that message as good to go. So, if you had two processes that were allocating two messages of the same AM type, the Transceiver could accidentally send the wrong message when one of the processes calls send. This would be a bad thing. Another reason we allocated only one message per AM type was just to make sure nobody had an accident - if you request a message from the Transceiver in a component, and then accidentally forget to send one, the Transceiver will stop up and your mote will no longer work, until that allocated message gets sent (because the circular buffer is waiting for a message to get done being written). Finally, if you send more messages at once than the Transceiver has available to write to, eventually you'll run out of space to buffer up these messages and the Transceiver.requestWrite() command will start returning NULL. If you can be a very careful programmer and make sure none of these cases occur, then make the Transceiver component do whatever you want it to do. But keep in mind that the "normal" method for a component to send consecutive messages is to send the message and wait for the sendDone event before sending the next message. If you have many messages to send, one right after the other, eventually the Transceiver's circular buffer is going to run out of places to write (depending on how much RAM you allocated to it via the MAX_TOS_MSGS preprocessor variable). For example, I have an application that needs to take a file and transfer it in TOS_Msg payloads over the Radio or Uart. This requires many, many consecutive messages. The way it works is I first put the component into some kind of SEND state so it knows its transferring this file, then I send the first message. When sendDone gets called, I can send the next message because the component knows its in the SEND state, so it should be sending messages. I keep sending messages in this fashion until I reach the end of the file. This way, the TOS_Msg buffers aren't overloaded in Transceiver and your component's transmission rate actually scales to the rate of whatever communication channel you're using. -David -----Original Message----- From: Matthew S. Nassr [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 08, 2006 4:57 PM To: David Moss Cc: [email protected] Subject: RE: [Tinyos-help] QueuedSend deadlock problem update 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
