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 joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35806 Support Available (256) 722-9985 _______________________________________________ AVR-libc-dev mailing list AVR-libc-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-libc-dev
