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

[Joerg Wunsch]

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/