ps...in the original code, you probably don't really need the atomics
(or the intermediate "tb" because the "blocking" value is a single
byte and the test is only going one way, which is (I think, under
all conditions) going to be reliably TRUE or FALSE from instruction
to instruction...
Correct
Wow! volatile...and cogent descriptions of TOS tasks and Spin Lock usage...
You guys are gods!
MS
ps...in the original code, you probably don't really need the atomics
(or the intermediate "tb" because the "blocking" value is a single
byte and the test is only going one way, which is (I think, u
On Thursday 07 December 2006 03:10 pm, Philip Levis wrote:
> On Dec 7, 2006, at 12:51 PM, R. Steve McKown wrote:
> > I think in general the need/desire for a spin lock or other similar
> > continue-to-test strategies suggest that some of the best benefits
> > of TinyOS
> > aren't being fully exploi
On Dec 7, 2006, at 12:51 PM, R. Steve McKown wrote:
I think in general the need/desire for a spin lock or other similar
continue-to-test strategies suggest that some of the best benefits
of TinyOS
aren't being fully exploited. Granted, it can mean the
organization of your
code is trickier
On Thursday 07 December 2006 01:04 pm, Jeff King wrote:
> The problem is in my app:
>
> bool blocking;
>
> event void Boot.booted() {
>bool tb = TRUE;
>call MyDebugger.write("Booting, Part 1\r\n");
>while (tb) {
> atomic {
>tb = blocking;
> }
>}
>call MyDebugge
On Dec 7, 2006, at 12:04 PM, Jeff King wrote:
The while loop in Boot.booted() doesn't seem to pick up that the
global variable 'blocking' has changed.
Any clue as to why the app can't print the "Booting, Part 2" line?
I'm not a 100% expert on C (David), but perhaps you need a volatile?
A
Hello,
I'm having a problem getting some code to work, where the application
prints a message to the serial port, blocks while the uart transmits
data, then prints another message. I don't know whether I'm
misunderstanding the execution order or the use of atomic sections, but
here's the scen
