On Wed, May 5, 2010 at 9:35 AM, Michael Schippling <[email protected]>wrote:
> 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. I've been all through the timer code. I have a jtag and believe most strongly in single stepping through code to understand what is going on. The timer task gets posted anytime the code thinks there is a modification to the timer tables. A timer task also gets posted when a timer needs to be fired. That is why the timer signal is sync. > If that task is blocked and > overruns you are probably scrod. 300uS might squeek > through. > > The problem is when one starts to miss deadlines. One could then start getting a backlog of tasks that need to run and one wont catch up. But one probably has a broken system then anyway because there is too much work. But I'm wondering if folks have any empirical evidence of good guidelines on how long a task can run ball park. I'm very aware that it really depends on what the system (code that does something useful) needs to do and the code implimenting it. > 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 already is split phase. The entire initilization takes 52 mis (binary milliseconds). I've split things up already and the current start up takes about 200-300 uis. Then there is a section that runs in repeated busts of about 300uis. Hence my question. I'm wondering as I'm tweaking the code at what point have I hit the point of diminishing returns. How short a time do I need? eric > 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 >> > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
