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:[email protected]] > 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 <[email protected] > > 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: [email protected] > [mailto:[email protected] > ] 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 _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
