Oh, I see. I don't need two header files to declare and define the variable. Since everything is conglomerated into one app.c file before real compilation occurs, all I need is the definition file that allocates the space and assigns it a name.
Don't need the #ifndef __HEADER_H__ thing either... Cool MS Eric Decker wrote: > > > On Tue, Jun 22, 2010 at 9:30 AM, Michael Schippling <[email protected] > <mailto:[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]> > <mailto:[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]>> > <mailto:[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
