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

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

Re: [avr-libc-dev] AVR toolset critical issues


From: E. Weddington
Subject: Re: [avr-libc-dev] AVR toolset critical issues
Date: Tue, 23 Nov 2004 09:40:33 -0700
User-agent: Mozilla Thunderbird 0.7.3 (Windows/20040803)

E. Weddington wrote:

Hello All!

There are a number of critical issues with the AVR toolset (binutils, gcc, avr-libc) that need action soon, especially timing these with the upcomping 4.0.0 release, which seems to be targeted for early 2005 (possibly even January).

1. New AVR devices.
There are patches in the avr-libc Patch Manager to add these devices to the toolset: tiny13, tiny2313, at90can128, mega48, mega88, mega168. These patches are for binutils, gcc (HEAD and 3.4.x patches), and avr-libc. There needs to be *new patches* created for these devices: mega165, mega325, mega3250, mega645, mega6450. But the important thing is that these patches need to get committed.

2. Per-device multi-lib.
We've discussed this item before and there seems to be a lot of agreement that the toolset needs to get rid of the "architectures", which isn't really supported by Atmel, and go to per-device multi-libs. Ted said that Marek had some ideas about this. There's a CVS branch for it in avr-libc. But that's as far as it's gotten. Since we're adding new devices, now would be a good time to get this implemented, especially because of 4.0.0 coming up soon.

3. Update avr-libc auto* tools.
Unfortunately, the per-device multi-lib branch is the same as the new auto* tools branch. Perhaps they can both be done at the same time? If not, it would be great to seperate the two.

4. Warning on misspelled signal names.
Ted has a GCC patch for this. If this is good to go, it really needs to get committed to GCC.

Ted, Joerg, Denis, Marek: You guys have the FSF paperwork in for either binutils or gcc or both. In my current situation, I can't do this. It's going to be up to you (collectively) to commit these items (except for #3). I would hope that these items could get in before the window closes on GCC 4.0.0.

Ok everybody take a look at this on the GCC list:
<http://gcc.gnu.org/ml/gcc/2004-11/msg00775.html>

We don't have that much time to take care of these issues. At the very least can we get the patches for new devices into the toolset?

Thanks
Eric




reply via email to

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