[Bug 2111] AVR needs avr-libc to compile RTEMS.

bugzilla-daemon at rtems.org bugzilla-daemon at rtems.org
Wed Apr 10 03:07:40 UTC 2013


--- Comment #13 from cynt6007 at vandals.uidaho.edu 2013-04-09 22:07:40 CDT ---
Condensed info:
1. Does AVR have a "timestamp" implementation?
2. score/cpu/avr/sys/time.h for now. Thanks! this simplifies things.
But the posix subdirectory has a few files which are built even when
--disable-posix is specified:

libposix_a_SOURCES += src/nanosleep.c src/clockgettime.c src/clocksettime.c \
    src/clockgetres.c src/sysconf.c

These need timespec and clockid_t plus sysconf.c needs the _SC_xxx constants
which are in unistd.h in newlib.
3. put SC_xxx constants in score/cpu/avr/unistd.h
4. strategically delete files under the score/cpu/avr/avr/ (keep only those not
in avr-libc, if any)
> I think this problem you found actually stems from the classic API Clock
> Manager (cpukit/rtems/include/rtems/rtems/clock.h) depends on struct timeval.
5. If struct timespec and timeval are POSIX, and feasible, disable everything
that depends on them.
This goes back to the requirements of what I have called "uRTEMS" for 
RTEMS on Microcontrollers. This is almost a throwback to version 1.x of
RTEMS where there was only the Classic API as defined by RTEID/ORKID.
No assumptions on C Library in the score and RTEMS -- not even memcpy.
6. in score/cpu/avr/rtems/score/cpu.h change this to FALSE 

And see how much farther you get. If you don't have timespec though, these
won't compile:

$ ls *spec*
coretodgetuptimetimespec.c  timespecfromticks.c  timespectoticks.c
timespecaddto.c             timespecisvalid.c    ts64totimespec.c
timespecdividebyinteger.c   timespeclessthan.c
timespecdivide.c            timespecsubtract.c

And don't worry about anything except C.  This is back to answering the

What are the requirements for uRTEMS?

+ C99/C11 Standard Library Dependency only? 
+ Classic API only?
+ no BSP TCP/IP stack?
+ filesystem(s)?
+ stack checker?
+ ...

I know I am on a requirements kick lately but defining them is important for
this. I believe the Classic API should be OK for uRTEMS minus struct time*
based upon the original design parameters.
Yes, scoping down the problem through requirements analysis is really critical
(so we can complete it), and because we want to build the "right-thing", after
all, right now the AVR community wants something smaller for avr-rtems to be

Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

More information about the bugs mailing list