In re: creating real global variables under NESCC.
WOW! I think you've got it. Almost anyway...
I'm pretty sure I tried the (sort of obvious) method of
[declar,defin}ing a variable outside of the
module{}implementation{} block in a .nc file, ala:
includes RoboMsg;
static int foolish;
module MotionM
{
// ...
}
implementation
{
// ...
}
and in the user module:
includes RoboMsg;
extern int foolish;
module MotionM
{
// ...
}
implementation
{
foolish = 2;
// ...
}
But I tried it again anyway. And:
IT DOESN'T WORK
"syntax error before yadayada"
However. If I put both the static definition and the
extern declaration in header files and "includes" them
(just an aside which I'm sure is covered in some NESCC
document...but what the heck is "includes" and why is
the syntax different from our old friend "#include"?):
IT WORKS!
I had to create a separate header file for the static
definitions and "includes" it in only one .nc module,
but an examination of app.c and compile output indicates
that I have indeed created a global variable.
Now the question is: do I really care, since I have hacked
global passing into all my interface definitions and will
have to go de-hack them all once more...
wow!
thx!
MS
Eric Decker wrote:
>
>
> On Sat, Jun 19, 2010 at 6:36 AM, Michael Schippling <[email protected]
> <mailto:[email protected]>> wrote:
>
> Just because the code is shared, doesn't mean that the data memory
> is shared as well.
>
> Just a WAG on my part, but I would assume that TOSSIM runs each
> mote instance on a different stack and sets each instance's "global"
> memory area to different locations as well. In writing that last
> phrase it occurred to me that there must be some memory foo happening
> at compile time to make that happen...
>
> That said, I've had to jump through annoying hoops in order to share
> global state across multiple TOS modules due to NESC name mangling.
>
>
> Try pull the global out of the module {} implementation {} block. nesc
> only mangles names inside of a nesc block.
>
>
> I recently thought I might be able to do a real global variable in
> a C library and link the TOS program to it, but that's water under
> the bridge now.
>
> And there's nothing wrong with T1 that a few good kicks doesn't fix.
> Usually....
>
>
> I'm just saying it isn't where the majority of new effort is going. And
> it isn't officially supported any longer.
>
> I personally thing T2 is much better organized, structured. I've used
> both. T1 drove me nuts. Not that anyone could tell the difference.
>
>
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
