Also realised that
keywords like static or extern, do sod all as I discovered when
my app wouldn't compile due to redefinition errors.
Just wanted to share this in-case anyone else had special needs that
necessitated coding against the nesC/TinyOS programming model.
Darren
Darren BISHOP wrote:
Nevermind,
I am exploring using function pointers; it compiles, I guess as they
aren't used in command/event signatures.
Also discovered the C attribute - I am hoping this will allow access to
the modules namespace. If anyone is curious, read the 'nesC 1.1
Language Reference Manual', in particular nesC Applications and
Miscellaneous sections.
Best regards,
Darren
Darren BISHOP wrote:
Hi All,
Ted: Can you give details on your debugging interface?
Phil: I have implemented a C function with declaration 'extern result_t
lprintf(result_t *status, char *format, ...). The definition is
included by a LoggingM component that sends to UART when on Tmote Sky
or calls dbg when on TOSSIM.
Is there anyway to access the UART i.e. send to it, from this C
function. At some point I will be able to assert that no other
component will be sending to UART other than through this 'interface';
essentially I am trying to replicate dbg(...) when running on mote
hardware.
As it is, my implementation maintains a circular log-buffer which the
LoggingM component must poll to learn when work needs to be done, that
is, send to UART. What timer-rate do you think is reasonable in order
to yield an acceptable trade-off (i.e. performance hit due to context
switching vs. promptness of logging)? Should this be user-definable
(perhaps in the form of a compile-time option) where only the user will
really know how much (read: frequent) logging would be used, and also
how dependent (pc-side) processes are on timelyness; what's your
opinion?
Best regards,
Darren B
|
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
