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

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

Re: [avr-libc-dev] being able to use libc without fdevopen?


From: Frederik Rouleau
Subject: Re: [avr-libc-dev] being able to use libc without fdevopen?
Date: Wed, 08 Sep 2004 11:19:59 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803

Like many people I had the same pb. I have then chosen an other way than Svein.
I had statically allocated files streams in fdevopen.
So fdevopen became :

FILE stdStream[MAXSTREAM];
static unsigned char CurrentStream = 0;

//....

   //    if ((s = calloc(1, sizeof(FILE))) == 0)
if ((CurrentStream >= MAXSTREAM)||((s = &stdStream[CurrentStream++]) == 0))

The pb with that is that the number of stream is fixed in the lib( MAXSTREAM).

Svein's proposal seems better to me. I am wondering what are the benefits of hiding FILE's structure ? Otherwise Svein's pb of FILE's structure size will be solved....


Svein E. Seldal wrote:

Bernard Fouché wrote:

Hi.

I'm using an atmega162 and being short on flash. So I removed fdevopen
because I use only printf/puts, etc, with no float. fdevopen bring in
calloc/malloc and that eats more than one K of flash + ram overhead for
dynamic allocation. I was not able to link without the official fdevopen,
maybe I misunderstood linker options like "-Wl,-u,fdevopen".

To get rid of calloc/malloc in my application, I had to get rid of fdevopen
and to do so include stdio_private.h in my code and regenerate a libc
without fdevopen.

Is there another way to do it (I'd like to keep using the libc the
'official' way) ?


I have been annoied by the same fact. In fact I do not want to use the official avr-libc printf because it eats too much resources. After a brief investigation it turns out to be the addition of the fdevopen, which in turn pulls in calloc. Since I'm using a very small AVR, I absolutely do not want to use calloc. Hence avr-libc printf was dropped.

The reason that is so cumbersome today is basically because the developers dont want to reveal the size of FILE/struct __file. They have a avr-libc build-time implementation which is hidden from the user. E.g. to take sizeof(FILE) in an application is impossible because struct __file has no implementation in stdio.h. When you call fdevopen you will be returned a pointer to a memoryarea (of unknown size) to a struct __file. This unknown size is the size of the FILE implementation in the internal parts of the libc library.

While the idea to do this hiding of FILE's implementation is good, I dont like it when being used on a small microcontroller, because it requires calloc/malloc to work.

So my request is basically the same as Bernards request: Can we please make a static implementation of FILE, so that we dont need to have calloc to make it work. Or to put it in another way: I dont want to implement calloc _only_ because printf requires it.

I have an outline to fix this. It might not be the best solution, but it can possibly help to find a working version that does not require calloc.


in stdio.h:

#define FILE_SIZEOF 8
typedef uint8_t FILE[FILE_SIZEOF];


in stdio_private.h:

struct __file {
    ...
}

in fdevopen.c:

FILE *
fdevopen_static(FILE *file, int (*put)(char), int (*get)(void), int opts __attribute__((unused)))
{
    struct __file *s = (struct __file *)file;
}

in app.c:

int main(void)
{
    FILE static_file;
    fdevopen_static(&file,my_putc,my_getc,0);
}


The first assumption is that FILE is not defined to be struct __file.

The biggest challenge here is to keep sizeof(struct __file) == sizof(FILE) in sync. Maybe the FILE_SIZEOF could be autogenererated when the struct __file is compiled in the libc function?


Svein


_______________________________________________
AVR-libc-dev mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev






reply via email to

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