newlib with avr-libc support

[Ralf Corsepius]

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.

> - 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.

> 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.

Ralf