Philip Levis escreveu:
On Mar 13, 2007, at 8:34 AM, Filipe Alves wrote:
Hi, everybody,
I have some questions about using generic modules/configurations.
The situation is this: I'm creating an module like the QueuedSend in
tinyos-1.x, for tinyos-2.x,
however as the sending base is AMSenderC, and there is the generic
module QueueC,
I was thinking in using a generic configuration to "allocate" the
AMSendC and QueueC, and
as the state machine is equal for all a normal component that uses
the first two components.
The question is does Tinyos know what specific generic
modules/configurations to call ?
An example of code is this:
generic configuration QueuedSendC(am_id_t amtype, uint8_t QueueSize ){
provides AMSend;
}implementation{
components new AMSendC(amtype) as SubSend, new QueueC(message_t*,
QueueSize ) as Queue, QueuedSendP;
QueueSendP.AMSend -> SubSend.AMSend;
QueueSendP.Queue -> Queue.Queue;
AMSend = QueueSendP;
}
Those a call to an instance of QueuedSendC know that it is linked to
a particular AMSendC/QueueC ?
Please note that implementing a queue in this fashion raises a lot of
issues; if you look at the 1.x CVS, I believe that QueuedSend,
although only 81 statements, has more revisions and bug fixes than any
other source file in the tree.
In fact, the interfaces in 2.x were explicitly changed to prevent some
of the issues that QueuedSend introduced. In particular (and this will
be in TEP 116 after its next round of editing), you cannot have two
consecutive calls to Send.send that return SUCCESS. That is:
if (call Send.send(...) == SUCCESS &&
call Send.send(...) == SUCCESS) {
// This code will never execute
}
This behavior is very important for compile-time verification and
command/event matching. One of the major problems you encounter with
1.x's QueuedSend is that you don't know why a FAIL occurred. For
example, in some versions of QueuedSend, if you tell QueuedSend to
send a packet that's too long, then it will try to send it, the radio
stack returns FAIL, and the packet will block the queue forever. From
the caller of Send's perspective, now it has to distinguish a full
queue from other failure conditions: code above is generally written
to either assume a single outstanding packet at any time, or many.
Having to write it for both cases as defensive programming breaks the
idea of being able to easily swap components.
I'd recommend that you create a new interface, QueuedAMSend, which has
the properties you want. That is, QueuedAMSend can have multiple
outstanding packets at any time. But since it's a new interface, you
can include additional functionality (e.g., isQueueFull) and specify
different error return codes. Implementing it would be pretty
straightforward. It would look something like this:
generic configuration QueuedAMSenderC(am_id_t id, uint8_t size) {
provides QueuedAMSend;
provides Packet;
provides AMPacket;
}
implementation {
components new QueuedAMSenderM(), new AMSenderC(id), new
QueueC(message_t*, size);
QueuedAMSend -> QueuedAMSenderM;
Packet -> AMSenderC;
AMPacket -> AMSenderC;
QueuedAMSenderM.SubSend -> AMSenderC;
QueuedAMSenderM.SendQueue -> QueueC;
}
Phil
Hi Phil,
Thanks for the input ! I will probably ( like 99.99% ) follow that
approach, but given that QueuedAMSenderM, is equal for every body, and
it doesn't depend on any parameters
should it be non generic, i.e., a normal module, maybe using
parameterized interfaces to tell the clients appart ? Would this work ?
generic configuration QueuedAMSenderC(am_id_t id, uint8_t size) {
provides QueuedAMSend;
provides Packet;
provides AMPacket;
}
implementation {
enum{
id = unique("queuedSend.client");
}
components new QueuedAMSenderM, new AMSenderC(id), new
QueueC(message_t*, size);
QueuedAMSend -> QueuedAMSenderM[id]; // This a realtive certain that
works
Packet -> AMSenderC;
AMPacket -> AMSenderC;
QueuedAMSenderM.SubSend[id] -> AMSenderC; // This not that sure
QueuedAMSenderM.SendQueue[id] -> QueueC; // dido
}
Thanks, Filipe
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
