It's been discussed before, but it's worth mentioning again.
Timer.fired is synchronous, which means after the corresponding hardware
interrupt signals, the application fired events goes through the task
queue. That means an arbitrary number tasks and an arbitrary amount of code
may execute before any particular Timer.fired. Assuming most platforms are
around 1 MIPS, and that there may be hundreds or thousands of machine
instructions before the application Timer.fired is signaled, the uncertainty
in when you get that event is around 100us to 1ms, at least for this
hypothetical analysis. That means Timer<TMicro> is mostly meaningless, and
even Timer<T32khz> is dubious, and why Timer<TMilli> is the standard.
So, if you care about timing, use an Alarm, which derives directly from a
hardware interrupt and asynchronously fires without going through the task
queue. But again assume a 1 MIPS platform. Just servicing into the
interrupt handling code will likely take about 10 instructions. Also take
into account the largest atomic block in your code, which could be some more
tens of instructions. That means even for an async alarm, the jitter can be
upwards of 100us. So, here an Alarm<TMicro,uint16_t> is dubious and may
have to worry about the power state of the platform, and an
Alarm<T32khz,uint16_t> is standard.
If you just care about measuring time elapsed within one task, then a
Counter<TMicro,uint32_t> can make sense.
Cory
On 5/10/07, Steve McKown <[EMAIL PROTECTED]> wrote:
Hi Shanza,
I hope you don't mind me putting this discussion back to the list. Others
in
the future may benefit from our discussion.
On Thursday 10 May 2007 09:35, shanza khan wrote:
> Thank you but i am using Timer.fired().
I don't see a microsecond timer implemented for any tos2 platform. You
could
implement it by duplicating how the virtualized millisecond timer works.
TimerMilliC instances eventually wire to HilTimerMilliC, which is the
platform specific implementation. Watch out for side effects, like low
power
mode handling, conflicts with other components using hardware you need to
do
microsecond timing, etc.
> I found another interface named
> LocalTime being provided by CounterToLocalTimeC and i used LocalTime.get
()
> to get current time in microseconds. but when i compile my code i got an
> error that
>
> /opt/tinyos-2.x/tos/lib/timer/CounterToLocalTimeC.nc : in function '
> LocalTime.get':
> Counter.get not connected.
>
> Counter is the name of interface being used by the CounterToLocalTimeC
.Can
> u tell me why this error comes.
This error means that CounterToLocalTimeC is not wired to a provider of
the
Counter interface which it uses. In your app wiring, you need to wire
CounterToLocalTimeC to a component that provides the proper Counter
interface. I haven't tried it, but I think on msp430 platforms the wiring
would be:
components CounterToLocalTimeC(TMicro);
MyApp.LocalTime -> CounterToLocalTimeC;
components Msp430CounterMicroC;
CounterToLocalTime.Counter -> Msp430CounterMicroC;
I expect other platforms would work similarly.
All the best,
Steve
>
>
> thanks
>
> Shanza
>
> On 5/10/07, Steve McKown <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > On Wednesday 09 May 2007 20:52, shanza khan wrote:
> > > I want to get time for execting a function. So i want to used timer
> > > interface with TMicro can anybody tell me that which component i
should
> >
> > use
> >
> > > for it that provide timer interface with Tmicro.
> >
> > TinyOS 1.1.x or 2.x? What hardware platform?
> >
> > If you don't need Timer.fired() but are just measuring the distance
> > between
> > two events -- and you don't mind the measurement itself subtly
changing
> > the
> > timing -- a Counter interface is probably fine.
> >
> > Under TinyOS 2.x on an msp430 based platform, you can use
> > Msp430CounterMicroC,
> > which provides a Counter<TMicro, uint16_t> interface. On the mica
> > platform,
> > you can use CounterMicro32C, which provides a Counter<TMicro,
uint32_t>
> > interface.
> >
> > Steve
>
> !DSPAM:46433f0834272707813856!
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
