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 _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
