My only good data point is using TOSH_uwait(10) in I2CM code. (I was disturbed to find that in T1 at least the I2C code bitbangs the protocol rather than setting up the uController correctly, and it was missing a wait-state detection).
On the missed deadline issue, the Timer would need to run its task every (binary)-milli-sec and would thus overrun if it was delayed. I wonder if faster timers have the same structure...I think the old TimerJiffy fires in interrupt context. But there might be other tasks that need near-real-time execution, maybe the radio? BTW, rather than me actually _reading_ the nescc doc... Does "sync" indicate a task level callback and "async" an interrupt level? Or is it More Complicated? thx MS Eric Decker wrote: > > > On Wed, May 5, 2010 at 9:35 AM, Michael Schippling <[email protected] > <mailto:[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] > <mailto:[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
