This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: newlib with avr-libc support
Ralf Corsepius wrote:
On 06/02/2009 06:45 PM, Weddington, Eric wrote:
-----Original Message-----
From: newlib-owner@sourceware.org
[mailto:newlib-owner@sourceware.org] On Behalf Of Ralf Corsepius
Sent: Tuesday, June 02, 2009 5:45 AM
To: Joel Sherrill
Cc: josh.switnicki@utoronto.ca; newlib@sources.redhat.com
Subject: Re: newlib with avr-libc support
Hi Ralf,
In RTEMS, stuff like interrupts etc. belong into RTEMS,
not into newlib.
Ralf, the .h files he is merging include all the CPU model
ifdef's and IO register names and bit definitions. avr-libc
provides them and you need them to write device drivers,
=> device drivers == RTEMS
The AVR is often used without any kind of OS.
The question was related to porting RTEMS to the avr.
> Do you have a constructive suggestion on how this functionality
should be organized within newlib?
Actually no, because I don't see much sense in merging avr-libc into newlib.
If at all, I could imagine some sense to merging parts of avr-libc into
libgloss.
Wrt. RTEMS, parts of avr-libc could likely be merged into RTEMS's cpukit
or lib/libcpu etc.
bring their setjmp/longjmp over and to write the RTEMS
context switch and interrupt vectoring code.
setjmp/longjmp are supposed to be machine independent and in newlib.
The problem he is having is that we need machine/avr/include/XXX
to get picked up and installed where XXX is a non-standard
directory. sys/linux does this but it looks like the method has
changed since I last looked at it.
sys/linux is a hack
So, we need another hack. This whole thing is going to be a hack.
We're trying to cobble together functionality from 3 different projects because,
- We want RTEMS to support the AVR.
RTEMS already does, except that some parts are missing inside of RTEMS.
- Newlib supports RTEMS.
- Newlib does not have (useful) AVR support.
I disagree. Newlib provides the amount of support required by RTEMS. Of
cause, there are bugs and defects, which should be ironed out.
The patch adds machine/avr. It adds setjmp.S from avr-libc.
That file includes at least the .h files from avr-libc which assists in
hiding the differences in the CPU models. It is a wrapper
for a collection of .h files -- one per CPU model. AFAIK that is
most of what is in the include/avr subdirectory and needed.
The avr/util directory may not be absolutely needed by setjmp.S.
But it contains a lot of AVR helper routines that are used
by all the AVR C code I have seen so far.
Since they were in avr-libc, it made sense to provide them in
newlib/avr because anyone trying newlib/avr as an alternative
to avr-libc is going to expect functional parity.
- AVR-LibC has complete AVR support.
- AVR-LibC does not currently support RTEMS.
AVR-LibC is not of much interest for RTEMS, because RTEMS is closely
tied to newlib.
There have been two suggested approaches to get RTEMS to support AVR:
- Add functionality from AVR-LibC to Newlib, so Newlib has better AVR support
- Add functionality from Newlib to AVR-LibC, so AVR-Libc has better RTEMS support
Joel has suggested the first. I have suggested the latter. We're both helping out Josh who is working on this as a GSoC project. I know that AVR-LibC (as a project) seems to have a lot more flexibility. But I'm ok if the first route is tried.
Both don't make sense, IMO.
It makes sense to use newlib with RTEMS and add the CPU support.
Your comments are confusing adding avr cpu support with the
inclusion of .h files you don't want to see.
Let us know if you have suggestions.
IMO, the way to go is to extend newlib's cpu specific parts and to
extend RTEMS with parts of avr-libc.
But that doesn't help the case building an avr-elf compiler
with newlib. It will not provide .h compatability with avr-elf
built with avr-libc. It takes no more effort to put it one place than
the other.
--joel
Ralf