On Mar 8, 2006, at 5:46 AM, Ron Olson wrote:
Tomo,
I went through this a few weeks back, but I went a different
direction. I write and compile my C code as separate .c files,
rather than including them in a .nc file. That way, I don't have to
take any special precautions to insure that I don't have
overlapping variable names, etc. To do a build, I just compile
the .c files separately and include the .o files in the link. I got
the details of doing this from help on this forum, but it's
actually very simple.
These three steps work for me:
1) For compiling: msp430-gcc.exe -c *.c
2) For linking: Add '*.o' to the end of the PFLAGS setting in file /
opt/tinyos-1.x/tools/make/msp/msp.rules
3) To expose a function name in a .nc file so it's visible from
a .c file, or vice versa, add the '__attribute__((C, spontaneous))'
qualifier on a function definition.
This approach has worked great. I have a fairly sizable
application, 90% of which is in .c files. I compile and test under
native Linux before moving to the less friendly mote world. That
keeps my mote test time to a minimum.
The major disadvantage of this approach is that you don't benefit
from nesC's optimizations and dead code elimination. For application-
level codes, that's not too big a deal, but for low-level stuff it
can make a big difference. Another approach is to just write an
interface for your abstraction and wire it. Basically, using the C
linker lets you resolve the symbols post-compilation and saves you
the interface wiring code, but in so doing requires you use a global
namespace and sacrifice cross-call optimization.
Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
