AVR3.5 (AT90USB162)

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been reading release notes trying to figure out if the AVR3.5 MUL fix has been release in avr-libc and gcc yet. I know the WinAVR binaries have the patches, but I'm building directly from source on Linux.

Looking at GCC source, I believe the AVR35 stuff was added in 4.2.3 which if true would be great. Now what about avr-libc? Does the code depend on these architectures? If so, has it been released?

And I assume binutils is unaffected and that 2.18 will continue to work?

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The patches for WinAVR are available at the WinAVR project on SourceForge in the CVS repository (under the 'patches' module). Why not just patch your Linux build?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I could patch 4.2.2, but is there a reason to do that if GCC 4.2.3 already has them applied? I'd rather not maintain a customized source tree locally.

Given that CVS has no avr-libc patches does that mean I only need to rebuild it for AVR35? Or are there avr-libc patches elsewhere?

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, looking at the WinAVR patches I see that binutils 2.18 has patches. So I guess I'll go that route to ensure I have the latest fixes.

The leaves me with two questions:

1. The get-patches.sh script in the sticky thread downloads patches mostly from freebsd ports. Are the WinAVR patches a superset of these? I believe applying the same patch twice is safe, so maybe I'll try both.

2. I'm still not sure if avr-libc needs patching for AVR35

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

- GCC 4.2.3 does not have them all applied. The upcoming GCC 4.3.0 has most of them applied, but not necessarily all.
- You don't have to have a customized source tree. But then you don't get all the features either.
- No, avr-libc does not need patching, if you use the latest release. Release cycles for avr-libc are usually faster than binutils, and gcc.
- WinAVR patches and FreeBSD Ports patches are closely aligned, but sometimes they get slightly out of sync. Each distro also may have distro or host specific patches that may not be needed on your host. Sometimes WinAVR has more bug fixes than FreeBSD Ports. Sometimes FreeBSD Ports patches gets updated before the WinAVR patches.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Eric. I think I'll grab them from WinAVR since it looks like it currently has some additional patches and filter out the 00-WinAVR specific ones.

I'm actually making a few improvements to the posted scripts that should make it easier to keep up with current patches. I'll post those or send them to /Bingo when I'm done.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't forget to see the README file. You may want to filter out the 1x patches too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've run into a problem with the patched version of gcc 4.2.2 on Linux. I am using the winavr patches minus the 0x and 1x patches. Binutils, gcc, and avr-libc all build and install fine, but when I try to build an application for either the AT90USB162 or AT90USB82 I get the following linker error:

/usr/local/lib/gcc/avr/4.2.2/../../../../avr/bin/ld: crtusb162.o: No such file: No such file or directory

This actually object file is here:

$ locate crtusb162.o
/usr/local/avr/lib/avr5/crtusb162.o

If I change the MCU in my makefile to any other usb chip, it links correctly. If the 59-gcc-4.2.2-avr35.patch is removed and gcc rebuilt, it links correctly. And if I manually copy:

/usr/local/avr/lib/avr5/crtusb162.o

to

/usr/local/avr/lib/avr35/crtusb162.o

it links correctly. So is this an avr-libc install problem? I wonder if its even building with the correct target. I am not that familiar with the *nix makefile install approach, so any tips how to fix this correctly would be appreciated.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What version of avr-libc are you using? I would recommend that you use the latest: 1.6.1.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using 1.6.1

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I filed this bug (and even managed to include the same typos as above) :)

http://savannah.nongnu.org/bugs/...

-Brad