MHV AVR Tools - an AVR toolchain for Windows

Last post
47 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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/group-projects/mhvavrtools

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

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

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.

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

Thanks Arnold, thats a good suggestion.

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

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

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

Updated to GCC 4.5.2 & AVR LibC 1.7.1.

Also includes GNU Win32 utilities such as rm & friends.

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

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

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

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!

Thanks for your work!

avrfreaks does not support Opera. Profile inactive.

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

@SprinterSB

Speaking about avr-gcc-4.5.x :-)

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

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

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.

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

New release:
- Upgrade to GCC 4.6.2
- Upgrade to AVR LibC 1.7.2rc2252
- Upgrade to AVRDUDE 5.11.1

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

I have not yet made the changes that Sprinter suggested.

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

evildeece wrote:
- Upgrade to GCC 4.6.2
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.

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

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

Can these features be disabled at GCC compile time?

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

avrfreaks does not support Opera. Profile inactive.

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

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.

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

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!

 

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

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.

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

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"

 

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

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 :)

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

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.

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

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

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

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.

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

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.

OSX will follow soon.

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

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.

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

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

http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20(Win32)/

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

avrfreaks does not support Opera. Profile inactive.

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

Thanks Sprinter :)

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

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

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

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

avrfreaks does not support Opera. Profile inactive.

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

What is smatch?

JW

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

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

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

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

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

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

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

avrfreaks does not support Opera. Profile inactive.

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

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

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

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

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/mhvavrtools-20121007

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

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.

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

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.

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

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

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

Cheers

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

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/?35407

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

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.

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

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

BR
Daniel

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

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++.

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

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.

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

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.

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

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.

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

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.

 

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

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

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

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-bin/gitweb.cgi?p=mhvavrtools.git;a=blob;f=mhvavrtools/setup.nsi;h=dc641965708a96c13f2b37de9c814de4a957cfd2;hb=HEAD

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

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