## Using WinAVR makefile with AVR Toolchain

27 posts / 0 new
Author
Message

Hi,

I am interested in using the makefile from WinAVR to compile codes using Atmel AVR Toolchain (because there will be no longer any WinAVR releases), is it possible? Any way, is therea makefile tool for AVR Toolchain?

If yes (for WinAVR makefile), where can I find instructions on how to add Atmel AVR Toolchain necessary excusable files (that will be called by the makefile) in the environment variables path to be able to use the makefile with Atmel AVR Toolchain?

thanks

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

It is possible.

What you need to do is to tweak the makefile so that it points to the tools in "AVR Toolchain" instead of the ones in you WinAVR directory.

Look somewhere near the middle of the makefile, where things like compiler, linker and other binutils are pointed out in Make variables:

# Define programs and commands.
SHELL = sh
CC = avr-gcc
OBJCOPY = avr-objcopy
OBJDUMP = avr-objdump
SIZE = avr-size
AR = avr-ar rcs
NM = avr-nm
AVRDUDE = avrdude
REMOVE = rm -f
REMOVEDIR = rm -rf
COPY = cp
WINSHELL = cmd


As you see, there are no paths in those, so your PATH variable will be used to determine the specific directory for them.

You either set your PATH variable so that it mentions the AVR Toolchain directory before WinAVR, or you edit the abbove variables so that they point specifically to the AVR Toolchain variants. (Where the AVR Toolchain lacks the executable, I think the best is to leave the variable pointing to the WinAVR executable. If you simply have the AVR Toolchain directory before the WinAVR directory in your path variable, then that should do the trick.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Hi,

I am having errors:

C:\Users\user\Desktop\SPI_Test>make clean

-------- begin --------

Cleaning project:
"C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\
AVRToolchain\bin\rm.exe" -f main.hex
/usr/bin/sh: C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRG
make: *** [clean_list] Error 127
C:\Users\user\Desktop\SPI_Test>make all

-------- begin --------
/usr/bin/sh: C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRG
make: *** [gccversion] Error 127

I also attached my makefile.

## Attachment(s):

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Things like 'rm' in WinAVR come from gnuwin32 so either install that or for those utilities continue to point to \winavr\utils\bin

The error about avr-gcc.exe is likely because the PATH needs quoting.

Quote:

The error about avr-gcc.exe is likely because the PATH needs quoting.

Of-course! Stupid me..

metal has this

CC = "C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-gcc.exe"

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

C:\Program

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

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Hi,

I modified the lines and noticed that avr-objdump.exe, avr-size.exe and avr-nm.exe cause troubles when used from AVR Toolchain folder.
I don't understand why these executable files exist in AVR Toolchain folder and aren't working with WinAVR makefile although Atmel uses them successfully. I need to understand how Atmel uses them, at least one could modify the original makefile template and create a makefile that always works with AVR toolchain, why not?

Apparently rm is working fine from AVR toolchain, the first error I posted was kinda deceiving, my bad.

# Define programs and commands.
SHELL = sh
CC = 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-gcc.exe'
OBJCOPY = 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objcopy.exe'
OBJDUMP = avr-objdump.exe
SIZE = avr-size.exe
AR = 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-ar.exe' rcs
NM = avr-nm.exe
AVRDUDE = avrdude.exe
REMOVE = 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\rm.exe' -f
REMOVEDIR = 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\rm.exe' -rf
COPY = 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\cp.exe'
WINSHELL = cmd

Here is the output of make all when I use avr-objdump.exe from AVR toolchain:

C:\Users\user\Desktop\lightspeed\SPI_Test>make all

-------- begin --------
avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling C: main.c
'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-gcc.exe' -c -mmcu=atmega88 -I. -gdwarf-2 -DF_CPU=
8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./main.lst  -std=gnu99 -MMD -MP -
MF .dep/main.o.d main.c -o main.o
main.c:17:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
main.c: In function 'main':
main.c:27:10: warning: array subscript is above array bounds [-Warray-bounds]

Compiling C: spi.c
'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-gcc.exe' -c -mmcu=atmega88 -I. -gdwarf-2 -DF_CPU=
8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./spi.lst  -std=gnu99 -MMD -MP -M
F .dep/spi.o.d spi.c -o spi.o

'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-gcc.exe' -mmcu=atmega88 -I. -gdwarf-2 -DF_CPU=800
0000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.o  -std=gnu99 -MMD -MP -MF .dep
/main.elf.d main.o spi.o --output main.elf -Wl,-Map=main.map,--cref     -lm

Creating load file for Flash: main.hex
'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objcopy.exe' -O ihex -R .eeprom -R .fuse -R .lock
main.elf main.hex

Creating load file for EEPROM: main.eep
'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objcopy.exe' -j .eeprom --set-section-flags=.eepr
--change-section-lma .eeprom=0 --no-change-warnings -O ihex main.elf main.eep || exit 0

Creating Extended Listing: main.lss
'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-objdump.exe' -h -S -z main.elf > main.lss
make: *** [main.lss] Error 127

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

I found what the problem was, schlieÃŸlich!!!

Instead of using slash I had to replace it with a backslash in the path and that's it, all tools from AVR toolchain are working now.

Finally, how can I assign

C:/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions\Atmel/AVRGCC/3.4.1.95/AVRToolchain/bin/

to a variable and use it in defining program paths, something like this as an example which is apparently not working, I don't know what the right syntax is for text concatenation:

new_path = 'C:/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions\Atmel/AVRGCC/3.4.1.95/AVRToolchain/bin/'

CC = new_path.avr-gcc.exe

What is the correct way to do it in a makefile.

Last funny thing, after I thought I succeeded I uninstalled WinAVR, and using make.exe from AVR toolchain, apparently there is something wrong:

C:\Users\user\Desktop\lightspeed\SPI_Test>"C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\make" all
The system cannot find the path specified.
The system cannot find the path specified.
ECHO is off.
-------- begin --------
avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-f was unexpected at this time.
make: *** [sizebefore] Error 255

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

Quote:

What is the correct way to do it in a makefile.

I would have thought something like:

TOOLPATH="C:/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions\Atmel/AVRGCC/3.4.1.95/AVRToolchain/bin"

CC=$(TOOLPATH)/avr-gcc.exe Total votes: 0 Thanks clawson, this is working now. TOOLPATH = 'C:/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions\Atmel/AVRGCC/3.4.1.95/AVRToolchain/bin' # Define programs and commands. SHELL = sh CC =$(TOOLPATH)/avr-gcc.exe
OBJCOPY = $(TOOLPATH)/avr-objcopy.exe OBJDUMP =$(TOOLPATH)/avr-objdump.exe
SIZE = $(TOOLPATH)/avr-size.exe AR =$(TOOLPATH)/avr-ar.exe rcs
NM = $(TOOLPATH)/avr-nm.exe AVRDUDE = avrdude.exe REMOVE =$(TOOLPATH)/rm.exe -f
REMOVEDIR = $(TOOLPATH)/rm.exe -rf COPY =$(TOOLPATH)/cp.exe
WINSHELL = cmd

I still can't use the make.exe of AVR toolchain:

C:\Users\user\Desktop\lightspeed\SPI_Test>"C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\
Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\make.exe" all
The system cannot find the path specified.
The system cannot find the path specified.
ECHO is off.
-------- begin --------
avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-f was unexpected at this time.
make: *** [sizebefore] Error 255

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

Add "-d" to the make command line for loads of debug info about what it's doing. You may also get more idea of what's wrong with "-n" as an alternative.

Seems there are a couple of executables that it tried to run but can't find them, I can't find what they are, but sure they are in C:\WinAVR-20100110\utils\bin, because when I add this path to system path variable, things are OK:

C:\Users\user\Desktop\lightspeed\SPI_Test>"C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\
Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\make" -n all
process_begin: CreateProcess(NULL, "", ...) failed.
process_begin: CreateProcess(NULL, "", ...) failed.
echo
echo -------- begin --------
'C:/Program Files (x86)/Atmel/Atmel Studio 6.0/extensions\Atmel/AVRGCC/3.4.1.95/AVRToolchain/bin'/av
r-gcc.exe  --version
if test -f main.elf; then echo; echo Size before: ; 'C:/Program Files (x86)/Atmel/Atmel Studio 6.0/e
xtensions\Atmel/AVRGCC/3.4.1.95/AVRToolchain/bin'/avr-size.exe --mcu=atmega88 --format=avr main.elf;
\
2>/dev/null; echo; fi
if test -f main.elf; then echo; echo Size after:; 'C:/Program Files (x86)/Atmel/Atmel Studio 6.0/ext
ensions\Atmel/AVRGCC/3.4.1.95/AVRToolchain/bin'/avr-size.exe --mcu=atmega88 --format=avr main.elf; \

2>/dev/null; echo; fi
echo --------  end  --------
echo

The question is, how does avr studio 6 compile without the need for executable files in C:\WinAVR-20100110\utils\bin

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

Quote:

I can't find what they are,

Not even using -n ?

BTW as far as I can see the make.exe in AS6 is the same 3.81 as the one in WinAVR

Quote:

The question is, how does avr studio 6 compile without the need for executable files in C:\WinAVR-20100110\utils\bin

The AVR Toolchain actually contains all the core stuf needed to build (vompiler, linker, objcopy etc). It does not contain all GNU commands/utilities that WinAVR does.

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

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Thank you Johan.

I see, then I will need WinAVR installation to get the missing tools, how sad indeed. I modified my path to this:

C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin;C:\WinAVR-20100110\bin;C:\WinAVR-20100110\utils\bin

all is OK now. I have to admit that I hate these workarounds..

It is ironic how people are forced to use AVR studio 5/6, firstly by making it impossible to find any makefile tools that work AVR Toolchain away from the studio, secondly there are members exist among us who can do it and it will not take much time from them, but apparently there is some unknown reason that prevents them doing this, may be, who knows!?

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

Quote:

making it impossible to find any makefile tools that work AVR Toolchain away from the studio

Not true. But you need to know what to look for, or what to do in the makefile.

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.

Quote:
It is ironic how people are forced to use AVR studio 5/6 [...]

Also not true. It all depends to a certain degree on what effort you are prepared to put in.

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

I tried an experiment of starting a Command Prompt and then setting the PATH to only be the location of AVR Toolchain and nothing else.

If I go to one of the Debug/Release directories for one of my existing AS6 projects and "make clean; make" it works without issue. If, however I switch to a directory with a simple one .c file project and an Mfile generated Makefile and try the same I get the errors being described here. I can make some of the problems go away by copying sh.exe and msys-10.dll from the Winavr installation to the directory but there are still problems.

The conclusion would seem to be, therefore, that it's specific commands in the Mfile generated Makefile and nothing to do with the actual make.exe+tools being used that is causing the problem.

I tried the obvious things like switching:

SHELL = sh

to be:

SHELL = c:/windows/system32/cmd.exe

but sadly that's not enough to clear the issue.

I suppose I could try a "binary split" on the contents of the errant Makefile (done with a bit of thought) to try and isolate just what it is that is causing the issue but a quicker solution may be to add the source files to AS6. Get it to generate a Makefile then use that for building at the Command Prompt if you are really going to insist on CLI building.

WOW,GNU Make manual, this is alone a disaster for me :- ) I will try to replace rm in the makefile with delete and see how it goes, hope it is just the rm command that has to be replaced.

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

I don't know why everyone is so hung up on rm.exe here? That is a complete red-herring and is NOT the reason why an Mfile Makefile is having problems with Atmel's Toolchain. For one thing:

C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin>dir rm.exe
Volume in drive C has no label.
Volume Serial Number is E0DD-96FE

Directory of C:\Program Files\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin

13/11/2012  13:53           109,056 rm.exe
1 File(s)        109,056 bytes

So even if you only have a PATH to this directory there are going to be no issues with rm.exe being found - it is already supplied as part of Atmel's Toolchain.

As I say the issue appears (in part) to be make.exe's need to invoke sh.exe. That is NOT present from Atmel. However making a copy available is not the entire solution. I've done that and there are still problems. There's something else missing too but, as I say, I haven't worked out what it is yet.

I am finding procmon.exe from systinternals.com quite useful in investigating though.

Last Edited: Tue. Jan 15, 2013 - 12:13 PM

clawson, to be honest with you, my laptop resources are a bit limited, really I am not willing to add more RAM or change the laptop. This is one reason I wanted to use CLI with AVR Toolchain. The new studio is really heavy and I have to wait some time till it starts running, and when it runs, it eats the RAM.

I do hope that you will be able to modify the makefile from WinAVR to work with AVR Toolchain.

Thanks for giving it a try. I mentioned that rm.exe works for me from the AVR Toolchain in a previous post. When Johan talked about it, I thought that rm.exe itself calls something that doesn't exist in the AVR Toolchain.

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

Quote:

I do hope that you will be able to modify the makefile from WinAVR to work with AVR Toolchain.

As I say you only need to run AS6 once to setup a project like the one for which you already have a Makefile and get AS6 to generate its own version of Makefile - then subsequently use that (or something similar though maybe not with Atmel's directory layout as they always build in a "Debug" or "Release" directory one level deeper than the source files.

Quote:

WOW,GNU Make manual, this is alone a disaster for me

Really? That is one of the best manuals I've read lately (as in the last 15 years.. :wink:) Well written, clear and to-the-point, excellent few introductory chapters, etc etc.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Come on Johan, don't be so hard on me, reading is different than learning :P

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

In the absolute majority of cases, learning implies reading.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

you'r right!

I'll read that, thoughI doubt it will tell me what the missing files are and how to modify the mfile to work with the new toolchain.

Signature: We need more peripherals in DIP packages. Namely, USB, 12-bit ADC, 16-bit timer, cheaper tool as a programmer/debugger coz STK600 is expensive! Atmel Studio 5/6 sucks! coz it brings MS visual studio crap to AVR world..

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

sizebefore:
@if test -f $(TARGET).elf; then echo; echo$(MSG_SIZE_BEFORE); \$(ELFSIZE); \
2>/dev/null; echo; fi

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.