avr-libc-dev
[Top][All Lists]
Advanced

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

[avr-libc-dev] Re: [avr-gcc-list] c library with stdio?


From: E. Weddington
Subject: [avr-libc-dev] Re: [avr-gcc-list] c library with stdio?
Date: Wed, 28 Aug 2002 13:06:13 -0600

In avr-gcc-list:

On 28 Aug 2002 at 18:38, Joerg Wunsch wrote:
 
> The problem with a full-blown printf() is that it'll probably almost
> fill up the entire ROM of a small device.  So it's usually better to
> perform the task manually.  Also, since there's by now no common
> notation of an IO device (in the sense of stdio's FILE *), it'll
> become hard to support more than just the sprintf() & Co. functions.
> 
> A simple way to do actual IO is to have printf() doing its IO to some
> imaginary user-supplied functions (e. g. the user is responsible to
> supply a getc() and putc() primitive), but this one has the
> disadvantage that you could only serve one IO channel in total.  So
> it's probably better to hide the actual IO channel and its details
> behind FILE *, but that requires a bit of consideration about how to
> implement it without wasting too much memory for the underlying
> structures.
> 
> -- 
> J"org Wunsch                                         Unix support engineer
> address@hidden       
> http://www.interface-systems.de/~j/ avr-gcc-list at http://avr1.org

Since this seems to be an issue with some people....

I agree that printf() is too impractical to do.

Any ideas about implementing at least sprintf() / snprintf(), with 
caveats about the amount of space it will take up (i.e. use it only 
on the bigger AVRs)? 

If not sprintf(), then how about an ftoa() to fill in the gaps (since 
there's already itoa(), utoa(), ltoa(), etc.)?

If not both than how about a FAQ as to why it's not implemented since 
this question keeps popping up. I've seen this question (about having 
printf()) also on the forums at avrfreaks.net.

Eric




reply via email to

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