## MHV AVR Tools - an AVR toolchain for Windows

49 posts / 0 new
Author
Message

I have put together a development environment and a set of scripts to build the latest GNU toolchain for Windows.

Please note that EW states that GCC 4.4.x is tested far more throughly than GCC 4.5.1 used in my release, so I would not recommend it for any production situation.

The build scripts and compiled binaries are available at:
http://www.makehackvoid.com/grou...

I'm happy to accept community patches, in particular:
- porting new device patches to GCC 4.5.1
- creating a Nullsoft installer for the package

May I suggest you bundle it with your library? That way your toolchain would have a distinguishing feature.

Stealing Proteus doesn't make you an engineer.

Thanks Arnold, thats a good suggestion.

Updated recently to include a real installer and smatch for C linting.

Updated to GCC 4.5.2 & AVR LibC 1.7.1.

Also includes GNU Win32 utilities such as rm & friends.

Can your binary installed *.exe tool co-exist with studio 4.18 ?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Hi. First of all, let me say that it's great to have distributions like this that are plain vanilla, leight-weight and come without the additional plethora of GUIs like AStudio!

I tried the 4.5.2 released 2011-03-06 and observed the problem that libgmp-10.dll could not be found. I did not add the path of the toolchain to PATH because I prefer to use the tools by specifying absolute path names like e:/absolute-install-path/bin/avr-gcc directly. (It worked after I added /bin to PATH, but if there are many toolchains installed it might be impossible to find the right order to add their paths to PATH and some toolchains will always use false DLLs).

The problem seem to be that you supply gmp/mpfr/mpc as shared libraries, so I propose adding --disable-shared to your configure options.

Moreover, the process of building avr-gcc is easier and straight forward if you do a in-tree build of the support libraries gmp/mpfr/mpc. To do that, just copy the sources of gmp/mpfr/mpc as "gmp", "mpfr" resp. "mpc" in the top-level gcc source tree (or, at your option, soft-link them).

That way you do not need seperate build steps for these libraries: gcc build machinery will recognize and configure, build and install them as needed. You don't have to give --with-gmp/-mpfr/-mpc any more. It's all handled automatically.

Moreover, some people might want to play around with link time optimization. I didn't try to build avr-gcc-4.5 with LTO yet, but maybe it works out of the box. To do that, just get appropriate version of libelf, link/copy it into gcc top-level source and say --enable-lto.

As GCC 4.6.0 is already released: is there also a 4.6.0 distribution? This might establish a narrower release-test-bugfix cycle. However, note that DWARF2 is broken in avr-gcc >= 4.6, so you would have to remove --with-dwarf2 from configure. See

http://gcc.gnu.org/PR48459

As Eric said, the 4.4 release is far more tested, but how are people supposed to test if there are no easily available distributions that can switched back and forth by changing some path name? Is everyone supposed to instell 3 versions of AStudio 5 just to test 3 releases of avr-gcc? I installed your version on Win2000 and it runs smooth!

avrfreaks does not support Opera. Profile inactive.

@SprinterSB

Could you mention a good combination of "options" for producing "small code"
Aka. Best practice GCC options for gcc-4.5.x

ie. -fno-split-wide-types

etc ...

/Bingo

Bingo600 wrote:
Could you mention a good combination of "options" for producing "small code"
Aka. Best practice GCC options for gcc-4.5.x

I don't think there is a magic combination of options that deflates you code by 10%, except -Os.

There are plenty of options and params; it's almost impossible to test all combinations. You can try to deactivate some of the following switches that are turned on with optimization:

-finline-small-functions
-fmove-loop-invariants
-fsplit-wide-types
-ftree-loop-optimize
-ftree-scev-cprop

It will depend on the code if or if not some switch might safe some bytes.

The biggest impact will have -Os and your coding style.

avrfreaks does not support Opera. Profile inactive.

New release:
- Upgrade to AVR LibC 1.7.2rc2252

The URL has changed, it can now be found at:
http://www.makehackvoid.com/proj...

I have not yet made the changes that Sprinter suggested.

evildeece wrote:
There is PR50063 that leads to wrong code. Did you disable that pass?

Moreover, -fno-caller-saves might be a good idea.

avrfreaks does not support Opera. Profile inactive.

Not yet, I'll roll off another build soon.

Can these features be disabled at GCC compile time?

avrfreaks does not support Opera. Profile inactive.

Hi folks,

A new release is available at http://www.makehackvoid.com/mhvavrtools-20120329

It includes GCC 4.7.0, SimAVR & GDB.

Win32 & Linux installers are available now, OSX will be up in a day or so.

Quote:

It includes GCC 4.7.0

How close to a 4.7.1 are you? I think that's the one everyone's waiting for!

clawson wrote:
Quote:
It includes GCC 4.7.0
How close to a 4.7.1 are you? I think that's the one everyone's waiting for!
4.7.0 should work will if no new features are used.

That is: If you use some version < 4.7 to compile a project, it should just as well work with 4.7.0.

If everyone just sits and waits for 4.7.1 (and thus no problems are reported) 4.7.1 will make absolutely no difference compared to 4.7.0 for the vase majority of code that don't use new features (that require source changes in the project). Simply becasue if there are no known problems, there won't be fixed for them, of course.

avrfreaks does not support Opera. Profile inactive.

Quote:

if no new features are used.

It's the new memory sections and pointer stuff that I think most people (certainly me) want to "play" with. But they want it wrapped up in a user friendly "WinaVR-alike"

and LTO is only fixed in the latest 4.7.1 AFAIK.

I play with 4.7.x for a few months, no problem with it, it optimizes code very well.

I converted all my code to use the new __flash feature, no more PROGMEM. Also I think all the pgm_read_xxxx() functions are being deprecated soon, so better convert your code :)

Magister wrote:
and LTO is only fixed in the latest 4.7.1 AFAIK.
LTO already worked in 4.6; the issue is rather with binutils and the windows environment.
Quote:
I play with 4.7.x for a few months, no problem with it, it optimizes code very well.
With current binutils I hit PR13899. Maybe it's best to use 2.21 where I don't see problems. 2.22 don't work for some other reason. I don't know how binutils folk handles backporting of PRs and how the prospects are that PR13899 is fixed. It's avr specific and thus very unlikely...
Quote:
I converted all my code to use the new __flash feature, no more PROGMEM. Also I think all the pgm_read_xxxx() functions are being deprecated soon, so better convert your code :)
There's no reason for a deprecation. There is really no reason to remove features like attribute progmem and render tons of code invalid. __flash is new feature that can help programmers as they deal with constants in flash; it's not intended to replace/deprecate progmem+pgm_read.

All source should be upward compatible and old code compile just as well without changing anything (except making data in flash read-only as introduced in 4.6, but that has nothing to do with __flash).

__flash is easier to use than pgm_read, in particular when dereferencing structures or mult-level pointers. Maybe __flash is good for new projects, but converting an old project and go through all that pain for nothing and just for nice sources??

I parameterized a project so that it can be built both with __flash and progmem+pgm_read in order to see performance differences or to learn how __flash interacts with real-world code in comparison with pgm. But the sources are ugly, even more ugly as with pgm alone. But with clean __flash there is no way to learn about the difference or performance degradation.

avrfreaks does not support Opera. Profile inactive.

I use binutils 2.22.52.20120322, so far so good, I did not hit the bug you mention, I will be careful though if something fails.

Also I was wrong, it's not the prog_read_xxxx() functions that are deprecated but the prog_char, prog_uint16_t, etc

On a SVN branch I have my code for 4.7.x, I integrated this in the Makefile to have it compiled with either my 4.3.0 or 4.7.1 :

GCCVERSION := $(shell echo avr-gcc -dumpversion) ifeq "$(GCCVERSION)" "4.7.1"
CTUNING += -mstrict-X
else
CTUNING += -morder1 -fno-split-wide-types -fno-inline-small-functions
CTUNING += --combine -fwhole-program
CDEFS   += -DUSE_PROGMEM
endif

Then in the C code I test USE_PROGMEM to include or not pgmspace.h, have a diff in some prototypes, etc

clawson wrote:
Quote:

It includes GCC 4.7.0

How close to a 4.7.1 are you? I think that's the one everyone's waiting for!

Thats more up to the GCC folk than me ;)

It typically takes me a few hours to put together a new package if I don't need to port anything, so I should be able to mave fairly quikly once 4.7.1 is announced.

MHV AVR Tools 20120709 has been released:
http://www.makehackvoid.com/mhvavrtools-20120709

- Bump to GCC 4.7.1 and Binutils 2.22.52.20120702 (development snapshot)
- Enable LTO
- Enable XMega microcontrollers

Windows (Atom or greater), Linux x86 (Atom or greater) and Linux x64 (Sandybridge or greater) binaries are available now.

Last Edited: Tue. Jul 10, 2012 - 10:36 PM

This release was a real pain to push out. I added a bootstrap step that first builds a native, current compiler and then builds the rest from that. When building AVR binutils and GCC, libtool kept installing the libtool wrappers instead of the actual executables.

I ended up building these components using the MinGW shipped compilers instead.

evildeece wrote:
GCC 4.7.1 and Binutils 2.22.52.20120702 (development snapshot)
There are some bugs in binutils. See the patches that the following 4.7.1 + 2.23 release applies:

avr-gcc-4.7.1-rc1-mingw32.zip!/source

in

Some of these issues are upstream meanwhile, others are not...

avrfreaks does not support Opera. Profile inactive.

Thanks Sprinter :)

FYI, with the MHV tool, my project build to 15670 bytes, with the 4.7.1 of SprinterSB it is 15460 bytes.

Presumably that difference is caused by PR53595 which is fixed in 4.7.2

avrfreaks does not support Opera. Profile inactive.

What is smatch?

JW

Smatch is a static analyser useful for flushing bugs in C code.

You can find it at http://smatch.sourceforge.net/.

I found that but it appeared to be cold dead... :-) and also the documentation was, ehm... lacking some details... ;-) I couldn't get to accept it more than one default path to system includes whereas gcc uses two... it appered to work on manually preprocessed source somehow, though...

Aren't there any usage hints for it?

Thanks,

JW

I'd guess the sourceforge smatch is just an open source clone of Coverity Prevent's smatch?

avrfreaks does not support Opera. Profile inactive.

Unfortunately no - I haven't gotten around to using it myself :/

I use Eclipse CDT's Codan feature and CPPCheck myself.

A new version of MHV AVR Tools has been released with GCC 4.7.2 and Binutils 2.22.90

Binaries are available for Windows, OSX & Linux.

http://www.makehackvoid.com/mhva...

This throws an error from the dynamic liner that libiconv-2.dll cannot be found.

In my canadian cross builds for MinGW32 this error does not occur, so is this a misconfiguration from mhv side?

avrfreaks does not support Opera. Profile inactive.

Some multilibs are empty, namely the ./tiny-stack and ./avr25/tiny-stack ones. This means something more went wrong.

avrfreaks does not support Opera. Profile inactive.

Eep, something bad must have happened between building and packaging.

I'll rebuild tomorrow and see if the problem reproduces.

Cheers

I just did a clean install and avr-gcc works, and libiconv-2.dll in installed.

If the bin directory is not in the path, you may see this error. If you did not select adding MHV AVR tools to the path at install time, you will either need to launch "MHV AVR Shell", or run the avrvars.bat from the installation in order to set up the path.

I'll need to read up more on the tiny stack issue, but it seems related to:
http://savannah.nongnu.org/bugs/...

I don't set PATH because I have around 20 versions / flavors of foo-gcc. Calling the tools by means of their absolute paths works under Linux and Windows for my builds.

With these builds, it also works if LTO is used which needs liblto_plugin.dll. No setting of PATH is needed.

The difference might be that I prefer --disable-nls with binutils and GCC. Rationale is that if people report problems and they post diagnostics (errors, warnings, fatal messagas, ...) it is not helpful if they are in Klingonian or Elbish or Rongorongo...

AVR-Libc #35407 is work in progress. AVR-Libc does not automatically adopt GCC's multilib layout from

-print-multi-lib
so that each multilib change has to be hand coded in the build machinery.

avrfreaks does not support Opera. Profile inactive.

Hello,
There it's any code editor bundled in this package ?

BR
Daniel

dandumit wrote:
Hello,
There it's any code editor bundled in this package ?

BR
Daniel

No, sorry. I use Eclipse myself, but if you want something a bit lighter, you can try Notepad++.

Hello evildeece,

Something's in the package is not in order.
I have in my PC the software Siemens Step 7 (for PLC programming), after the instalation of MHV AVR Tools is my Siemens software destroying :oops: :twisted: and WinCC Flexible also from Siemens will not start!
Just as a info.

Regards.

martincol wrote:
Hello evildeece,

Something's in the package is not in order.
I have in my PC the software Siemens Step 7 (for PLC programming), after the instalation of MHV AVR Tools is my Siemens software destroying :oops: :twisted: and WinCC Flexible also from Siemens will not start!
Just as a info.

Regards.

Try removing MHV AVR Tools from your system path. If you do this, you will need to run avrvars.bat before using the toolchain. The easiest way to do that is to use the MHV AVR Shell, which runs it automatically.

evildeece wrote:

Try removing MHV AVR Tools from your system path.

Of course I did it, but unfortunately nothing has brought software still works no more.

Google "Dependency Walker" then use that to view the dependencies of both things. They may have a .dll in common that one program has delivered a later version of perhaps?

If you use Windows you should be able to undo the installation with a System Restore point.

Hello clawson,
thanks for your help. I have yesterday everything Siemens Software removes, I had no other choice.

Curious, other than the path, the MHV AVR Tools installer doen't touch anything that may affect other programs, and does not install anything into the windows\system32 directory.

Any registry fiddling is all done under the "MHV AVR Tools" moniker, and should not affect other programs.

You can check here what the installer does here, it may provide a clue as to what is going on:
http://git.makehackvoid.com/cgi-...

Hi folks, it's been a while (busy with life), but I have a new release for you:
http://www.makehackvoid.com/mhvavrtools-20131017

This includes:
Make 4.0
Binutils 2.24.51
GCC 4.8-20131010
AVR LibC 1.8.0-dev

gettext and iconv are now statically linked for the Win32 release.

Also included are toolchains for OSX & Linux

Hi all,just a tad off topic but i just want to ask how to compile code using winavr without installing it to your path,see i have code that needs older versions of win avr,but i dont want to keep installing uninstalling win avr each time,now i know there are portable winavr versions,how do i use them? and also say i have other tool chains and i just want to compile lets say 32 bit mcu,but dont want to install the tool chain,can i just copy the make exe and linkers etc to a folder where my code is and open cmd in the folder and make it that way? ime just looking for a primitive easy way to compile code without having to compile a toolchain and add it to the path etc,as ime a noob and just dont understand what to do until some one sits with me and shows me,manuals are no good as they are made for people who allready understand alot more than a noob.

In any copy of avr-gcc everything it uses is defined in a relative position to avr-gcc.exe. So just compile with:

\path\to\the\one\to\use\avr-gcc -mmcu=atmegaXXX -Os main.c -o main.elf

and it will use the compiler, linker, binutils, avr-libc all related to that installation.

dunk9999 wrote:
and also say i have other tool chains and i just want to compile lets say 32 bit mcu,but dont want to install the tool chain,can i just copy the make exe and linkers etc to a folder where my code is and open cmd in the folder and make it that way?
No idea what you are talking about - how could you use a set tools without actually installing them? Or do you mean "installing them to PATH" ?
dunk9999 wrote:
ime just looking for a primitive easy way to compile code without having to compile a toolchain
Wow that's a bit of leap - on Windows almost no end user ever compiles a toolchain. If you want a particular toolchain why would you not simply use a set that someone else has built. For example:

dunk9999 wrote:
and add it to the path etc,

As I say you do not have to add it to the path. Observe...

C:\somewhere>type avr.c
#include <avr/io.h>

int main(void) {
PORTB = 0x55;
}
C:\somewhere>avr-gcc
'avr-gcc' is not recognized as an internal or external command,
operable program or batch file.

C:\somewhere>\SysGCC\avr\bin\avr-gcc.exe -Os -mmcu=atmega16 avr.c -o avr.elf

C:\somewhere>\SysGCC\avr\bin\avr-objcopy.exe -O ihex -j .text avr.elf avr.hex

C:\somewhere>type avr.hex
:100000000C942A000C9434000C9434000C943400AA
:100010000C9434000C9434000C9434000C94340090
:100020000C9434000C9434000C9434000C94340080
:100030000C9434000C9434000C9434000C94340070
:100040000C9434000C9434000C9434000C94340060
:100050000C94340011241FBECFE5D4E0DEBFCDBF29
:100060000E9436000C943B000C94000085E588BB90
:0A00700080E090E00895F894FFCFBF
:00000001FF

C:\somewhere>

That shows I have a C file. I try to run avr-gcc without specifying where it is but it just says "not recognized" because the location is not in my PATH. So then I invoke it by giving the location and not only does that know where avr-gcc.exe is but also where all the avr-libc headers are (providing things like avr/io.h and avr/iom16.h) but also where the avr-ld.exe linker is that is used to link the code. Finally to create an output hex file I just need to use avr-objcopy but again, I need to give the path to it as it is not on PATH either. Finally my avr.c code has been built into a .hex file.