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

Reply via email to