[Tinyos-help] atomic sections in HplMsp430GpioC and BusyWaitMicroC

[Philip Levis]

On Mar 26, 2009, at 6:56 AM, Michiel Konstapel wrote:

> You might wanna try looking at the generated C code (build/$PLATFORM/ 
> app.c) or dig deeper and look at the binary with a disassember  
> (msp430-objdump) to see where your CPU cycles are going.
>
> From: Jacob Sorber [mailto:jacob.sorber at gmail.com]
> Sent: donderdag 26 maart 2009 14:55
> To: Michiel Konstapel
> Cc: Tinyos-Help Help
> Subject: Re: [Tinyos-help] atomic sections in HplMsp430GpioC and  
> BusyWaitMicroC
>
> I tried wrapping the sequence, but the improvement is very small.  I  
> haven't dug into the bowels of tinyos to figure out exactly what is  
> going on, but it seems that "collapsing" atomic sections, still  
> incurs most of the overhead.
>
> Jacob
> On Thu, Mar 26, 2009 at 9:14 AM, Michiel Konstapel <m.konstapel at sownet.nl 
> > wrote:
> If you wrap the whole sequence in an atomic block, it'll be  
> collapsed into a single atomic section. That should lower the total  
> time significantly, but you'll have one larger time window in which  
> interrupts won't be processed, instead of several short ones. I  
> don't know if that'll cause problems elsewhere (but it seems to work  
> fine for my software SPI code).
>
> Michiel
>
>
>
> From: tinyos-help-bounces at millennium.berkeley.edu [mailto:tinyos-help-bounces at millennium.berkeley.edu 
> ] On Behalf Of Jacob Sorber
> Sent: woensdag 25 maart 2009 21:58
> To: Tinyos-Help Help
> Subject: [Tinyos-help] atomic sections in HplMsp430GpioC and  
> BusyWaitMicroC
>
>
>
> I'm porting a driver for a OneWire bus from tinyos 1.x over to  
> tinyos 2.1 and I'm having some trouble with delays introduced by  
> atomic sections around every clr/set/makeinput/makeoutput.  Making  
> these calls atomic is costing me around 10us per call.  The  
> BusyWaitMicroC component basically does the same thing.  So  
> basically this sequence...
>
>
> call GeneralIO.makeOutput();
> call GeneralIO.clr();
> call BusyWait.wait(5);
> call GeneralIO.makeInput();
> call BusyWait.wait(5);
>
> ...takes 50-100us instead of 10-15us.  I can fix this by removing  
> the atomic sections, but I'm a little worried that I'm going to  
> break something else.  Is there a "proper" way to do this?  I could  
> just make an "non-atomic" version of these components and wrap them  
> in larger atomic sections, but I would rather not if someone has  
> solved this problem already.
>

This is correct; nesC elides nested atomic sections (when it can).

I agree: I'd look at the app.c/assembly to see what's going on.

Phil