In reference to calling nesC commands from a C function, I recently posted a similar question and got an answer. Here's a link to the thread:
http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2006-July/017770.html
Cheers.
-jay
On 8/18/06, Philip Levis <
[EMAIL PROTECTED]> 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
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
