Stephen Dawson-Haggerty wrote:
> The issue is that micaz's only have 4k of RAM; if you have allocate too much
> static memory, it may still compile because you've used slightly less then
> 4k, but then some of the data structures near the top of the address space
> get clobbered by the stack when it runs. Anyhow, those numbers sound about
> right; there's no way to receive a max-mtu (1280 bytes) message on a micaz.
>
Steve, thanks for reply!
Hope, the Team from Vanderbilt Uni could provide soon the adaptation for
IRIS and 8Kb RAM will be enough.
Best wishes,
Andrey
>
> On Fri, Sep 26, 2008 at 8:21 AM, Andrey Gursky <[EMAIL PROTECTED]>wrote:
>
>> Stephen Dawson-Haggerty wrote:
>>> Hmm, you're right. The only thing it's being used for is the uptime
>>> counter, so it would be easy enough to comment out. I'll try to switch
>>> it to a different timer though.
>>>
>> Thanks Steve! I (and and it seems some others) are looking forward :)
>>
>>> You may also need to reduce the memory used somewhat to get the new
>>> release to fit into 4k; I've sucessfully used the new stack on micaz,
>>> but only by saving a little ram. You can decrease the size of the
>>> fragment pool at the bottom of 6lowpan.h, or else cut down the heap.
>>> Receiving max-mtu packets (1280 bytes) is barely possible on a micaz...
>>>
>> Sorry for the delay with a feedback!
>> I've tried some values in 6lowpan.h and tested with echotest.pl, where
>> I've changed the random getting of length to fixed. Here are the results:
>>
>> enum {
>> // IP_NUMBER_FRAGMENTS = 10, //orig -> doesn't work at all!
>> IP_NUMBER_FRAGMENTS = 9, // -> max length of message = 738
>> // IP_NUMBER_FRAGMENTS = 8, // -> max length of message = 642
>> // IP_NUMBER_FRAGMENTS = 5, // -> max length of message = 354
>> }
>>
>> Could it maybe achieved more? Are there tools to check this?
>>
>> And the strange thing with 10 fragments, because python Listener.py
>> doesn't receive UPD reports at all and ping have no successes. I
>> understand that too big message can't be used but the report should come
>> always or I'm missing something?
>>
>> Thanks,
>> Andrey
>>
>>
>>> From: Andrey Gursky <[EMAIL PROTECTED]
>>> <mailto:[EMAIL PROTECTED]>>
>>> Date: Tue, Sep 2, 2008 at 5:01 AM
>>> Subject: [Tinyos-help] b6lowpan: update from August, 25 doesn't work
>>> anymore with micaz
>>> To: [email protected]
>>> <mailto:[email protected]>
>>>
>>>
>>> Hi!
>>>
>>> After update UDPEcho doesn't compile.
>>>
>>> ---------------------------------------------------------
>>> In file included from UDPEchoC.nc:50:
>>> In component `UDPShellC':
>>> UDPShellC.nc:46: component CounterMilli32C not found
>>> UDPShellC.nc:47: no match
>>> make: *** [exe0] Error 1
>>> ---------------------------------------------------------
>>>
>>> Is there any 32-bit(?) counter for Atm128 (micaz) that one could use
>> in
>>> place of one for msp430? Or is there any obviously way to exchange
>> this
>>> peace of code, someone could see better?
>>>
>>>
>>> Thanks,
>>> Andrey
>>>
>>>
>>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help