[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?)
- [avr-libc-dev] Release?, E. Weddington, 2004/12/13
- Re: [avr-libc-dev] Release?, Joerg Wunsch, 2004/12/14
- Re: [avr-libc-dev] Release?, E. Weddington, 2004/12/14
- Re: [avr-libc-dev] Release?, Paul Schlie, 2004/12/14
- [avr-libc-dev] Newlib [was: Re: Release?], E. Weddington, 2004/12/14
- [avr-libc-dev] Re: Newlib [was: Re: Release?],
Paul Schlie <=
- [avr-libc-dev] Re: Newlib [was: Re: Release?], E. Weddington, 2004/12/14
- Re: [avr-libc-dev] Re: Newlib [was: Re: Release?], E. Weddington, 2004/12/14
- [avr-libc-dev] SIMULAVR / Test suite, Björn Haase, 2004/12/14
- Re: [avr-libc-dev] SIMULAVR / Test suite, Paul Schlie, 2004/12/14
- Re: [avr-libc-dev] SIMULAVR / Test suite, E. Weddington, 2004/12/14
- AW: [avr-libc-dev] SIMULAVR / Test suite for binutils and gcc, Björn Haase, 2004/12/19
- Re: AW: [avr-libc-dev] SIMULAVR / Test suite for binutils and gcc, E. Weddington, 2004/12/20
- AW: AW: [avr-libc-dev] SIMULAVR / Test suite for binutils and gcc, Björn Haase, 2004/12/20
- [avr-libc-dev] Re: Newlib [was: Re: Release?], Paul Schlie, 2004/12/14
- Re: [avr-libc-dev] Re: Newlib [was: Re: Release?], Joerg Wunsch, 2004/12/14