avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0


From: Bernardo Innocenti
Subject: Re: [avr-libc-dev] Re: Revised release criteria for GCC 4.0
Date: Fri, 17 Dec 2004 00:27:51 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041208)

Joerg Wunsch wrote:
As Bernardo Innocenti wrote:


A long term goal could be merging intersting bits of avr-libc into
newlib and switching AVR toolchain distributions for Linux and
Windows to use newlib by default.


Perhaps, yes.

What's their CVS [commit] access policy?

gcc/binutils/gdb rules are very strict.  All developers
must sign FSF papers before you legally significant
patches can be committed.

After a few good patches have been approved and committed
by regular maintainers, a developer can ask for CVS write
access and get an account.  He's still required to get
non-obvious patches reviewed and approved before committing.

Newlib is perhaps not subject to the same rules.  It's even
under a BSDish license.  Judging from CVS activity, it receives
very little new development, but of course it's being bugfixed
and maintained as needed to keep it working on all supported
targets.


This would make AVR applications more portable while concentrating
development effort in a single C library.

Well, forgot about portability in microcontroller environments. ;-)

Either you design your application to be real portable, then it will
be, but it'll probably require a hardware abstraction layer, and thus
less optimal than a specific version.

Our AVR applications share a small (20-30%) part of portable
code with other embedded applications.  Most drivers are of
course very CPU specific, but some modules don't really need to
interact with hardware.

Some examples of portable code we use on the AVR are FIFO buffers,
linked lists, a printf-formatter, CRC16, graphics routines, a
heap allocator, etc.

These are shared with other embedded applications on DSP56800,
ColdFire and even a native emulator running on Win32/Linux.


If you've got an AVR-specific C file, you can probably pull out
algorithms into another controller project, but the overall
maintenance effort is bad enough so changing a couple of other items
(which could be automated by an editor) is no additional work.  As for
the library itself, it uses C standard names where appropriate, so
nothing would change.

avr-libc is very good at matching the ANSI/ISO C standard (except
that C99 fixed-size types are in inttypes.h instead of stdint.h).

Porting code to Microsoft's runtime requires much more tweaking
than avr-libc :-)


Toolchain distributors would still need to add some AVR-specific
headers for register definitions and asm macros, which wouldn't be
appropriate for inclusion in newlib.

That sounds bad.  Do you really think it's feasible to offload this to
``toolchain distributors''?  No centralized repository for it, where
it can be coherently maintained regardless of the person who is
shipping the toolchain?

No, you're right.  AVR developer tools are already broken in
too many uncoordinated projects.


Right now, you can at least shuffle an
AVR-GCC project back and forward between Windows & Linux & FreeBSD (&
Solaris & MacOS X) without any need to change your code (and if you
design it that way, hopefully even with the same Makefile).

This
would seem a much more important source code compatibility issue in my
opinion than a hypothetically increasing probability to port an AVR
project to an ARM7 or such.

We already enjoyed doing this between Win32 (WinAVR + cygwin)
and Linux (self-built toolchain) in several AVR projects.

The AVR toolchain is very strongly supported.  It's too bad
that every combination of OS and processor must be taken care
of separately.  There's an N * M maintenance cost for integration,
packaging and distribution, which is far from optimal.

There's a single place where most of the required components
are already concentrated: the sources.redhat.com repository,
which also happens to be the same site hosting gcc.gnu.org (*).

(*) this is well hidden for political reasons.

AVR-specific tools are not there primarly because creating
independent projects on SourceForge and Savannah is much
easier and results in greater freedom.

Some s.r.c and g.g.o developers would refuse to merge
AVR-only projects such as simulavr or avrdude, but many
other bits could go in for the mutual benefit of sharing
effort with other toolchains.

Alternatively, these smaller projects could be merged
into an umbrella project such as WinAVR or avr-libc
for increased integration (something like freedesktop.org).

The lack of high-quality toolchain distributions is
severely impairing the adoption of GNU development
tools, expecially among embedded engineers, who are
generally familiar with commercial Windows IDEs.
These users wouldn't ever consider building their
own GCC toolchain from sources, and I can't blame
them.


I strongly disagree with that aspect.  Why couldn't this be integrated
into newlib as well?  All these header files purposely go into an avr/
subdirectory already anyway.  Otherwise, we end up with one CVS repo
for newlib and one CVS repo for the avr-specific header files, which
would be no different than the current situation.

Is an application developer, I'd much prefer to find
the AVR headers in newlib's include directory.

But a newlib developer may want to avoid the maintainance
burden of architecture-specific headers for over 20 targets.
My guess is that newlib's focus is providing just the
core libc functionality for embedded applications.

Perhaps the addition of program-memory functions such as
strcpy_P() would be welcomed because many Harvard targets
need them.  The only way to be sure is asking on newlib's
mailing-list.

Being able to bootstrap a full AVR toolchain (GCC, binutils,
newlib and GDB) in the uberbaum tree by issuing a single
configure & make would already be very handy:

This is my script to build a complete AVR toolchain on
Linux, Mac OS X and Cygwin:

---cut---
#!/bin/sh

set -x

ROOTDIR=`pwd`
TREE=combined
ARCH=avr
VERS=HEAD
BUILDDIR=${ROOTDIR}/${ARCH}-${VERS}-build
INSTALLDIR=${ROOTDIR}/${ARCH}-${VERS}-install

export LD_LIBRARY_PATH=$INSTALLDIR/lib:$LD_LIBRARY_PATH
export PATH=$INSTALLDIR/bin:$PATH

rm -rf "${BUILDDIR}" "${INSTALLDIR}"
mkdir -p "${BUILDDIR}" "${INSTALLDIR}"
cd "${BUILDDIR}"
../${TREE}-${VERS}/configure \
        --prefix=${INSTALLDIR} \
        --target=${ARCH} \
        --enable-languages=c,c++ \
        --enable-multilib \
        --disable-libmudflap \
        --enable-target-optspace \
        --enable-threads=single \
        --with-gnu-ld \
        --disable-gdbtk \
        --disable-libmudflap \
        --disable-nls \
        --disable-__cxa_atexit \
        --disable-clocale \
        --disable-c-mbchar \
        --disable-long-long \
        --without-newlib \
        || exit 1
time nice gmake || exit 1
gmake install || exit 1

# avr-libc inappropriately uses these
export CFLAGS=
export CXXFLAGS=

AVRLIBC_VERS=1.0.4
AVRLIBC_SRC=avr-libc-${AVRLIBC_VERS}
AVRLIBC_BUILD=avr-libc-${AVRLIBC_VERS}-build
cd "${ROOTDIR}"
rm -rf "${AVRLIBC_BUILD}"
mkdir -p "${AVRLIBC_BUILD}"
cd "${AVRLIBC_BUILD}"
../${AVRLIBC_SRC}/configure \
        --prefix=${INSTALLDIR} \
        --target=${ARCH} \
        || exit 1
time nice gmake || exit 1
gmake install || exit 1
---cut---

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]