getting a new version of WinAVR

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

I am running Avr Studio 4 with a WinAVR I have used for a long time.

After downloading WinAVR-20100110-install.exe, in an attempt to get a new version, it appears to be the same version I have been using.

Is there a later version?
Where can I get it?

I am working on some 'GCC inline extended assembly' and would like to get the latest WinAVR before going ahead.

Thanks for any help,
...Jim

Minimize Coupling - Maximize Cohesion

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

Jim Hughen wrote:
Is there a later version?
No.

But there are other sources for newer Windows binaries, like here:
http://lists.gnu.org/archive/html/avr-gcc-list/2012-09/msg00024.html

Stefan Ernst

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

There is no later version.

Obviously the 2010 distribution has no knowledge of the more recent AVRs. However, I guess that 99% of users will be using the regular AVR chips. Hence 2010 will work just fine.

The Atmel 'Toolchain' works ok. It is up to date, and supports all current AVRs.

It does not install many of the common Unix utilities that WinAVR provides. In which case, you may want to copy them from a previous installation.

Yes, it would be nice to have a WinAVR-2013. I doubt that it will ever appear. Now that Toolchain works fairly well, it is even less likely.

David.

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

sternst wrote:

But there are other sources for newer Windows binaries, like here:
http://lists.gnu.org/archive/html/avr-gcc-list/2012-09/msg00024.html

How should this be done?

The file in the link includes the following folders (each with subfolders)
avr
bin
lib
libexec
share

Should all these folders be copied in winavr overwriting the old folders/files or we should replace files selectively?

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

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

alexan_e wrote:
Should all these folders be copied in winavr overwriting the old folders/files or we should replace files selectively?
Neither.
Extract it into its own folder and then let your IDE/PATH point at it.

Stefan Ernst

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

Don't change the WinAVR installation, you might want to use it again!

My WinAVR installed in C:/WinAVR20100110 so I unzipped the above to C:/avr-gcc47.

If you uncheck the "Use WinAVR" box in Project Options->Custom Options, and navigate to the new /bin/avr-gcc.exe and /bin/make.exe files, Studio will use those versions. However the rest of the tools (avr-objcopy, etc.) will still come from WinAVR because it included itself in the Windows PATH. To change that, right click System->Properties->Advanced->Environmental Variables->PATH->Edit and change the WinAVR-20100110 to avr-gcc47 for the \bin directory only:

C:\avr-gcc47\bin;C:\WinAVR-20100110\utils\bin

The tiny editing box is a major pain, and it is much simpler to use cygwin or mingw command windows where you can override by adding a new directory at the front of the search path:

$ which avr-gcc
/cygdrive/c/WinAVR-20100110/bin/avr-gcc
$ which make
/usr/bin/make

$ PATH=/cygdrive/c/avr-gcc47/bin:$PATH
$ which avr-gcc
/cygdrive/c/avr-gcc47/bin/avr-gcc
$ which make
/cygdrive/c/avr-gcc47/bin/make

Note that uses the make in gcc47, overriding the make in /usr/bin

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

Thank you for the detailed explanation

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

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

dak664 wrote:
...Note that uses the make in gcc47, overriding the make in /usr/bin

I have downloaded the package from the link given by sternst in the second post, there is no make.exe included in that. :roll:

Quote:
However the rest of the tools (avr-objcopy, etc.) will still come from WinAVR because it included itself in the Windows PATH

I suppose this is wrong and we should always change the paths so that all tools are from the same package?

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

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

Thank you for all responding so well.

This is an interesting situation. I use the AVR GCC complier
in very advanced project builds. It doesn't generate as
compact code as IAR, but it really works terrific.

Would it be possible for someone to take over maintence of
this application? Problem is, I don't want to upgrade past Studio 4.

Sorry, I do not understand what "AVR toolchain" is.
Does it include the GCC complier?
I just installed WinAVR with Studio 4 and away we go.
I use some assembly and other tricks to get the code faster, etc.
I am trying to dramatically reduce the interrupt latency, because
of a special chip which has only a single receive buffer FIFO byte.
For simple port i/o, inline assembly seems the best way, but it is
difficult for me to figure out the correct way to do it.

Minimize Coupling - Maximize Cohesion

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

Quote:

Would it be possible for someone to take over maintence of
this application?

Well Atmel kind of have. However they have branched which means you are hostage to their fortune. But if you want an avr-gcc with the widest device support the Atmel Toolchain (4.6.2) is it. The hope is they'll take the 4.7.2 work and make an issue based on that sometime in the near future.

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

dak664 - thanks for these detailed instructions.
they are essential for what I am doing.

Quote:
If you uncheck the "Use WinAVR" box in Project Options->Custom Options, and navigate to the new /bin/avr-gcc.exe and /bin/make.exe files, Studio will use

There did not seem to be a /bin/make.exe file in avr-gcc-4.7.2-mingw32.zip. It did have avr-gcc.exe

Minimize Coupling - Maximize Cohesion

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

I did find
D:\WinAVR-20100110\utils\bin\make.exe
and
D:\WinAVR-20100110\avrgcc4d7\bin\avr-gcc.exe

...Jim

Minimize Coupling - Maximize Cohesion

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

It would be very unwise to go mixing a 4.7 within the WinAVR2010 tree! Sure you can "borrow" make.exe (and perhaps some gnuwin32 tools) from there but that's about it.

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

Quote:
The Atmel 'Toolchain'... does not install many of the common Unix utilities that WinAVR provides.

Is this true any more? I thought (another thread) that one of the things standing in the way of a new winavr was that that the "toolchain" now included almost everything that used to be in winavr...

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

Nope WinAVR has most of gnuwin32. "Toolchain" still does not. The one thing they did get right in the latest incarnation was to finally include a copy of doc/avr-libc/*. I know Eric seemed to be doing a poll about 6 months ago to ascertain what Toolchain could benefit from including (find, grep, sed, etc) but as far as I know there hasn't yet been a major release from the Atmel toolchain people where such a change would become evident. Maybe they'll combine it with a 4.7.x release?

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

I am using the 2010 version in Windows and it is not letting me compile for a tiny24A part. How do I fix this please?

Tim Ressel
Portland, OR
timr@earthling.net

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

Google "Atmel toolchain for windows". Their current issue is 4.7.2 and AFAIK supports all the current models of AVR.

Don't totally uninstall WinAVR2010 though. Atmel's package is just the GNU/GCC toolchain - it does not have all the "extras" you get with WinAVR so keep that in your PATH (but lower down so the avr-*.exe tools are found in the Atmel version first).

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

I did as you said and it led me to an Atmel page where a 3.4.2 toolchain is available. Is this the one you mean?

Tim Ressel
Portland, OR
timr@earthling.net

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

I don't understand Atmel's mad numbering scheme so can't tell you. I get my avr-gcc from them as part of AS6.

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

That's correct - the toolchain package is 3.4.2, which contains GCC 4.7.x and other utilities. It doesn't make sense to version the toolchain after the compiler, since there's also binutils and other components with their own versioning schemes.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

madhun wrote:
I am using the 2010 version in Windows and it is not letting me compile for a tiny24A part.
The part name is attiny24a, not tiny24A. My WinAVR-20100110 compiles code for attiny24a, thus yours will too :-)

avrfreaks does not support Opera. Profile inactive.

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

Quote:
the toolchain package is 3.4.2, which contains GCC 4.7.x

"3.4.2" is just a particularly worrisome number, given the number of "packages" (winavr, crosspack, arduino) that include gcc v3.4.2...

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

Quote:

It doesn't make sense to version the toolchain

Yes it does. In all other realms you identify the GCC you are using by the compiler version. I may say I'm using "avr-gcc 4.6.2". Sure that may also, by implication mean I'm using binutils 2.21 and AVR-Libc 1.7.7 (or whatever) but everyone knows what I mean by using 4.6.2. If you now put all those things together and call it 14a.zqq.27beta46 or something then no one has ANY idea what you are using.

If you are going to call it 3.4.2 then consider "3.4.2-(4.7.2)" so the external observer has some chance of knowing the GCC version.

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

WinAVR was versioned after its release date, yet it was not too confusing.

Using the compiler (or binutils or whatever) version might also be confusing because the release might come with bulk of patches so that the Atmel release deviates arbitrarily from the FSF release.

avrfreaks does not support Opera. Profile inactive.

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

Is it correct to copy http://tinyurl.com/cagtojh avr-gcc on top of 2010 WinAVR?

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

Quote:

Is it correct to copy

How ironic. Did you realise that Georg-Johann Lay who posted that message is SprinterSB? Notice his signature line and in particular the "4.8 Windows" link.

I'm not sure I'd ever copy any toolchain version "on top" of another but I would install it to a new place then make sure that new place either replaces the old one in PATH or is listed before it in PATH. That way anything "replaced" will be found in the new installation while anything not replaced (srec_cat.exe for example) will still be found in the older installation.

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

What I usually do is that I install each version of WinAVR/"Toolchain"/GJL's build/whatever into a separate (sub)directory, and then call the desired version of tools explicitly through a complete path. A snippet from one of my "experimenting" makefiles:

# BIN_DIR = c:/PROGRA~1/Atmel/AVRTools/Wavr-gcc-4.7.1-rc1-mingw32/bin
# BIN_DIR = c:/PROGRA~1/Atmel/AVRTools/Wgcc-4.7-185693-mingw32/bin
# BIN_DIR = c:/Program\ Files/Atmel/AVRTools/Wgcc-4.6.1-mingw32/bin
# BIN_DIR = c:/Program\ Files/Atmel/AVRTools/AVRToolchain/bin
# BIN_DIR = c:/Program\ Files/Atmel/AVRTools/WinAVR20100110/bin
BIN_DIR = c:/Program\ Files/Atmel/AVRTools/WinAVR/bin

CC = $(BIN_DIR)/avr-gcc
OBJCOPY = $(BIN_DIR)/avr-objcopy

etc.

JW