tossim execution requires actual mote for execution of the program

On Thu, Mar 26, 2015 at 12:30 AM, <
[email protected]> wrote:

> Send Tinyos-help mailing list submissions to
>         [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> or, via email, send a message with subject or body 'help' to
>         [email protected]
>
> You can reach the person managing the list at
>         [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tinyos-help digest..."
>
>
> Today's Topics:
>
>    1. Workaround for Timer bug ( IRIS modules) (Roadstar Runner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 25 Mar 2015 00:46:58 -0400
> From: Roadstar Runner <[email protected]>
> Subject: [Tinyos-help] Workaround for Timer bug ( IRIS modules)
> To: tinyos forum <[email protected]>, Miklos Maroti
>         <[email protected]>,    Janos Sallai <[email protected]>,
> Eric
>         Decker <[email protected]>
> Message-ID:
>         <
> can3ao+wg18yqirvfdzaihbx8co9x77m8cz+edd5e-4pa388...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I recently cam across a possible bug in the Timer module for the IRIS
> motes. I occasionally noticed that the timer would fire very late thus
> causing a whole series of cascading failures in my modules.
>
> After days of debugging, I traced the problem to the routine setInterrupt()
> in the  module Atm1281AlarmAsyncP.
> If the alarm is armed to fire after 1 TCNT tick, in some situations OCR2A
> will be loaded with a value that will essentially be in the "past",  thus
> requiring TCNT2 to wrap around for the compare to occur (about 255 ms
> late).
> Since TCNT2 is a free running timer, if TCNT2 increments after the current
> time is captured by the call to Counter.get(), the *fired *flag will not be
> set, even though the alarm has technically expired. After this, under some
> circumstances, the compare register can be loaded with a wrong value.
> Consider the following situation when setInterrupt() is called
>
>
> to = 24
> dt = 1
> TCNT2 =1
> base = 23
>
> now if TCNT increments (TCNT2 = 2)  after the current  time is captured
>   uint32_t now = call Counter.get();
>
> Then the following condition will fail
>  /* Check if alarm expired */
>    if ((uint32_t)(now - t0) >= dt)
> The following variables will be updated as indicated below, to compute
>  anew value for OCCR2A
> alarm_in = 2
> newOcr2A = 1
>
> Since newOcr2A   =1  and TCNT2 =2 , When OCCR2A is loaded, it will delay
> the next alarm by 255 ms.
>
> As a quick workaround, i added the following code to force the timers to
> fire after calling setOcr2A(newOcr2A);
>
> //work around
> if(newOcr2A >= TCNT)
> {
> diff =  newOcr2A - TCNT   ;
> }
> else
> {
> diff =  (0xFF - TCNT) + newOcr2A ;
> }
> if( diff   > MAXT)
> {
> fired = TRUE;
> }
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://www.millennium.berkeley.edu/pipermail/tinyos-help/attachments/20150325/ca091374/attachment-0001.htm
>
> ------------------------------
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> End of Tinyos-help Digest, Vol 143, Issue 10
> ********************************************
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to