The TimerM code posts a task to do work. I don't remember if it's every tick or just when something needs to be executed. If that task is blocked and overruns you are probably scrod. 300uS might squeek through.
I did have trouble with (someone else's) code that busy-waited for a millisec. Symptom was unpredictable lapses in time sync using Tmote and Boomerang. The safe way to do your start() is with the two-phase SplitControl interface. It would be kinda nice to have a chart of what "system" level code does callbacks in interrupt and/or task mode. As I said in T1, TimerM.fired() is a task, but ACCC.dataReady() is in interrupt context. MS Eric Decker wrote: > I have a task that does some of the h/w initilization. The problem is > we turn this h/w off when not using it and later we need to reinitilize > it. The first part of the job take about 200-300 us. Is this too > long for the task? > > Are there any general guidelines that people have found from actual > experience about where this becomes a problem. > > I'm sure it is very application specific in that it of course depends on > whether something else really needs to run. > > -- > 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
