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

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

[avr-libc-dev] Re: Newlib [was: Re: Release?]


From: E. Weddington
Subject: [avr-libc-dev] Re: Newlib [was: Re: Release?]
Date: Tue, 14 Dec 2004 12:06:37 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

Paul Schlie wrote:

From: "E. Weddington" <address@hidden>
Although a little off topic, anyone consider the possibility of contributing
it as the basis of an avr newlib/binutils port/directory of those efforts,
and consolidating effort avr effort there, as opposed to proceeding in
parallel? Or are there legal/logistical issues/complexities of doing so?

(as just thought it might help raise the effort's visibility?)
I don't know all the history. Marek knows it though.

IIRC, it started originally in newlib. I'm not completely sure of the
reason why avr-libc was broken off. But there are some advantages to
having a C lib seperate from newlib, in that we can put in AVR specific
headers and code, such as the bootloader, etc. I would certainly welcome
more comments from others in this area.

The avr port of newlib was only recently revived by the RTEMS people as
they are going to be using it (newlib) for the RTEMS OS.

There might be some advantages into re-integration, such as better
support for the math libary. On the other hand, avr-libc could be
extended to better support the needs of OSes such as RTEMS. (I've talked
to the RTEMS AVR maintainer about this.)

But anything along these lines will have to be done in the future after
a release.

Browsing in newlib, it would seem that avr-libc could complement newlib
(which is basically a C source code library),
That's not quite correct.
There is GLibC, which is used as the Standard C library for many hosts.
There is Newlib, which is used as the Standard C library for many embedded platforms. It is supposed to be smaller, and have better licensing for embedded platforms. There is avr-libc, which is used as the Standard C libarary for the AVR platform.

avr-libc and Newlib are not necessarily completementary, as a whole. Ideally, one would replace the other. Though avr-libc has functionality that is AVR-specific that is not normally found in Newlib.

There would have to be a process of even seeing if Newlib for the AVR is efficient enough, and resolving whatever differences there are. This is not insignificant.


And with a little luck, possibly even get the gdb folks to accept simulavr
as an avr simulator
Seperate issue.

Something is definitely needed to run the GCC test suite for the AVR. I don't know offhand what this would look like.


(although structured and interfaced differently than the
others; but don't know if it's a good idea, as the gdb folks seem to have
recently adopted the notion that gdb is to be focused on linux debugging,
leaving embedded target support somewhat in a cumbersome position;
That thread was mostly just a rant; I don't see it really changing anything.

and
further complicated as Ted appears to feel a little
burned-out/overwhelmed/disillusioned at the moment?)

A new AVR GDB maintainer will have to be found.

Eric





reply via email to

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