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