Cory, thank you! I'm reminded of that old saying "always ask why before you ask how". Bit again...
Shanza, now you see the *real* reason I put this back on the list. ;^) On Thursday 10 May 2007 11:56, Cory Sharp wrote: > 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 > > > > _______________________________________________ > > Tinyos-help mailing list > > [email protected] > > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > !DSPAM:4643623b78461824015086! _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
