Felipe:

If you run make with the cc2420x extra, then the rfxlink based radio
stack gets compiled in, which supports microsecond-precision
timestamping. Specifically,
tos/platforms/telosa/chips/cc2420x/tmicro/am/ActiveMessageC.nc gets
compiled in instead of tos/platforms/telosa/ActiveMessageC.nc. See the
readme at tos/platforms/telosa/chips/cc2420x/README.txt for details.

Use LocalTimeMicroC to get the microsecond-precision local time.

On Tue, Aug 28, 2012 at 12:45 PM, Felipe Cousin
<[email protected]> wrote:
> Hi all,
>
> We need to get the timestamp of received packets in microseconds, but I
> couldn't find any component that provides the interface
> PacketTimeStamp<TMicro,uint32_t> for telosb
> and also we would like a Counter<TMicro,uint32_t> and, again, I couldn't
> find any component that provides that interface for telosb...
>
> Does anybody knows a component that does that or have some suggestion ?
>
> Thanks,
> Felipe
>
>
>
> ________________________________
> Date: Tue, 28 Aug 2012 00:52:29 -0700
> From: [email protected]
> To: [email protected]
> CC: [email protected]
> Subject: Re: [Tinyos-help] questions about usage of keyword atomic
>
>
>
> On Mon, Aug 27, 2012 at 6:59 PM, Xiaohui Liu <[email protected]> wrote:
>
> Hello all,
>
> 1) I have the following code snippet:
> uint8_t a;
>
> async event void Alarm1.fired() {
>    a = 0;
> }
>
> This compiles successfully without any warning.
>
>
>
> Isn't there a racing condition here, between Alarm1 and itself?
>
>
> I don't know what you mean by the above.   How can Alarm1 have a race
> condition with itself?
>
> Looks to me like in the above program there is only one place where a is
> accessed, so how can there be a race condition.
>
>
>
> 2) If the following is added.
> async event void Alarm2.fired() {
>    a = 1;
> }
> Still, this compiles successfully without any warning. Isn't there an
> additional racing condition here, between Alarm1 and Alarm2 (and Alarm2 and
> itself)?
>
>
> async is considered to be one level of execution.   So there still isn't a
> race condition.   When Alarm1 fires, a gets set to 0.   Alarm2 can not get
> in and thus there is not a race condition.
>
> this is a nesc assumption.   That async is one level of execution  (one
> context).
>
>
>
> 3) If the following is added.
> event void Timer.fired() {
>   a = 2;
> }
> Then there is a warning, "non-atomic accesses to shared variable `a'". Why
> is there no warning for
> a = 0;
> in Alarm1?
>
>
> Why do you expect a warning from Alarm1?
>
> Timer.fired is at sync level.   Sync level is the other nesc execution
> context.   Because there is access to a from the async level nesc beleives
> that there is a potential race condition between the Alarms (async level)
> and Timer.fired (sync level).   Hence non-atomic accesses.
>
>
>
> According to the TinyOS book P196, a variable has to be protected by an
> atomic statement "if it is accessed from an async function". But seems to
> me, "a" is accessed from an async function in all 3 cases above and none is
> protected except
> a = 0;
> in Timer.
>
>
> The book isn't very clear.
>
> Typically async level is used for functions called from interrupt level
> signals.
>
>
>
> Can anybody please share the experience on atomic? Thanks in advance.
>
> --
> -Xiaohui Liu
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
>
>
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
>
>
>
> _______________________________________________ Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> _______________________________________________
> Tinyos-help mailing list
> [email protected]
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to