Quick answer: If you need timing resolution on the order of ones of
milliseconds, you should be using a hardware timer in TOS1 or an Alarm in
TOS2. Also note, for Telos/Tmote the <3 check is in 32khz units, not 1khz
units.
Response to the "odd comment": Atomic sections cannot prevent the issue
because it is a problem with real time, not interrupts. In an atomic
section, timer counters still count. If time elapses from when the alarm
was calculated to when it is set, then short alarms will misbehave (like
"now"+1). Down inside the timer drivers, you can put that last part in an
atomic section and only be limited by the MCU MIPS, hence the "<3 units"
check. On the other hand, application code is interruptable, so much more
time may elapse than 3 "units". The TOS2 timer and alarm commands of the
form set(t0,dt) address this specific issue at the application layer.
A final aside: The other way to address that application-level uncertainty
is to use a large enough timer width that you can assume it never overflows
-- 64-bit (probably in nanoseconds). But, we decided pervasive 64-bit
timers was too much overhead for TinyOS.
Cory
On 1/22/07, Michael Schippling <[EMAIL PROTECTED]> wrote:
Ok, I'm Beginning to See the Light here...
I was using TOS1.7 to make my robots on mica2's and a 1ms interval
setting worked just great. But then I tried the code on micaz
(and had to upgrade to 1.10 to do so) and there indeedy is the
if( ... interval <= 2 ) no-go;
So I gave up and stuck like glue to .7 and '2's.
The unfortunate fact is that it did work before (in some cases) and
was then (silently?) eliminated. The comment relevant to the limit
is kind of odd:
// The problem is due to the possibility that the hardware clock
// could increment while setting the compare value,
Seems like, first, it did work, and second, isn't that what atomic
and all the other interrupt control stuff is for?
Did anybody characterize the conditions where < 3 didn't work?
Is this still the case in T2?
MS
David Moss wrote:
> There are timing problems when a timer is below 4 ms - I believe it was
> due to the microcontroller not being able to keep up with executing code
> that quickly. If you look at the code that gets executed when you call
> Timer.start(..), one of the first tests is to make sure you're not
> trying to start a repeating timer that is at or below 3 ms.
> -David
>
>
> On Thu, 18 Jan 2007 10:46:51 +0800
> "Zhang Yan" <[EMAIL PROTECTED]> wrote:
>>
>> I am using Tinyos-1.x with a MicaZ mote and trying to do some work at
>> high rates. But when I use the TimerC, it seems that the timer
>> couldn't work when the interval is below 4 milli second. It means that
>> when I use codes as follows,
>> command result_t StdControl.start() {
>> // Start a repeating timer that fires every 1000ms
>> return call Timer.start(TIMER_REPEAT, 1);
>> }
>>
>>
>> Then the timer didn't work. The event of Timer.fired() couldn't be
>> triggered. So why this happen? Is it because the precision of the
>> timer of micaz? Thanks a lot.
>>
>>
>> Regards,
>> Zhang Yan
>> [EMAIL PROTECTED]
>> 2007-01-18
>>
>> _______________________________________________
>> Tinyos-help mailing list
>> Tinyos-help@Millennium.Berkeley.EDU
>>
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>
> _______________________________________________
> Tinyos-help mailing list
> Tinyos-help@Millennium.Berkeley.EDU
>
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
