No, there is a compile time error if you try and define such a function inside a generic module for exactly the reason you mention. You can only do this in modules that are not generic. And adding the @C attribute makes sure it doesn't get the module sspecific extended name tacked on to the front of it. Take a look at the app.c generated from compiling the TestPrintf application and do a search for 'putchar'. Its implementation contains PrintfP$ names tacked on to beginning of some of the variables it uses, but the PrintfP$ does *not* get tacked on to the name of the function itself.
Kevin On Dec 15, 2007 2:18 PM, Michael Schippling <[EMAIL PROTECTED]> wrote: > Won't that make multiple copies of the 'global' function, > with module specific extended names, in the final code? > MS > > Kevin Klues wrote: > > Again, bad style, but there's nothing really preventing you from just > > creating a c-style function in a header file, and then #including it in > > any component you wish to use it in. > > > > You can even declare it in a header file, #include that file in any > > components you wish to use it, and then implement it within the body of > > one of your TinyOS modules so that it will have access to the variables > > defined in that module. To go this route, you need to add some nesC > > attributes to your function definition though. Take a look at the > > defintiion of uart_putchar() in tos/lib/printf/PrintfP.nc for an > > example. And take a look at chapter 9 of the TinyOS programming Manual > > to understand what these attributes are doing. > > > > http://csl.stanford.edu/~pal/pubs/tinyos-programming.pdf<http://csl.stanford.edu/%7Epal/pubs/tinyos-programming.pdf> > > > > Kevin > > > > On Dec 14, 2007 8:12 AM, Greg Hackmann < [EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > Michiel Konstapel wrote: > > >> I'm wondering whether I can define global function. > > >> The global function mean, I define a function in > > >> component A, and I can call this function in component > > >> B without using interface, just call the function directly? > > > > > > No, all interaction between components has to go through the > > commands and > > > events they define in their interfaces. Well, you could probably > > hack your > > > way there, but you're not really supposed to. > > > > Actually, you can have components provide and use commands and > events > > that aren't tied to any interfaces; e.g.: > > > > module SomeComponentP { > > provides command bool someCommand(uint8_t param); > > } > > implementation { > > command bool someCommand(uint8_t param) { > > ... > > } > > } > > > > This feature is used in a handful of places in TinyOS 2.0, like the > > TOSSIM ActiveMessage layer. See > > tos/lib/tossim/ActiveMessageAddressC.nc and > > tos/lib/tossim/TossimActiveMessageP.nc for an example. > > > > Doing this is arguably bad style, but it's possible nonetheless. > > > > Greg Hackmann > > _______________________________________________ > > Tinyos-help mailing list > > [email protected] > > <mailto:[email protected]> > > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > > > > > > > > > -- > > ~Kevin > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Tinyos-help mailing list > > [email protected] > > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help > > -- > Platform: WinXP/Cygwin > TinyOS version: 1.x, Boomerang > Programmer: MIB510 > Device(s): Mica2, MicaZ, Tmote > Sensor board: homebrew > > -- ~Kevin
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
