[Tinyos-devel] problem of using FTSP and CTP

[Miklos Maroti]

Phil,

On Mon, Mar 23, 2009 at 6:26 AM, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Mar 22, 2009, at 9:05 PM, Janos Sallai wrote:
>
>> On Sun, Mar 22, 2009 at 7:42 PM, Philip Levis <pal at cs.stanford.edu> wrote:
>>>
>>> It was a bug in FTSP to wire directly to ActiveMessageC; Brano fixed
>>> it, correct?
>>
>> No, you can't do that, because AMSender does not provide the
>> TimeSyncAMSend interface.
>
> So shouldn't there be a TimeSyncAMSenderC?

Here is the problem with the TimeSyncAMSenderC implementation: you
have to use the same AMQueueImplP.nc module to share the same message
buffer to store the pending messages, otherwise the no EBUSY semantics
will not work. However, for certain AM types you need to call the
AMSend interface of ActiveMessageC or the TimeSyncAMSend interface of
TimeSyncActiveMessageC. First you do not know which one to call and on
top of that you need the extra event time parameter for the time sync
message. Where do you store that event time? The
TimeSyncActiveMessageC is platform dependent, so it is harder to break
it apart.

There are other problems. There can be several reasons why a MAC layer
may return EBUSY when it cannot temporary send a message, one of them
is that it is currently sending another message, but there are others:
for example while changing to another channel, or the PLL gets
unsynchronized (yes, it does happens) but is expected to work shortly.
There are also other factors, if for example you allow 6LOWPAN
components or any other alternative stack. You CANNOT funnel
everything everything through the AMSenderC component.

You might solve the TimeSyncActiveMessageC and SenderC problem, but
fundamentally the problem is with AMSenderC not handling the EBUSY
condition. You MUST be prepared for an EBUSY from the ActiveMessageC
and you MUST deal with that in AMSenderC, and that is a rather simple
change!

Miklos