AVR Freaks

Re "rm":

You have redirected each and every executable in the makefile to the Atmel Toolchain directory. You can't do that blindly - You need to understand what you're doing..

I talked above about the AVR Toolchain is lacking some executables that WinAVR has. You have encountered e.g. the case of "rm" missing in the Atmels Toolchain.

So now you either need to replace rm with something else (i.e. the Windows/DOS equivalent) or make sure that for things missing in Atmel Toolchain your system falls back to the WinAVR instance. The things missing will typically be basic OS/Shell stuff like rm, so there should be no worries about incompatibilities.

If you really do not want to have your WinAVR installation any more, and don't want to change to Windows/DOS equivalents, then installing MinGW might be another option. While I have not checked everything, I highly suspect that MinGW caters all of the executables present in WinAVR that Atmel Toolchain lacks.

For each of the executables needed by the makefile you need to verify if Atmel Toolchain supplies them or not.

Re the second error: Can you verify tat avr-gcc.exe is really in that directory?

metal has this

in his makefile. Now, if make passes that string to the shell it will see a command without the quotes, and it will try to execute

So, some escaped quotes are needed in the executables variables in the makefile.

I think this would be much more simply done by having the AVR Toolchain path before the WinAVR path in the PATH variable. It will also be simpler to fix things when the tool chain changes its path (which it inevitably will, since the version number is in the path).

Your makefile makes use of the not-so-core stuff, e.g. like rm (which of-course is the Unix/Linux equivalent to the DEL command on Windows) that comes with WinAVR but is lacking in AVR Toolchain.

When Atmel Studio builds stuff, and e.g. needs to delete a file it simply uses something intrinsic in Windows, rather than the GNU/MinGW stuff that the Mfile makefile template uses.

So far the explanation. Now, on to an opinion:

I still think the simple way to get things going would be to have AVR Toolchain and WinAVR in your PAT variable. By placing AVR Toolchain first that will be the default place so to say. When something is missing there the search will go on to the WinAVR directory to get things like "rm". And your makefile template will not need all those long paths. And you will need to change in one place only when the AVR Toolchain is updated to a new version (when you have explicit paths in every makefile you will have a lot of places to update).

To make this clear: The Mfile makefile uses e.g. 'rm'. This is GNUs equivalent of a Windows delete file. If you want such a makefile to be usable you either need to have 'rm' on your system, or change the makfile so that it e.g. uses a DOS/CMD 'del' command instead.

I too think it is sad that the makers of the AVR Toolchain (i.e. Atmel themselvs) decided to cut down on the GNU tools supplied), but it is their choice and 99 percent of the Windows users will not need that stuff. For me it would just be a good freebie, but I suppose Atmel looks at it as something that AVR Toolchain does not need but that Atmel would need to maintain in some sense.

Blaming AVR Toolchain/Atmel is not very fair. The fact is that you are trying to use Mfile, and Mfile assumes you have 'rm' on your system. I can not see how it is the responsibility of AVR Toolchain to supply something needed by the Mfile utility.

You need to look at Mfile more as what it is - a utility coming out of the GNU/Linux way of thinking. It is up to you to supply whatever it needs to function properly.

And you need to understand the innards of the Mfile template makefile. And for that you need to understand something about GNU/Linux in general, and GNU Make in particular.

Your ultimate makefile tool is a good editor and the GNU Make manual.

E.g. changing those paths in the Mfile makefile is not exactly rocket science.

As an alternative: Installing MinGW to get a hold on the missing GNU utilities is a bit tougher, but certainly not impossible.

And in general, since avr-gcc and the rest of the tool chain is open source I can not see how Atmel is forcing anyone to use AS6. It might not be easy for the average user to build his own tool chain, but it certainly is possible. And if Atmel was forcing everyone, then what about all those people who actually develop for AVRs on GNU/Linux?

If you want to talk about debugging then that to is possible outside of AS6. You need to know a lot of stufff about things like AVARICE, GDB etc. And if you want to integrate that into an IDE (Eclipse, NetBeans) you have even more things to learn and stuff to do. But it is possible.

----------

Having said all that, I am still sad that Atmel actually chose the Windows-only route for AS5/6. It seems to me that the effort to get a development environment that could run on different platforms would not have been that much bigger (if bigger at all). But now Atmel has chosen this route, and we will have to live with it. It does not make things impossible, just a little bit more akward.

In the absolute majority of cases, learning implies reading.

Well part of the issue is that virtually the first thing the Mfile Makefile does is:

That invokes test.exe (another GNU util) with the -f option to test for the existence of foo.elf. Thing is that when cmd.exe is used instead of sh.exe that syntax is not valid. DOS batch language does support "if exist foo.elf" as an alternative but editing that line alone will not be sufficient.

I think the simplest solution is simply to keep a copy of \winavr\utils\bin in the PATH if the intention is to use this particular Makefile that uses GNU utils with impunity. YOu don't need the whole WinAVR installation. Just the .\utils\bin\* stuff from it.