[Tinyos-devel] Re: [Tinyos-help] Question about printf

[David Moss]

Phil's case is important.  I've seen a lot of support in TinyOS for
split-phase debugging output.  But there's this whole other area where
single-phase debugging output is critical, i.e. tracing through code as it
executes or trying to get something to print out before the uC gets locked
up in a mysterious infinite loop (try to debug older version of the CC2420
stack for example).  I don't think it's a matter of using printf
incorrectly, it's a matter of having an incompatible printf/serial stack
implementation underneath for what you're trying to do.  

For some types of single-phase debugging that would support Phil's for()
loop, I've experimented with a basic single-phase serial stack located at
tinyos-2.x-contrib/rincon/tos/lib/directserial.  Unfortunately, if it's
compiled in alongside the baseline serial stack, they conflict and cause
some problems, but it would be nice to get them to coexist.  With a
single-phase serial stack, Printf could then support nearly all of its use
cases (except for timing critical issues I suppose) and possibly require
less memory since its buffer is flushed out completely by the time the call
to printf() returns. 

-David





-----Original Message-----
From: tinyos-devel-bounces at Millennium.Berkeley.EDU
[mailto:tinyos-devel-bounces at Millennium.Berkeley.EDU] On Behalf Of Philip
Levis
Sent: Saturday, September 22, 2007 1:02 PM
To: Kevin Klues
Cc: schip at santafe.edu; TinyOS-Devel list; tos
Subject: [Tinyos-devel] Re: [Tinyos-help] Question about printf

On Sep 21, 2007, at 8:25 PM, Kevin Klues wrote:

> I don't seen anything in 'man 3 printf' that implies that it has to be
> a blocking operation.  In fact the manual shouldn't imply this.
> printf is part of the standard C library, not affiliated with any
> particular operating system.

Right -- the printf semantics have more to do with the associated  
file stream (printf is really just a call to fprintf) than with  
printf itself. In the case of printf, the file stream is stdout.

>
> To implement printf() functionality for any mcu that has a libc (such
> as msp430-libc or avr-libc) you just have to fill in the body of the
> 'putchar' function declared in "stdio.h".  This is exactly what the
> PrintfP component in tos/lib/printf does.  No magic..... it just
> collects the bytes coming in via calls to putchar, packs them into
> TInyOS serial messages, and sends them out over the USART.

Right -- so look at how putchar is typically implemented. The example  
from avr-gcc's stdio.h goes like this:

     static int
     uart_putchar(char c, FILE *stream)
     {

       if (c == '\n')
         uart_putchar('\r', stream);
       loop_until_bit_is_set(UCSRA, UDRE);
       UDR = c;
       return 0;
     }

     int
     main(void)
     {
       init_uart();
       stdout = &mystdout;
       printf("Hello, world!\n");

       return 0;
     }


> It should be left up to whatever operating system that implements it
> to define the semantics.

Great: I'd like to define a printf semantics that crashes the computer.

Look -- to reiterate my last mail, I agree that this function is  
useful, and it should be available. I'm just saying that, because it  
does differ significantly from what one might expect from printf,  
maybe it should be named differently. E.g.:

void test() {
   uint16_t i;
   for (i = 0; i < 20480; i++) {
     printf("\n");
   }
}

If you can find a reasonable implementation of printf besides yours  
that does not print out 20480 newlines, then my concern is totally  
unfounded and wrong.

Phil
_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at Millennium.Berkeley.EDU
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel