CVS copy/pasting problems in my local drive. I've committed it now, but it may take awhile for sourceforge to post it.
In the meantime, there should be another copy of it inside of tinyos-2.x-contrib/tunit/tos/lib/directserial -David -----Original Message----- From: Kevin Klues [mailto:[EMAIL PROTECTED] Sent: Saturday, September 22, 2007 1:33 PM To: David Moss Subject: Re: [Tinyos-devel] Re: [Tinyos-help] Question about printf The directserial directory isnt there. Kevin On 9/22/07, David Moss <[EMAIL PROTECTED]> wrote: > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Philip > Levis > Sent: Saturday, September 22, 2007 1:02 PM > To: Kevin Klues > Cc: [EMAIL PROTECTED]; 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 > [EMAIL PROTECTED] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel > > > -- ~Kevin _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
