hi janos,
i validated this code, which came from an old (OLD) mspgcc post, on a
scope, toggling a pin and measuring the duration.
doing it again now, with the stock 4mhz clock, a nominal 100us wait
takes 100.7us. pretty reasonable. at 8mhz, i see 105.1us.
with your code, we have a delay of 97.5us at 4mhz, and 50.85us at 8mhz
because it doesn't know the clock has sped up!
point is, it's a wash, but i have two clocks to support, so the current
plan must stay in place.
-steve
On 03/08/2011 03:03 PM, Janos Sallai wrote:
> 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<a...@handhelds.org> 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<a...@handhelds.org> 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
>>>>> tinyos-de...@millennium.berkeley.edu
>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>> _______________________________________________
>>>> Tinyos-devel mailing list
>>>> tinyos-de...@millennium.berkeley.edu
>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> tinyos-de...@millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
