The radio using the 32khz clock for MAC backoff timing. If you change it behind the scenes to 4khz, the radio will at best act differently and at worst outright misbehave.
Handling an overflow every two seconds isn't a big deal. The microcontroller wakes up in less than a microsecond. I don't know how long it takes to process the overflow interrupt in the timer, but let's say in the worst case it takes a millisecond -- or overall about a 0.05% overhead. There are bigger things to worry about, like removing second long tasks that block all other system behaviors... such as receiving messages and processing timers for other components. Cory On 2/6/06, Matt Thompson <[EMAIL PROTECTED]> wrote: > It is too bad TinyOS doesn't context switch between tasks ;) > > About the modifications to TimerB's divisor, it breaks DCO calibration > unless you change the TARGET_DELTA from 2048 to 256 in MSP430DCOCalibM.nc. > > With this configuration, I can use the Timer module properly with long > operations (ECDSA), and have yet to see any issues with peripherals (CC2420, > STM25 flash, UART, external iButton). > > Why would we want the extra interrupt load of the timer overflowing every 2 > seconds? Would that not also mean that it has to wake up from LPM every 2 > seconds to process the interrupt (I have yet to look into LPM at all..so I'm > completely unsure of its operation). > > Cheers, > Matt > > > Prabal Dutta wrote: > Matt, > > ECDSA is a pretty long running operation and we've seen similar > problems with other algorithms like RSA and FFT that can have long > running times. You best bet for getting it to work in TinyOS without > screwing with the task queues or other internals is to write your > algorithm so it operates in multiple phases, with each phase short > enough to avoid overflowing the timer. The easiest way to do this, > like the referenced thread states, is to iterate through long loops in > pieces. You should avoid the temptation to break the system model > (short tasks) even if you can get it to work in a particular case. > The reason is that the rest of the system is built on top of that > assumption and you risk causing unintended side effects. > > - Prabal > > On 2/6/06, Matt Thompson <[EMAIL PROTECTED]> wrote: > > > Are there any inherent problems with setting the TimerB divisor to 8 in > MSP430ClockM.nc (by adding ID_DIV8 in > MSP430ClockInit.defaultInitTimerB()), and changing > "milli*32" to "milli*4" in TimerM.nc? > > This should make TimerB work at 4khz, overflowing the 16bit counter approx > every 16 seconds. > > Cheers, > Matt > > > Cory Sharp wrote: > On 2/5/06, Michael Schippling <[EMAIL PROTECTED]> wrote: > > > > Oh, now here is an interesting bit of trivia.... > > TimerC overflows a 16bit > > > count every 2 sec. > > But the interface has a resolution of 1ms, > and there has > > > been talk about what the max > > timeout when using the i/f is? > > > > For the MSP430 in tinyos-1.x, the max timeout is something like 2^26 > > or 2^27 > > > milliseconds -- about 18 hours. > > > > > And the lack of wiring vs not including in > > the config file...hmmm? Is the > > > Timer always > > started in StdControl.init() even if not used? > > > > TimerM.nc is wired to a counter overflow interrupt in the MSP430, > > which is > > > handled regardless of StdControl. > > > > > I've probably missed a really important piece > > of documentation...Can you > > > elucidate a bit? > > thx > MS > > > Cory Sharp wrote: > > > > None of the drivers in TinyOS are written to be able to sustain a > task > > taking long seconds or more to complete. Blocking the task queue for > a > > > long time is bad. Read the discussion pointed to my Michael. You > > must split > > > your long task into multiple tasks, each task incrementally > > doing more > > > processing. > > For the MSP430 TimerC in particlar, every two seconds, for > > > each > > overflow of a 32khz 16-bit counter, a task is posted to process > > > that > > overflow. The current overflow MUST be processed before the > > > next > > overflow occurs. > > For a healthy, reactive system, I recommend no one > > > task take longer > > than, say, tens of milliseconds to complete. > > Cory > > On > > > 2/5/06, Matt Thompson <[EMAIL PROTECTED]> wrote: > > > > Hi, > > It appears that TimerC is filling the task queue while a long task > > > is > > running (ie Elliptic Curve DSA signature verification). After the > > > ECDSA > > task completes, the telosb is unable to process any more tasks. > > > Is > > there a way to stop the timer from posting tasks before a long > > > operation > > is started? It seems that even if I do not start the timer (and it > > > is > > not wired to StdControl), the task queue still fills up. I have > > > to > > completely remove it from the configuration for this behaviour to > > > disappear. > > Why does the mote not continue to process the task queue after > > > the long > > task completes, and then allow me to post more tasks when some of > > > them > > have completed? > > Has anyone else expereienced similar > > > behaviour? > > Cheers, > Matt > _______________________________________________ > 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 > > > _______________________________________________ > 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
