I mean wiring to GenericComm is same as wiring to SPC, from the code
reading. (which is different than you said in previous email). Am I right?

Anyway, thanks a lot.

>>(1) if you are using the "old" interfaces (ie, SendMsg and ReceiveMsg),
then >> you should wired to GenericComm, not SPC.
>> Unfortunately the nesC wiring checks aren't completely functional. 




-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Joe Polastre
Sent: Monday, May 22, 2006 4:55 PM
To: Adam
Cc: [email protected]
Subject: Re: [Tinyos-help] Re: Confusion on uncombined call and
SPCcomponent/interface - still comiple warnings

Sure it does, GenericComm is for backwards compatibility as the
documentation says.

-Joe

On 5/22/06, Adam <[EMAIL PROTECTED]> wrote:
> Thanks. You are right, I did not expect MULTIHOP uses same ID as SURGECMD.
>
> But I still have confusion, I re-read GenericComm in SP directory, 
> where the SendMsg is actually connected to SPC.SendMsg ... It does not 
> match with your previous email.
>
> ==================================================
> configuration GenericComm
> {
>   provides {
>     // for backwards compatibility
>     interface StdControl as Control;
>
>     // The interface are as parameterised by the active message id
>     interface SendMsg[uint8_t id];
>     interface ReceiveMsg[uint8_t id];
>   }
> }
> implementation
> {
>   // CRCPacket should be multiply instantiable. As it is, I have to use
>   // RadioCRCPacket for the radio, and UARTNoCRCPacket for the UART to
>   // avoid conflicting components of CRCPacket.
>   components SPC;
>   components NullStdControl;
>
>   // This wrapper doesn't allow the user to start/stop the radio
>   // instead, they must use the interfaces provided by SP
>   Control = NullStdControl;
>
>   // Wrappers for the send and receive functions for backwards
compatibility
>   SendMsg = SPC.SendMsg;
>   ReceiveMsg = SPC.ReceiveMsg;
>
> }
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
> Of Joe Polastre
> Sent: Monday, May 22, 2006 4:47 PM
> To: Adam
> Cc: [email protected]
> Subject: Re: [Tinyos-help] Re: Confusion on uncombined call and 
> SPCcomponent/interface - still comiple warnings
>
> You still have more than 1 component wiring to the same AM id.  Please 
> check your app.
>
> -Joe
>
> On 5/22/06, Adam <[EMAIL PROTECTED]> wrote:
> > Following Joe's suggestion, I changed to
> >
> > Components GenericComm as Comm;
> >   // receive/process/send control message
> >   Impl.SendCtrlMsg -> Comm.SendMsg[AM_OASISCMDMSG];
> >   Impl.RecvCtrlMsg -> Comm.ReceiveMsg[AM_OASISCMDMSG];
> >
> > I used "make tmote fielset" to verify I indeed used 
> > /opt/moteiv/tos/lib/sp/GenericComm.nc
> >
> > However, I still got that warning message:
> > "nesc1: warning: calls to ReceiveMsg.receive in SPM fan out, but 
> > there is no combine function specified for the return type"
> >
> > How to solve this? Thanks.
> >
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of 
> > David Gay
> > Sent: Monday, May 22, 2006 2:03 PM
> > To: [email protected]
> > Subject: Re: [Tinyos-help] Re: Confusion on uncombined call and 
> > SPCcomponent/interface
> >
> > On 5/22/06, Joe Polastre <[EMAIL PROTECTED]> wrote:
> > > correct. they are not actually verified during compilation.
> >
> > They are verified by an external tool, invoked automatically during 
> > the build process. This is intentional, and will not change. But I 
> > can easily believe there's a bug in the external tool (nescc-wiring, 
> > bug reports welcome...).
> >
> > David
> >
> > _______________________________________________
> > Tinyos-help mailing list
> > [email protected]
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos
> > -h
> > elp
> >
> > _______________________________________________
> > Tinyos-help mailing list
> > [email protected]
> > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos
> > -h
> > elp
> >
>

_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to