[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Re: printf in avr-libc

From: Jörgen
Subject: Re: [avr-libc-dev] Re: printf in avr-libc
Date: Thu, 12 Sep 2002 12:23:41 -0700 (PDT)

C++ comments and long lines are easily fixed.

As far as the FILE approach; If you look in the
sources you will see that the formated_write function
indeed supports printf, sprintf fprintf at the same
time by requiring a function pointer and a void* data

Hmm, not sure I like the compile time select of
features approach, but I guess it could work.

A LOT is rewritten from Alexander's version. I spent
several hours with GCCv3.2 looking at the list file to
minimise the code size. Tried different switch / if
constructs, etc. I do not think that we need to start
from scratch.

I agree that putchar (used by printf) could be
predefined by stdlib to output characters on the UART
at 9600. If the programmer want's something else
she/he simply define their own putchar function.

--- Joerg Wunsch <address@hidden> wrote:
> As Jörgen Birkler wrote:
> > I can contribute with doxygen documentation if you
> > want to include it in the library (if it is
> possible
> > according to the licenses).
> As i wrote elsewhere, the licensing issues should be
> cleared.  It
> seems that Alexander has been working on a
> GPL-infected version from
> the GNU libc that by itself was inherited from
> BSD... and now
> Alexander's work was the base of your work.
> > One idea (not mine...) is to compile three
> versions of
> > the formatted_write function.
> formatted_write_small,
> > formatted_write_full and formatted_write_all. with
> > different capablities. At link you can set the
> weak
> > symbol _formatted_write to one of those three,
> > selecting how many features you need.
> Another idea is to use different macros so you could
> switch at
> compile-time (before including <stdio.h>) which
> version to use.
> I'd also like to see a floating-point version,
> possibly one that
> builds upon dtostre()/dtostrf().
> Too bad it is so big.
> What i don't like about it at a first glance:
> . It's too wide.  Line length should be limited to
> the usual 80
>   characters.
> . C++ style comments are currently not a part of the
> C standard
>   (although there are rumours that it is intented to
> standardize
>   them).
> I need way more time for a detailed review, in
> particular for a diff
> against Alexander's version to see what you actually
> changed.  Wrt.
> the licensing issues, it seems best to me to start
> over from the plain
> BSD version, then applying Alexander's diffs (which
> probably needs to
> be done manually).  This way, we get sure nobody can
> shoot us for a
> GPL violation.
> I still think it's worth a try to write a printf()
> from scratch that
> is particularly targeted at the AVR, in order to
> keep its size small.
> Maybe we'll really get smaller with this than by
> just `downporting' a
> version that has been written with a 32-bit engine
> in mind.
> Also, i'm thinking about a more generic FILE *
> approach than just
> calling a magical sendchar() function, something
> that would allow to
> implement a full fprintf() that can easily print to
> more than one
> channel in the system (say, a UART channel for
> debugging, and an LCD
> in the actual application).  Sure, there'll probably
> be something else
> than fopen() to establish the channel (since the
> user needs to supply
> the output function), but apart from that, i don't
> see why it
> shouldn't be done.
> I'm not sure, i think all the AVRs that can be
> programmed in C do also
> have a UART.  That way, it could make sense to
> pre-define an `stdout'
> channel that talks to the UART at 9600 Bd without
> further programmer
> interaction (i. e. to provide the necessary output
> function inside
> avr-libc).  Would give people an easy way to hack a
> quick debug
> printf() statement...  Those who want more
> sophisticated UART
> functions to be used need to overload the
> pre-existing definition of
> stdout.
> -- 
> J"org Wunsch                                         Unix support engineer
> address@hidden       
> http://www.interface-systems.de/~j/
> _______________________________________________
> AVR-libc-dev mailing list
> address@hidden

Do you Yahoo!?
Yahoo! News - Today's headlines

reply via email to

[Prev in Thread] Current Thread [Next in Thread]