Re: [avr-libc-dev] Porting RTEMS patches to avr-libc

[Cynthia Rempel]

On 01/07/2013 12:31 PM, Georg-Johann Lay wrote:
> Weddington, Eric wrote:
>> First, I think it's great that you're working on this, and I'm all for
>> having RTEMS synced with avr-libc, as much as is feasible.
>>
>> The current release of avr-libc is 1.8.0, though we've been discussing
>> recently about fixing a bunch of bugs on HEAD for a future 1.8.1 release.
>> So, I would definitely suggest taking a look at porting 1.8.0, or even
>> better making sure that it works with HEAD.
>>
>> Avrtest is what is being used to test with the GCC testsuite. Although I
>> thought some work was also being done with simulAVR to make it work with the
>> GCC testsuite (perhaps someone else on this list can confirm or correct me
>> if I'm wrong).
>>
>> Additional recommendations: IIRC, there are some specific GCC bugs that are
>> avr-rtems specific (though less than a handful). Eventually, you, or someone
>> else on the RTEMS team, may want to take a look at those.
> AFAIK, there are no avr-rtems bugs in GCC.  There are PR50925 (ICE: spill fail
> in newlib build) and PR52488 (ICE for insanely memory allocation like 2000
> bytes for attiny).  These are no genuine RTEMS problems, they just occur
> because a different, less common code base (newlib) is compiled.  Similar
> problems can just as well occur with non-rtems configuration.
The bugs that were listed on the avr-libc bug-tracker looked resolved... 
although I'm currently experiencing the joys of trying to get the svn version 
of avr-gcc to compile (for testing purposes :). Just stumbled across ATMEL's 
Linux Toolset w/patches, 
http://distribute.atmel.no/tools/opensource/Atmel-AVR-Toolchain-3.4.1/avr/ , 
hoping up-to-date patches will help...
>
>> Joel and I have talked off and on over the years, and as I understood it,
>> RTEMS was using newlib for its C library. Does RTEMS now use avr-libc? Or
>> just a portion of avr-libc?
>>
>> If RTEMS will be using avr-libc on a more permanent basis for the future,
>> then perhaps we'll want to make sure that we coordinate testing, bug fixing,
>> etc.
> If RTEMS wants to use avr-libc, extending --with-avrlibc seems warranted so
> that is covers avr-rtems, see PR54461.
...if --with-avrlibc would get the svn avr-gcc to compile that would be very 
helpful! Until then, I'll play with trying to upstream ATMEL patches...

I thought about this some over the holidays and need to talk to some
of the other core developers when they get back from holiday.

I am thinking that if we start by restricting the subset of RTEMS that
we want on the AVR, then live gets enormously easier when changing
C libraries. The way newlib and RTEMS integrate, you have RTEMS
providing the bottom system calls expected by newlib. newlib owns
some .h files that we provide the implementation of (pthread.h being
at the top of the list). Plus we have our own malloc implementation.
-- I agree, if the other core developers agree, the restricting the size of the 
libraries in a deeply embedded system would be very beneficial, and using one 
libc implementation at a time would probably be easier as well...

I want to discuss starting with only the subset of RTEMS that is the
"Classic API" with no filesystems or networking. This would bring
a tasking RTOS comparable to ThreadX, VxWorks or Nucleus and
be independent of POSIX. This would simplify the integration with
avr-libc. Then we could discuss which pieces of RTEMS make sense
to enable.
-- I agree fully! The 8-bit AVR comes with it's own version of libc and using a 
restricted subset of real-time functionality is well worth exploring... It's 
very probable that eventually pthreads-like functionality could be simulated 
through clever macros of Classic API or Super Core calls.
>
> Johann


--
Joel Sherrill, Ph.D.             Director of Research&  Development
address@hidden        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35806
Support Available               (256) 722-9985