[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
pointer.
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
>
http://mail.freesoftware.fsf.org/mailman/listinfo/avr-libc-dev
__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com
- Re: [avr-libc-dev] Re: [avr-gcc-list] I fixed dtostre(), (continued)
- [avr-libc-dev] Re: [avr-gcc-list] I fixed dtostre(), Jamie Morken, 2002/09/10
- Re: [avr-libc-dev] Re: [avr-gcc-list] I fixed dtostre(), Joerg Wunsch, 2002/09/10
- [avr-libc-dev] Re: printf in avr-libc, ken restivo, 2002/09/10
- Re: [avr-libc-dev] Re: printf in avr-libc, E. Weddington, 2002/09/11
- Re: [avr-libc-dev] Re: printf in avr-libc, Joerg Wunsch, 2002/09/11
- [avr-libc-dev] Re: printf in avr-libc, Jörgen, 2002/09/12
- Re: [avr-libc-dev] Re: printf in avr-libc, Joerg Wunsch, 2002/09/12
- Re: [avr-libc-dev] Re: printf in avr-libc, Joerg Wunsch, 2002/09/12
- Re: [avr-libc-dev] Re: printf in avr-libc,
Jörgen <=
- Re: [avr-libc-dev] Re: printf in avr-libc, E. Weddington, 2002/09/12
- [avr-libc-dev] Multithreaded strtok, Harald Kipp, 2002/09/13
- Re: [avr-libc-dev] Multithreaded strtok, Joerg Wunsch, 2002/09/13
- Re: [avr-libc-dev] Re: printf in avr-libc, Joerg Wunsch, 2002/09/13
- Re: [avr-libc-dev] Re: printf in avr-libc, daniel_laptop, 2002/09/13
- Re: [avr-libc-dev] Re: printf in avr-libc, Joerg Wunsch, 2002/09/13
- Re: [avr-libc-dev] Re: printf in avr-libc, daniel_laptop, 2002/09/13
- Re: [avr-libc-dev] Re: printf in avr-libc, Jörgen, 2002/09/16
- Re: [avr-libc-dev] Re: [avr-gcc-list] I fixed dtostre(), Chris Baugher, 2002/09/10