Hi all, small comment about the new PrintF. If TOS_DATA_LENGTH is defined too large, then the condition Queue.size() > 5* sizeof(printfmsg) might always be false, because Queue.size is only a uint8_t.. Maybe you could find another way to computer the condition for flushing..
Well, I agree that it would be nice to have a non-split-phase debugging tool. I guess I can try myself the directserial.. Best regards, Alban 2007/9/22, David Moss <[EMAIL PROTECTED]>: > > 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 > Tinyos-help@Millennium.Berkeley.EDU > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >
_______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
