[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
support for TI C3x/C4x DSP
- Date: 16 Mar 2003 09:26:53 +0100
- From: corsepiu at faw.uni-ulm.de (Ralf Corsepius)
- Subject: support for TI C3x/C4x DSP
Am Sam, 2003-03-15 um 15.56 schrieb Ted Buswell:
> Hi -
> I'm investigating RTOS options for a new project.
> What is the current status of RTEMS support for TI's DSP's?
Well, politely speaking, improvable, frankly speaking, pretty messy.
The main problem is the toolchain.
1. RTEMS c4x's port is based on hacked versions of old versions of gcc
and newlib. Within last year many changes have been introduced into
newlib's interaction with RTEMS, but these changes had not been
reflected back to the old C4x-toolchain.
Some time ago, I had provided a hack to get this old c4x-toolchain
usable with recent versions of RTEMS, but apparently nobody (incl. Joel)
was interested in picking it up.
2. Several months ago a couple of people seemed to have resumed
c4x-support for the official FSF binutils and gcc. However, to my
knowledge, at present time none of these activities have reached a
functional state nor has their work been reflect back to newlib.
I would not expect these activities to reach a usable state any time
3. The people resuming C4x-support in gcc/binutils have changed the
canonicalization name used for the C3x/C4x from c4x* into
tix<something>. As overall result, this resulted into many
incompatibilities between different parts of the gnu-tools, in total
rendering many of them unusable.
One of the tools having been affected is automake-1.7.x, i.e. it is
non-applicable without a patch for the old c4x-rtems toolchain.
> Searching the mailing list, I don't see much mention
> of it aside from the port announcement back in 2000.
> Is this a target people are currently using?
I don't know about anybody.
> Any feedback appreciated.