On Tue, Jun 22, 2010 at 9:30 AM, Michael Schippling <[email protected]>wrote:

> Err. Uh...Wot?
>
> That second paragraph appears to have fairly standard English
> syntax and grammar but makes absolutely no sense to me.
> Are you using an auto-reply generator?
>

sorry, forgot to turn off the AI  :-)

The points I was trying to make are,
> A) yes, one can declare and use global variables;
> B) this has to be done in header files which are "includes";
> B) because "includes" seem to be processed in a different
> context than the surrounding .nc file;
>
> And I guess, D) I didn't find a simple way to re-use the header
> that declares the externs to also allocate the actual variables.
> I didn't try the simple route of not declaring them extern, is
> that what you meant by "your include file is protected against
> being included twice"?
>

#ifndef __HEADER_H__
#define __HEADER_H__
....




#endif   /* __HEADER_H__ */



>
> All part of the joys of TOSsership I guess...
> MS
>
>
>
> Eric Decker wrote:
>
>> 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 
>> <[email protected]<mailto:
>> [email protected]>> 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
>>        <[email protected] <mailto:[email protected]>
>>        <mailto:[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.
>>
>>
>>
>>
>> --
>> Eric B. Decker
>> Senior (over 50 :-) Researcher
>>
>>
>>


-- 
Eric B. Decker
Senior (over 50 :-) Researcher
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to