Today was a day of discovery.
I am using tinyos-1.x and thus nesC1. I found the C attribute after reading
the reference manual and in doing so got a concrete understanding of how nesC
works on the whole.
The way I have implemented my logging API, it no longer matters who uses the
UART and when; the API is just for convenience (yes I got lumbered with
implementing infrastructure, tools, etc).
I looked as far deep as to see the byte transmission code, but retreated in
fear of breaking the whole stack.
Currently I have a 'standalone' LoggingC component, LoggingM component, a
Logging interface that can be used (coupled with 2 variadic macros, LOGF and
LOGSF) or a lprintf function that takes a function pointer (NULL if feedback
is not required) to a 'logDone' type function, and a format string and a
variable argument list.
If anyone is interested in the code, don't hesitate to ask.
--
Warm regards,
Darren Bishop, MSc, BSc (Hons), MBCS
On Friday 18 August 2006 20:27, Philip Levis wrote:
> On Aug 18, 2006, at 1:55 AM, 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?
>
> TinyOS 1.x or 2.x?
>
> The most important thing is to *not* write a blocking interface. It
> sounds like you're already along that route, which is good.
>
> If the question is "how do you I get C code to call nesC code?" the
> answer is pretty simple. In a component who can call the functions
> you care about, you define your lprintf with the attributes "C" and
> "spontaneous". David Gay probably knows best whether the latter is
> truly required to be 100% safe, but I tend to forget such things and
> so always include it. This means it won't be munged in the nesC
> namespace. Then define a header file somewhere that declares the
> function.
>
> E.g.:
>
> module DebugMagic {
> uses interface SomeByteLevelUartInterface as Bytes; // depends on
> 1.x or 2.x
> }
> implementation {
> result_t lprintf(result_t* status, char* format, ...)
> __attribute__ ((C, spontaneous)) {
> call Bytes.put(...);
> }
> // OR, depending on your nesc1 version,
>
>
> result_t lprintf(result_t* status, char* format, ...) @C()
> @spontaneous() {
> call Bytes.put(...);
> }
> }
>
> If the question is about making sure nobody sends other stuff to the
> serial port, that's a bit harder in 1.x because there is no resource
> management. My best recommendation would be to include a version of
> GenericComm that does not include the UART. I think you want to wire
> to HPLUARTC.
>
> If in 2.x, then on the Telos you want to instantiate a Uart1C to
> acquire the UART resource. You'll need to turn off the
> SerialActiveMessageC stack (call stop()), as when it starts it
> acquires the resource and does not release it until it stops.
>
> Phil
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
