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