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: Paul Schlie
Subject: [avr-libc-dev] Re: Newlib [was: Re: Release?]
Date: Tue, 14 Dec 2004 13:25:55 -0500
User-agent: Microsoft-Entourage/11.1.0.040913

> 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), but a few targets have
optimized sub-directory ports of basic newlib functions which avr-libc could
form the basis of? Where although newlib doesn't contain boot-code per-se,
it might be reasonable to include in within a contrib subdirectory?

And with a little luck, possibly even get the gdb folks to accept simulavr
as an avr simulator (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; and
further complicated as Ted appears to feel a little
burned-out/overwhelmed/disillusioned at the moment?)






reply via email to

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