[Tinyos-devel] problem of using FTSP and CTP

[Miklos Maroti]

Guys,

On Sat, Mar 21, 2009 at 12:00 AM, Branislav Kusy <kusy at stanford.edu> wrote:
> there is a bug in CTP that causes CTP to hang forever, if any other
> component wires ActiveMessageC (rather than AMSenderC). described in this
> thread:
> http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-December/003513.html

Ok, I read that thread, and I think Phil's conclusion (and the comment
about subsendResult == EBUSY) is incorrect. I think the AMSend
interface can return EBUSY even if a prior send was not called (not
from this AMSend interface but from another one with a different am
type). This is exactly what happens when some other component uses
ActiveMessageC instead of the AMSenderC (which serializes access).

So CTP need to be fixed and handle the EBUSY case.

> FTSP is one such components, thus CTP will hang when used with FTSP. one
> option would be to write system/AMTimeSyncSenderC.nc component that provides
> the TimeSyncAMSend interface that FTSP needs. i don't like this solution as
> there start to be too many timesync related files that mirror the radio
> stack files. perhaps the timestamping code should be redesigned? fixing the
> CTP bug would also help ;)

It would be (probably) impossible to write your AMTimeSyncSenderC
component, since it has to use the TimeSyncActiveMessageC to send
messages. We cannot implement the TimeSync protocol as a mix-in
protocol (such as PacketLink) because on the receiver side we have
absolutely no information if we have received a message with an
embedded time sync data or not, since only a 32-bit value is appended
and no flag is set in the message body. The only information we have
is the AM type, so we rely on the user to wire components through the
TimeSyncActiveMessageC when needed.

(One solution would be to wire the TimeSyncActiveMessageC to AMSenderC
on the sender side, but I am not sure we want to do that).

Miklos