what you are running into is the order the files are scanned.
If you do the .h business then you include that and it doesn't matter
because your
include file is protected against being included twice.
On Mon, Jun 21, 2010 at 12:22 PM, Michael Schippling <sc...@santafe.edu>wrote:
> 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
>> <sc...@santafe.edu<mailto:
>> sc...@santafe.edu>> 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.
>>
>>
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
_______________________________________________
Tinyos-help mailing list
Tinyos-help@millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
