[Tinyos-devel] cc2420 radio stack and deputy

[Vlado Handziski]

The sentence was left unfinished.

Deputy issues the following warnings for the RadioCountToLeds:

/home/hanjo/tos/tinyos-2.x/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning:
#warning "*** LOW POWER COMMUNICATIONS DISABLED ***"
/home/hanjo/tos/tinyos-2.x/tos/lib/timer/TransformCounterC.nc: In function
`TransformCounterC$0$Counter$get':
/home/hanjo/tos/tinyos-2.x/tos/lib/timer/TransformCounterC.nc:90: warning:
left shift count >= width of type
/home/hanjo/tos/tinyos-2.x/tos/lib/timer/TransformCounterC.nc: In function
`TransformCounterC$1$Counter$get':
/home/hanjo/tos/tinyos-2.x/tos/lib/timer/TransformCounterC.nc:70: warning:
`rv' might be used uninitialized in this function

and the installed binary results in erratic blinking on the two nodes.

Vlado

On Mon, Jun 23, 2008 at 23:54, Vlado Handziski <handzisk at tkn.tu-berlin.de>
wrote:

> I am getting strange behavior from the apps when testing radio stack apps
> with deputy. My deputy version includes the original patches, but not this
> last one. I am not sure if this is the cause, but RadioCountToLeds for
> example (on shimmer and on telosb). Can anyone confirm this?
>
> Vlado
>
>
> On Mon, Jun 23, 2008 at 23:11, Philip Levis <pal at cs.stanford.edu> wrote:
>
>>
>> On Jun 23, 2008, at 1:48 PM, David Gay wrote:
>>
>> > On Fri, Jun 20, 2008 at 4:01 PM, David Gay <dgay42 at gmail.com> wrote:
>> >> - First, in CC2420TransmitP.nc, m_msg was used in a bunch of places
>> >> where it could be null (just after boot). I added the obvious if's to
>> >> deal with that.
>> >>
>> >> - Second, the lower-levels of the CC2420 radio stack were passing the
>> >> total packet length (well, the value of the packet's length byte
>> >> actually) as the payload length, which caused a runtime error for
>> >> packets where payload-size + header-size > max-payload size. As I
>> >> couldn't see any good reason why this was being done, I propose the
>> >> following patch which passes the correct payload length in
>> >> CC2420ReceiveP. There was also a symmetric misuse of the length in
>> >> the
>> >> send path (starting in CC2420ActiveMessageP), which this patch also
>> >> fixes:
>> >
>> > No objections?
>>
>> Seems like a good bug fix to check in. Please put it on the head, we
>> can then test it on rc3.
>>
>> Phil
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080623/3b7843e6/attachment.htm