On Wed, Jun 23, 2010 at 10:52 AM, Michael Schippling <[email protected]>wrote:
> Oh, I see. I don't need two header files to declare and define > the variable. Since everything is conglomerated into one app.c > correct. > 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... > actually you do need the #ifndef. You don't have control of the order that files are processed and how they are being laid down into the app.c file so the easiest thing to do is to put the #include in modules that need the access. And which one gets pulled in first gets processed and the others get ignored. The easiest thing to do (and its good practice) is to use the #ifndef construct. eric > > 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 >> >> >> -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
