Steve: I'm not sure that the two pieces of code are equivalent. In my case, there's also a nop within the loop. Without that, I the delay I got were less than a microsecond (on the telos, at least). Have you verified the timing of your code against a counter driven by the SMCLK?
Janos On Tue, Mar 8, 2011 at 12:42 PM, steve ayer <[email protected]> wrote: > hi steve, > > it's telling that your replacement is essentially what we've been using > for years: > > void brief_pause(register unsigned int n) > { > asm volatile( "1: \n\t" > "dec %0 \n\t" > "jne 1b\n\t" > : "+r" (n)); > } > > #define TOSH_uwait(n) brief_pause((((unsigned long long)n) * > TARGET_DCO_KHZ * 1024 / 1000000 - 2) / 3) > > again, note the dependence on TARGET_DCO_KHZ, but that's not the only > thing in the tree. > > anyone else have any suggestions? > > thanks, > > steve > > On 03/08/2011 01:23 PM, Stephen Dawson-Haggerty wrote: >> We (Janos and I) also noticed that BusyWaitMicro isn't great -- it >> came up when I was trying to figure out why the ds2401 driver isn't >> very reliable/portable, since a different version with hand-coded busy >> loops works fine. >> >> Janos wrote this replacement that fixes the ds2401 driver, but we >> haven't committed it because of the potential to break things. It >> appears the at45db is the only other code in the tree using >> BusyWaitMicro and that still works for me with this version. >> >> No option on the other points; seems like the right thing to do about >> #1 though is to fix busywait. >> >> Steve >> >> On Tue, Mar 8, 2011 at 5:18 AM, steve ayer<[email protected]> wrote: >>> hello! >>> >>> i am the "offender" of public record. >>> >>> 1) our migration to tos-2.x initially used busywait until we noticed >>> some weird behavior. putting it on the scope, we observed that it was >>> inaccurate, iirc as much as 50% (slow) in some cases. as the tep >>> states: "BusyWait blocks for no less than the specified amount of time. >>> No explicit upper bound is imposed on the enacted delay, though it is >>> expected that the underlying implementation spins in a busy loop until >>> the specified amount of time has elapsed." >>> >>> shucks. especially when balancing the necessities of hardware specs and >>> application demands on the scheduler, close only counts in horseshoes. >>> so for pragmatic reasons, we're sticking with tosh_uwait, because it >>> works exactly as expected. >>> >>> 2) some of our platforms use an 8mhz crystal; applications that use it >>> and fail to set TARGET_DCO_KHZ to 8192 will be broken. >>> >>> 3) the separate copy for span was an oversight, and mike healy just >>> discovered it last week. i immediately changed it to point to the >>> single copy in shimmer/chips/msp430. oops. >>> >>> 4) our intention to not stay with a single variant of the msp430 will >>> track in architecture of upcoming platforms' code. it is our full >>> intention to align with and use as much mainline tos code as possible, >>> but not to sacrifice platform capabilities in the process (e.g., i >>> cannot for the life of me make the tos-2.x msp430 i2c code work properly). >>> >>> 5) the notion of shimmer* having a separate version of msp430hardware.h >>> is sub-optimal for who? if anything, it places a burden on me alone. >>> want me to change the name? >>> >>> -steve >>> >>> On 03/07/2011 08:57 PM, Eric Decker wrote: >>>> Greetings, >>>> >>>> For various reasons, I am integrating the 3 main msp430 cpu groups. >>>> Mostly because it is time and I need the x2 and x5 >>>> processors. >>>> >>>> For ease of communications.... >>>> >>>> x1 -> msp430f149, msp430f1611 (eyes, shimmer, span, telos{a,b}) >>>> x2 -> msp430f261{6,7,8,9} (msp430f2618) (z1, mm4) >>>> x5 -> cc430f5137, msp430f5438a (surf, mm5) >>>> >>>> In the course of this work I ran into duplicate copies of the >>>> msp430hardware.h file which seems to be sub-optimal. >>>> The span and shimmer motes are the offenders. Shimmer has been updated >>>> to include the new stuff that is in >>>> the main msp430hardware.h. But Span currently doesn't compile because >>>> of its private copy of msp430hardware.h >>>> >>>> Things that are in the private copies include: >>>> >>>> * pulls in Msp430DcoSpec.h >>>> * TOSH_wait >>>> * TOSH_wait_250ns >>>> * TOSH_uwait >>>> >>>> >>>> I would like the Span and Shimmer folks to work with me to figure out >>>> the right way to fix this. Should they >>>> migrate to the BusyWait interface? >>>> >>>> >>>> thoughts? >>>> >>>> eric >>>> >>>> -- >>>> Eric B. Decker >>>> Senior (over 50 :-) Researcher >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Tinyos-devel mailing list >>>> [email protected] >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel >>> _______________________________________________ >>> Tinyos-devel mailing list >>> [email protected] >>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel >>> >> >> >> > _______________________________________________ > Tinyos-devel mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
