AVR-Chat

I am just trying out AVR-VCC.  I am running Windows XP.  When I try to 
use MAKE, a DOS-type window appears for a split second and then 
disappears.

It has been a while since I had any need to try to use DOS programs, 
and I know it is an issue with XP.

What can I do so I can see the window with MAKE's results for more 
than a split second?

Switching back to Win98 or something is not possible.  My CPU is not 
supported in anything except XP.  It will run like a badly brain-dead 
P3 (or worse)in any other OS

-Tony

--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:
> I am just trying out AVR-GCC.  I am running Windows XP.  When I try
> to use MAKE, a DOS-type window appears for a split second and then 
> disappears.

You may not need to see the window.  Depending on where you launched it 
from it might be capturing the DOS box output or you might be able to 
make it do so.

Alternately, you can launch a DOS box (use Start Run and launch 'cmd') 
and then run make from there.

Don

----- Original Message -----

From: arhodes19044

To: AVR-Chat@yahoogroups.com

Sent: Saturday, April 09, 2005 11:27 PM

Subject: [AVR-Chat] Problem using AVR-GCC

I am just trying out AVR-VCC. I am running Windows XP. When I try to
use MAKE, a DOS-type window appears for a split second and then
disappears.

It has been a while since I had any need to try to use DOS programs,
and I know it is an issue with XP.

What can I do so I can see the window with MAKE's results for more
than a split second?

Switching back to Win98 or something is not possible. My CPU is not
supported in anything except XP. It will run like a badly brain-dead
P3 (or worse)in any other OS

Launch a dos prompt  ie Programs/accessories/Command Prompt
CD to you project's window and type make all. You should see everything.

Also you need the following on your path and make sure you have the temp
variables set ( I forget which one it uses)
Path=D:\Robot\WinAVR\bin;D:\Robot\WinAVR\utils\bin;
TEMP=C:\DOCUME~1\Dad\LOCALS~1\Temp
TMP=C:\DOCUME~1\Dad\LOCALS~1\Temp

Also are you running XP pro? Are you running with admin rights on the
box?

-----Original Message-----
From: arhodes19044 [mailto:spamiam@comcast.net] 
Sent: Saturday, April 09, 2005 6:27 PM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Problem using AVR-GCC





I am just trying out AVR-VCC.  I am running Windows XP.  When I try to 
use MAKE, a DOS-type window appears for a split second and then 
disappears.

It has been a while since I had any need to try to use DOS programs, 
and I know it is an issue with XP.

What can I do so I can see the window with MAKE's results for more 
than a split second?

Switching back to Win98 or something is not possible.  My CPU is not 
supported in anything except XP.  It will run like a badly brain-dead 
P3 (or worse)in any other OS

-Tony








 
Yahoo! Groups Links

Running MAKE from DOS?  Oh, Oh.  In XP (home), all that I can do, as 
far as I know, is open a DOS box.  I do not think that I can  drop 
into raw DOS the way I could in 98.

Isn't a DOS box good enough?

I did get a DOS box to come up and I can CD to the demo directory.  
From there I can issue the MAKE command.  MAKE does run, but says it 
can not see the makefile.  Of course the Makefile is right there in 
the current directory.

Why would this be?

It does not even like the "clean" arg to follow the MAKE command.

I am a little mystified.

-Tony


--- In AVR-Chat@yahoogroups.com, "Leon Heller" <leon.heller@d...> 
wrote:
>   ----- Original Message ----- 
>   From: arhodes19044 
>   To: AVR-Chat@yahoogroups.com 
>   Sent: Saturday, April 09, 2005 11:27 PM
>   Subject: [AVR-Chat] Problem using AVR-GCC
> 
> 
> 
> 
>   I am just trying out AVR-VCC.  I am running Windows XP.  When I 
try to 
>   use MAKE, a DOS-type window appears for a split second and then 
>   disappears.
> 
>   It has been a while since I had any need to try to use DOS 
programs, 
>   and I know it is an issue with XP.
> 
>   What can I do so I can see the window with MAKE's results for 
more 
>   than a split second?
> 
>   Switching back to Win98 or something is not possible.  My CPU is 
not 
>   supported in anything except XP.  It will run like a badly brain-
dead 
>   P3 (or worse)in any other OS
> 
> 
> 
> Are you actually running Make from DOS? You need to do that, 
rather than just running Make as a Windows application.

> 
> Leon
> --
> Leon Heller, G1HSM
> http://www.geocities.com/leon_heller

--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:

> I am just trying out AVR-VCC.
> I am running Windows XP.
>  When I try to use MAKE ...

If you want to use GCC for AVR on Windows, I suggest you get WinAVR. 
You can launch make from within Programmer's Notepad and the output is 
captured and shows up in a window of the GUI.

Graham.

I definitely do not get the same results as you.  I will re-install 
WinAVR and try again!

-Tony

--- In AVR-Chat@yahoogroups.com, "Leon Heller" <leon.heller@d...> 
wrote:
> ----- Original Message ----- 
> From: arhodes19044
> To: AVR-Chat@yahoogroups.com
> Sent: Sunday, April 10, 2005 2:12 PM
> Subject: [AVR-Chat] Re: Problem using MAKE
> 
> 
> 
> Running MAKE from DOS?  Oh, Oh.  In XP (home), all that I can do, 
as
> far as I know, is open a DOS box.  I do not think that I can  drop
> into raw DOS the way I could in 98.
> 
> Isn't a DOS box good enough?
> 
> I did get a DOS box to come up and I can CD to the demo directory.
> From there I can issue the MAKE command.  MAKE does run, but says 
it
> can not see the makefile.  Of course the Makefile is right there in
> the current directory.
> 
> Why would this be?
> 
> It does not even like the "clean" arg to follow the MAKE command.
> 
> I am a little mystified.
> 
> 
> Just open a DOS box, that's what I do.
> 
> Here's what I get:
> 
> C:\WinAVR\examples\demo>make clean
> rm -rf *.o demo.elf *.eps *.png *.pdf *.bak
> rm -rf *.lst *.map *.hex *.bin *.srec
> 
> C:\WinAVR\examples\demo>make
> avr-gcc -g -Wall -O2 -mmcu=atmega8    -c -o demo.o demo.c
> avr-gcc -g -Wall -O2 -mmcu=atmega8  -Wl,-Map,demo.map -o demo.elf 
demo.o
> avr-objdump -h -S demo.elf > demo.lst
> avr-objcopy -j .text -j .data -O ihex demo.elf demo.hex
> avr-objcopy -j .text -j .data -O binary demo.elf demo.bin
> avr-objcopy -j .text -j .data -O srec demo.elf demo.srec
> avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex 
demo.elf 
> demo_eepr
> om.hex
> avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O binary 
demo.elf 
> demo_ee
> prom.bin
> avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O srec 
demo.elf 

> demo_eepr
> om.srec
> 
> C:\WinAVR\examples\demo>
> 
> Leon
> --
> Leon Heller, G1HSM
> http://www.geocities.com/leon_heller

I re-re-loaded WinAVR and it does the same thing.  I used PN to try 
the make and it got the same results.

I loaded WinAVR on my kids old computer and everything worked just 
as advertised.

Maybe I will have to use their computer to do the work.  They will 
love it because they are not usually allowed on my computer.

-Tony

--- In AVR-Chat@yahoogroups.com, "wbounce" <wbounce@s...> wrote:
> Be sure of the case of your files. While windows does not care, 
some of
> the unix style tools in winavr do. 
> 
> -----Original Message-----
> From: arhodes19044 [mailto:spamiam@c...] 
> Sent: Sunday, April 10, 2005 9:12 AM
> To: AVR-Chat@yahoogroups.com
> Subject: [AVR-Chat] Re: Problem using MAKE
> 
> 
> 
> 
> Running MAKE from DOS?  Oh, Oh.  In XP (home), all that I can do, 
as 
> far as I know, is open a DOS box.  I do not think that I can  drop 
> into raw DOS the way I could in 98.
> 
> Isn't a DOS box good enough?
> 
> I did get a DOS box to come up and I can CD to the demo 
directory.  
> >From there I can issue the MAKE command.  MAKE does run, but says 
it
> can not see the makefile.  Of course the Makefile is right there 
in 
> the current directory.
> 
> Why would this be?
> 
> It does not even like the "clean" arg to follow the MAKE command.
> 
> I am a little mystified.
> 
> -Tony
> 
> 
> --- In AVR-Chat@yahoogroups.com, "Leon Heller" <leon.heller@d...> 
> wrote:
> >   ----- Original Message ----- 
> >   From: arhodes19044 
> >   To: AVR-Chat@yahoogroups.com 
> >   Sent: Saturday, April 09, 2005 11:27 PM
> >   Subject: [AVR-Chat] Problem using AVR-GCC
> > 
> > 
> > 
> > 
> >   I am just trying out AVR-VCC.  I am running Windows XP.  When I
> try to 
> >   use MAKE, a DOS-type window appears for a split second and 
then 
> >   disappears.
> > 
> >   It has been a while since I had any need to try to use DOS
> programs, 
> >   and I know it is an issue with XP.
> > 
> >   What can I do so I can see the window with MAKE's results for
> more 
> >   than a split second?
> > 
> >   Switching back to Win98 or something is not possible.  My CPU 
is
> not 
> >   supported in anything except XP.  It will run like a badly 
brain-

> dead 
> >   P3 (or worse)in any other OS
> > 
> > 
> > 
> > Are you actually running Make from DOS? You need to do that,
> rather than just running Make as a Windows application.
> > 
> > Leon
> > --
> > Leon Heller, G1HSM
> > http://www.geocities.com/leon_heller
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links

----- Original Message ----- 

From: arhodes19044
To: AVR-Chat@yahoogroups.com
Sent: Sunday, April 10, 2005 2:12 PM
Subject: [AVR-Chat] Re: Problem using MAKE



Running MAKE from DOS?  Oh, Oh.  In XP (home), all that I can do, as
far as I know, is open a DOS box.  I do not think that I can  drop
into raw DOS the way I could in 98.

Isn't a DOS box good enough?

I did get a DOS box to come up and I can CD to the demo directory.
From there I can issue the MAKE command.  MAKE does run, but says it
can not see the makefile.  Of course the Makefile is right there in
the current directory.

Why would this be?

It does not even like the "clean" arg to follow the MAKE command.

I am a little mystified.


Just open a DOS box, that's what I do.

Here's what I get:

C:\WinAVR\examples\demo>make clean
rm -rf *.o demo.elf *.eps *.png *.pdf *.bak
rm -rf *.lst *.map *.hex *.bin *.srec

C:\WinAVR\examples\demo>make
avr-gcc -g -Wall -O2 -mmcu=atmega8    -c -o demo.o demo.c
avr-gcc -g -Wall -O2 -mmcu=atmega8  -Wl,-Map,demo.map -o demo.elf demo.o
avr-objdump -h -S demo.elf > demo.lst
avr-objcopy -j .text -j .data -O ihex demo.elf demo.hex
avr-objcopy -j .text -j .data -O binary demo.elf demo.bin
avr-objcopy -j .text -j .data -O srec demo.elf demo.srec
avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex demo.elf 
demo_eepr
om.hex
avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O binary demo.elf 
demo_ee
prom.bin
avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O srec demo.elf 
demo_eepr
om.srec

C:\WinAVR\examples\demo>

Leon
--
Leon Heller, G1HSM
http://www.geocities.com/leon_heller

Kat, I hope you don't mind my posting an off-topic e-mail, but I thought 
someone on this group might know the answer.

I seem to be on everyone's spam list and I get the usual barrage of ads 
for drugs, loans, Nigerian scams, etc. every day.  But lately I've gotten 
a couple new types.

The e-mails are purportedly from bluemountain.com, which is an e-card 
service with e-mail greeting cards.  It says I've received a greeting 
card.  The first time I got one I thought it was legit and clicked on the 
link in the e-mail.  I got a "404 Not Found" screen which was part of the 
website I went to (a dummy screen) and something else happened between my 
computer and the other site.  I quickly disconnected from internet and 
examined the e-mail more closely, looking at the source code, then 
reconneced and went to www.dnsstuff.com to look at where the e-mail had 
actually taken me.  As I suspected, it was some place in Wall, South 
Dakota, not Bluemountain.com.

The thing is, I have no idea what the site was set up to do.  Install 
spyware?  Harvest e-mail addresses from my computer?  Any ideas?

Zack

Be sure of the case of your files. While windows does not care, some of
the unix style tools in winavr do. 

-----Original Message-----
From: arhodes19044 [mailto:spamiam@comcast.net] 
Sent: Sunday, April 10, 2005 9:12 AM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Re: Problem using MAKE




Running MAKE from DOS?  Oh, Oh.  In XP (home), all that I can do, as 
far as I know, is open a DOS box.  I do not think that I can  drop 
into raw DOS the way I could in 98.

Isn't a DOS box good enough?

I did get a DOS box to come up and I can CD to the demo directory.  
>From there I can issue the MAKE command.  MAKE does run, but says it
can not see the makefile.  Of course the Makefile is right there in 
the current directory.

Why would this be?

It does not even like the "clean" arg to follow the MAKE command.

I am a little mystified.

-Tony


--- In AVR-Chat@yahoogroups.com, "Leon Heller" <leon.heller@d...> 
wrote:
>   ----- Original Message ----- 
>   From: arhodes19044 
>   To: AVR-Chat@yahoogroups.com 
>   Sent: Saturday, April 09, 2005 11:27 PM
>   Subject: [AVR-Chat] Problem using AVR-GCC
> 
> 
> 
> 
>   I am just trying out AVR-VCC.  I am running Windows XP.  When I
try to 
>   use MAKE, a DOS-type window appears for a split second and then 
>   disappears.
> 
>   It has been a while since I had any need to try to use DOS
programs, 
>   and I know it is an issue with XP.
> 
>   What can I do so I can see the window with MAKE's results for
more 
>   than a split second?
> 
>   Switching back to Win98 or something is not possible.  My CPU is
not 
>   supported in anything except XP.  It will run like a badly brain-
dead 
>   P3 (or worse)in any other OS
> 
> 
> 
> Are you actually running Make from DOS? You need to do that,
rather than just running Make as a Windows application.
> 
> Leon
> --
> Leon Heller, G1HSM
> http://www.geocities.com/leon_heller





 
Yahoo! Groups Links

Using the MFILE utility style makefile If I run make all in a dos window
I get
D:\Robot\Projects\MinGrand>make all

-------- begin --------
avr-gcc (GCC) 3.4.1
Copyright (C) 2004 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.


Size before:
Robot.elf  :
section            size      addr
.data               266   8388864
.text             17924         0
.bss                377   8389130
.noinit               0   8389507
.eeprom               0   8454144
.debug_aranges      184         0
.debug_pubnames    2458         0
.debug_info       11295         0
.debug_abbrev      2366         0
.debug_line        7330         0
.debug_str          532         0
Total             42732




Compiling: Robot.c
avr-gcc -c -mmcu=atmega128 -I. -gdwarf-2   -O0 -funsigned-char
-funsigned-bitfie
lds -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=Robot.lst
 -std=gnu99 -Wp,-M,-MP,-MT,Robot.o,-MF,.dep/Robot.o.d Robot.c -o Robot.o
Robot.c: In function `main':
Robot.c:350: warning: unused variable `LastSonarRange'

Linking: Robot.elf
avr-gcc -mmcu=atmega128 -I. -gdwarf-2   -O0 -funsigned-char
-funsigned-bitfields
 -fpack-struct -fshort-enums -Wall -Wstrict-prototypes
-Wa,-adhlns=Robot.o  -std
=gnu99 -Wp,-M,-MP,-MT,Robot.o,-MF,.dep/Robot.elf.d Robot.o i2c.o motor.o
ringbuf
.o sonar.o uart.o logeeprom.o ParseGPSData.o compass.o    --output
Robot.elf -Wl
,-Map=Robot.map,--cref  -Wl,-u,vfprintf -lprintf_min -Wl,-u,vfscanf
-lscanf_min
-lm

Creating load file for Flash: Robot.hex
avr-objcopy -O ihex -R .eeprom Robot.elf Robot.hex

Creating load file for EEPROM: Robot.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex Robot.elf Robot.eep

Creating Extended Listing: Robot.lss
avr-objdump -h -S Robot.elf > Robot.lss

Creating Symbol Table: Robot.sym
avr-nm -n Robot.elf > Robot.sym

Size after:
Robot.elf  :
section            size      addr
.data               266   8388864
.text             17924         0
.bss                377   8389130
.noinit               0   8389507
.eeprom               0   8454144
.debug_aranges      184         0
.debug_pubnames    2458         0
.debug_info       11295         0
.debug_abbrev      2366         0
.debug_line        7330         0
.debug_str          532         0
Total             42732



Errors: none
-------- end --------

-----Original Message-----
From: Leon Heller [mailto:leon.heller@dsl.pipex.com] 
Sent: Sunday, April 10, 2005 10:02 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Re: Problem using MAKE



----- Original Message ----- 
From: arhodes19044
To: AVR-Chat@yahoogroups.com
Sent: Sunday, April 10, 2005 2:12 PM
Subject: [AVR-Chat] Re: Problem using MAKE



Running MAKE from DOS?  Oh, Oh.  In XP (home), all that I can do, as far
as I know, is open a DOS box.  I do not think that I can  drop into raw
DOS the way I could in 98.

Isn't a DOS box good enough?

I did get a DOS box to come up and I can CD to the demo directory.
>From there I can issue the MAKE command.  MAKE does run, but says it
can not see the makefile.  Of course the Makefile is right there in the
current directory.

Why would this be?

It does not even like the "clean" arg to follow the MAKE command.

I am a little mystified.


Just open a DOS box, that's what I do.

Here's what I get:

C:\WinAVR\examples\demo>make clean
rm -rf *.o demo.elf *.eps *.png *.pdf *.bak
rm -rf *.lst *.map *.hex *.bin *.srec

C:\WinAVR\examples\demo>make
avr-gcc -g -Wall -O2 -mmcu=atmega8    -c -o demo.o demo.c
avr-gcc -g -Wall -O2 -mmcu=atmega8  -Wl,-Map,demo.map -o demo.elf demo.o
avr-objdump -h -S demo.elf > demo.lst avr-objcopy -j .text -j .data -O
ihex demo.elf demo.hex avr-objcopy -j .text -j .data -O binary demo.elf
demo.bin avr-objcopy -j .text -j .data -O srec demo.elf demo.srec
avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O ihex demo.elf 
demo_eepr
om.hex
avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O binary demo.elf

demo_ee
prom.bin
avr-objcopy -j .eeprom --change-section-lma .eeprom=0 -O srec demo.elf 
demo_eepr
om.srec

C:\WinAVR\examples\demo>

Leon
--
Leon Heller, G1HSM
http://www.geocities.com/leon_heller 



 
Yahoo! Groups Links

On Sun, 10 Apr 2005 09:13:24 -0500 (CDT) you wrote:

>
>Kat, I hope you don't mind my posting an off-topic e-mail, but I thought 
>someone on this group might know the answer.
>
>I seem to be on everyone's spam list and I get the usual barrage of ads 
>for drugs, loans, Nigerian scams, etc. every day.  But lately I've gotten 
>a couple new types.
>
>The e-mails are purportedly from bluemountain.com, which is an e-card 
>service with e-mail greeting cards.  It says I've received a greeting 
>card.  The first time I got one I thought it was legit and clicked on the 
>link in the e-mail.  I got a "404 Not Found" screen which was part of the 
>website I went to (a dummy screen) and something else happened between my 
>computer and the other site.  I quickly disconnected from internet and 
>examined the e-mail more closely, looking at the source code, then 
>reconneced and went to www.dnsstuff.com to look at where the e-mail had 
>actually taken me.  As I suspected, it was some place in Wall, South 
>Dakota, not Bluemountain.com.
>
>The thing is, I have no idea what the site was set up to do.  Install 
>spyware?  Harvest e-mail addresses from my computer?  Any ideas?

One function they can have is email address validation. The mail sent to you
contains a code number which is sent to the site. It is compared to their list
from the mail sent out and your email address is marked as valid and active.

If you think a mail might be legitimate then I would save it and then open it in
notepad as a text file to examine it. That won't activate the links or send them
data.

--
Ralph Hilton
http://www.ralphhilton.org
C-Meter: http://www.cmeter.org
FZAOINT http://www.fzaoint.net

If have serveral strcmp statements

Originally I had them all like this.

if (strcmp("GPGGA",gcBuffer) == 0)
	{
	gpFieldPtr=(PGM_P) GGA;
	} 	

It would execute the pointer assignment on each of the 8 statements

I changed them to 

lnResult = strcmp("GPGLL",gcBuffer); 
if (lnResult == 0)
	{
	gpFieldPtr=GLL;
	}  

So I could see the result code of strcmp. This time it skipped the 1st 3
ok but then started doing the assignments. And when it got to the strcmp
that should have matched, lnResult was not 0 and yet it did the
assignment anyhow.

Anyone have any idea why?

Thanks for the suggestions.  I have checked some of them already.

I putposely kept the path to WinAVR short.  It resides on my F: 
drive right off the root.  F:\WinAVR.

No spaces the path afaik, but I will double check.

I tried compatibility mode on Make and it did not work.

I loaded winavr on my winxp pro at work and it was fine.

Don suggested to me to check for some other "make" elsewhere on the 
computer which is earlier in the path.  A VERY good sugggestion.  I 
will check for other make programs on the computer as soon as I get 
home.  This is the one thing I had not looked for before.  I am 
laying odds that this is the answer?  I will also move make.exe to 
the same directory as the project ans see if this does anything.

So far make works on both other computers I have tried it on.  Win 
98 and winxppro.

-Tony

--- In AVR-Chat@yahoogroups.com, Daniel Adolfsson <da@g...> wrote:
> arhodes19044 skrev:
> 
> >I re-re-loaded WinAVR and it does the same thing.  I used PN to 
try 
> >the make and it got the same results.
> >
> >I loaded WinAVR on my kids old computer and everything worked 
just 
> >as advertised.
> >
> >Maybe I will have to use their computer to do the work.  They 
will 
> >love it because they are not usually allowed on my computer.
> >
> >-Tony
> >  
> >
> This sounds like WXP problem, how do the path to your files look? 
How 
> long is it? Does i contain spaces in any folder names. for example 
> c:\projects\avr stuff\projectxx\
> in the above case make would probably look for the folder 
> c:\projects\avr with the parameters stuff\projectxx\
> 
> avr-gcc if i don't remember incorectly uses some cygwin dlls to 
run, I 
> have had problems with to long paths in old dos and in my version 
of 
> cygwin. They tend to be Truncated with a ~1
> ex 
> 
a:\path\to\my\files\that\is\by\far\too\long\may\cause\some\old\dos\so
ftware\and\cygwin\to\f***\up
> would be translated to for example
> a:\path\to\my\fil~1
> 
> also take a look in the propertiers of your make.exe try running 
it in 
> compatability mode and see if the information in there is correct 
(start 

> up path for example)
> 
> Daniel

arhodes19044 skrev:

>I re-re-loaded WinAVR and it does the same thing.  I used PN to try 
>the make and it got the same results.
>
>I loaded WinAVR on my kids old computer and everything worked just 
>as advertised.
>
>Maybe I will have to use their computer to do the work.  They will 
>love it because they are not usually allowed on my computer.
>
>-Tony
>  
>
This sounds like WXP problem, how do the path to your files look? How 
long is it? Does i contain spaces in any folder names. for example 
c:\projects\avr stuff\projectxx\
in the above case make would probably look for the folder 
c:\projects\avr with the parameters stuff\projectxx\

avr-gcc if i don't remember incorectly uses some cygwin dlls to run, I 
have had problems with to long paths in old dos and in my version of 
cygwin. They tend to be Truncated with a ~1
ex 
a:\path\to\my\files\that\is\by\far\too\long\may\cause\some\old\dos\software\and\cygwin\to\f***\up
would be translated to for example
a:\path\to\my\fil~1

also take a look in the propertiers of your make.exe try running it in 
compatability mode and see if the information in there is correct (start 
up path for example)

Daniel

My cygwin1.dll is in the \winavr\bin directory

-----Original Message-----
From: Daniel Adolfsson [mailto:da@glocalnet.net] 
Sent: Monday, April 11, 2005 3:06 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Re: Problem using MAKE - still no good



arhodes19044 skrev:

>I re-re-loaded WinAVR and it does the same thing.  I used PN to try
>the make and it got the same results.
>
>I loaded WinAVR on my kids old computer and everything worked just
>as advertised.
>
>Maybe I will have to use their computer to do the work.  They will
>love it because they are not usually allowed on my computer.
>
>-Tony
>  
>
This sounds like WXP problem, how do the path to your files look? How 
long is it? Does i contain spaces in any folder names. for example 
c:\projects\avr stuff\projectxx\
in the above case make would probably look for the folder 
c:\projects\avr with the parameters stuff\projectxx\

avr-gcc if i don't remember incorectly uses some cygwin dlls to run, I 
have had problems with to long paths in old dos and in my version of 
cygwin. They tend to be Truncated with a ~1
ex 
a:\path\to\my\files\that\is\by\far\too\long\may\cause\some\old\dos\softw
are\and\cygwin\to\f***\up
would be translated to for example
a:\path\to\my\fil~1

also take a look in the propertiers of your make.exe try running it in 
compatability mode and see if the information in there is correct (start

up path for example)

Daniel


 
Yahoo! Groups Links

On Apr 11, 2005, at 2:35 PM, arhodes19044 wrote:

> Don suggested to me to check for some other "make" elsewhere on the
> computer which is earlier in the path.  A VERY good sugggestion.  I
> will check for other make programs on the computer as soon as I get
> home.  This is the one thing I had not looked for before.  I am
> laying odds that this is the answer?  I will also move make.exe to
> the same directory as the project ans see if this does anything.

I wouldn't bother moving make.exe.

Quick way to find out what make is running type "make -v" in a 
command.com window to see what it says. No where near my WinAVR system 
but it should look something like this:

GNU Make 3.80
Copyright (C) 2002  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.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

> Quick way to find out what make is running type "make -v" in a
> command.com window to see what it says. No where near my WinAVR system
> but it should look something like this:

You should only be using command.com (which is a 16 bit shell) if
you're using Win9x. If you're using WinNT/2K/XP, you'll be much better
off using cmd.exe (whihch is a 32 bit shell). I set mine up to have a
virtual window that's 9999 rows high and 160 columns wide. Then you
can scroll back through old output and whatnot.

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

I have a weird problem. 
Same code as last night
	if (strcmp("GPVTG",gcBuffer) == 0 )
		{
		gpFieldPtr = (PGM_P) VTG;
		} 

When I look at the disembler and I have
+000019AE:   E461        LDI     R22,0x41         Load immediate
---- No Source
------------------------------------------------------------------------
------------
+000019AF:   E073        LDI     R23,0x03         Load immediate
+000019B0:   ED8C        LDI     R24,0xDC         Load immediate
+000019B1:   E091        LDI     R25,0x01         Load immediate
+000019B2:   940E2119    CALL    0x00002119       Call subroutine
+000019B4:   9700        SBIW    R24,0x00         Subtract immediate
from word
+000019B5:   F431        BRNE    PC+0x07          Branch if not equal

0x0341 is the address of gcBuffer and if I look in the memory view it
has GPVTG
0x01DC should be the address of the compare string. It should be GPVTG
but it has a bunch of unicode strings that read 
Atmega128 configured 0 KT  ETTINGS / Extended Fuse. If you leave out the
0 bytes between each letter.

I looks to be like AVR Studio overwrote some of my data memory. Any
anyone seen this before?

Do I have some kind of incorrect flag on my compiles or do I need to add
one to move the data somewhere?
-------- begin --------
avr-gcc (GCC) 3.4.1

avr-gcc -c -mmcu=atmega128 -I. -gdwarf-2   -O0 -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=ParseGPSData.lst  -std=gnu99
-Wp,-M,-MP,-MT,ParseGPSData.o,-MF,.dep/ParseGPSData.o.d ParseGPSData.c
-o ParseGPSData.o 

Linking: Robot.elf
avr-gcc -mmcu=atmega128 -I. -gdwarf-2   -O0 -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -Wall
-Wstrict-prototypes -Wa,-adhlns=Robot.o  -std=gnu99
-Wp,-M,-MP,-MT,Robot.o,-MF,.dep/Robot.elf.d Robot.o i2c.o motor.o
ringbuf.o sonar.o uart.o logeeprom.o ParseGPSData.o compass.o
--output Robot.elf -Wl,-Map=Robot.map,--cref  -Wl,-u,vfprintf
-lprintf_min -Wl,-u,vfscanf -lscanf_min -lm

Or is there something I am supposed to do in AVR Studio 4.1

On Sun, Apr 10, 2005 at 10:51:01PM -0400, wbounce wrote:

> If have serveral strcmp statements
> 
> Originally I had them all like this.
> 
> if (strcmp("GPGGA",gcBuffer) == 0)
>       {
>       gpFieldPtr=(PGM_P) GGA;
>       }      
> 
> It would execute the pointer assignment on each of the 8 statements
> 
> I changed them to
> 
> lnResult = strcmp("GPGLL",gcBuffer);
> if (lnResult == 0)
>       {
>       gpFieldPtr=GLL;
>       } 
> 
> So I could see the result code of strcmp. This time it skipped the 1st 3
> ok but then started doing the assignments. And when it got to the strcmp
> that should have matched, lnResult was not 0 and yet it did the
> assignment anyhow.
> 
> Anyone have any idea why?

I'm not sure about the problem, but just a quick observation.  With
AVR-GCC, string references like above consume both Flash as well as
precious RAM.  It can add up quickly, too.  To rewrite those to save
RAM space, try:

    strcmp_P(PSTR("GPGLL"),gcBuffer);

This references the string data directly from Flash and saves making a
copy of it to RAM.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers
http://www.bdmicro.com/

Thanks for the info.  I have been using cmd.exe.  I have also been 
trying to use make with the Programmers Notepad.  Both techniques fail 
in the same way.  Make tries to run, but it fails.

I quadruple checked the path.  It is fine.  I even moved the winavr 
references to the front of the path.  I even deleted all the rest of 
the path EXCEPT the winavr stuff.  No change.

I then deleted the entire path.  In this case make could not be found.

I then moved make into the current (demo) directory.  Then make WORKED 
FINE.  

So, it has someting to do with the path, but I do not know what.  I am 
running winavr from my F: drive, not the C: drive.  Maybe this has 
something to do with it.   

I may have to move the winavr directory to the c: drive and test it 
there.

Any ideas why the path would not work right?

-Tony


--- In AVR-Chat@yahoogroups.com, Dave Hylands <dhylands@g...> wrote:
> > Quick way to find out what make is running type "make -v" in a
> > command.com window to see what it says. No where near my WinAVR 
system
> > but it should look something like this:
> 
> You should only be using command.com (which is a 16 bit shell) if
> you're using Win9x. If you're using WinNT/2K/XP, you'll be much 
better

> off using cmd.exe (whihch is a 32 bit shell). I set mine up to have a
> virtual window that's 9999 rows high and 160 columns wide. Then you
> can scroll back through old output and whatnot.
> 
> -- 
> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/

Hi Tony,

> Any ideas why the path would not work right?

What's the exact output when it fails?

What path are you using?

How are you setting the PATH?

If you're using cmd.exe, you can click on the icon in the top left and
choose properties, and  then under options make sure QuickEdit is
selected.

Then you can drag your mouse over the window to select text and press
Enter. This will copy the selected text into the clipboard. You can
paste text into the window using a right-click.

Just be careful using QuickEdit though. If you click in the window and
the title bar changes to "Select ..." then all output to the window
stops under you press ENTER or ESC.

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

Here is the error report from make:

----------------------------------------
> "make.exe" all
make.exe: *** No rule to make target `all'.  Stop.

> Process Exit Code: 2
---------------------------------------------------

My path is:

%SYSTEMROOT%\system32;%SYSTEMROOT%;%SYSTEMROOT%\system32
\WBEM;F:\winavr\bin;F:\winavr\utils\bin;C:\PROGRA~1\ATITEC~1
\ATICON~1;C:\Program Files\ATI Technologies\ATI Control Panel


---------------------------------------------------------

I even modified the path to only point to the winavr directories in 
case some of the other entries screwed it up.  No change in its 
actions.  Maybe it is related to being on the F drive and something 
in make expects the C drive.

When I put a copy of the make utility directly in the current 
directory (demo), then make worked fine.

There are no other instances of make elsewhere on my computer, so 
some other make is not interfering with the correct one.  I have not 
yet moved the winavr directory to the C drive, and I will not be 
doing that any time soon.  That drive is getting flaky and needs to 
be replaced.

So, I have worked-around the issue by putting a copy of the make 
utility in each project directory.  Not pretty but it works.

Any ideas from anyone now?  I am fresh out of ideas of what is wrong.

-Tony


--- In AVR-Chat@yahoogroups.com, Dave Hylands <dhylands@g...> wrote:
> Hi Tony,
> 
> > Any ideas why the path would not work right?
> 
> What's the exact output when it fails?
> 
> What path are you using?
> 
> How are you setting the PATH?
> 
> If you're using cmd.exe, you can click on the icon in the top left 
and
> choose properties, and  then under options make sure QuickEdit is
> selected.
> 
> Then you can drag your mouse over the window to select text and 
press
> Enter. This will copy the selected text into the clipboard. You can
> paste text into the window using a right-click.
> 
> Just be careful using QuickEdit though. If you click in the window 
and

> the title bar changes to "Select ..." then all output to the window
> stops under you press ENTER or ESC.
> 
> -- 
> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/

Thanks Brain for the suggestion. I did that and AVR Studio is still
messed up. 

-----Original Message-----
From: Brian Dean [mailto:bsd@bdmicro.com] 
Sent: Tuesday, April 12, 2005 1:18 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Strcmp() problem stepping through AVR Studio



On Sun, Apr 10, 2005 at 10:51:01PM -0400, wbounce wrote:

> If have serveral strcmp statements
> 
> Originally I had them all like this.
> 
> if (strcmp("GPGGA",gcBuffer) == 0)
>       {
>       gpFieldPtr=(PGM_P) GGA;
>       }      
> 
> It would execute the pointer assignment on each of the 8 statements
> 
> I changed them to
> 
> lnResult = strcmp("GPGLL",gcBuffer);
> if (lnResult == 0)
>       {
>       gpFieldPtr=GLL;
>       }
> 
> So I could see the result code of strcmp. This time it skipped the 1st

> 3 ok but then started doing the assignments. And when it got to the 
> strcmp that should have matched, lnResult was not 0 and yet it did the

> assignment anyhow.
> 
> Anyone have any idea why?

I'm not sure about the problem, but just a quick observation.  With
AVR-GCC, string references like above consume both Flash as well as
precious RAM.  It can add up quickly, too.  To rewrite those to save RAM
space, try:

    strcmp_P(PSTR("GPGLL"),gcBuffer);

This references the string data directly from Flash and saves making a
copy of it to RAM.

-Brian
-- 
Brian Dean
BDMICRO - ATmega128 Based MAVRIC Controllers http://www.bdmicro.com/


 
Yahoo! Groups Links

Woops - looks like I told you the order wrong for strcmp_P(), should
be:

	strcmp_P(gcBuffer, PSTR("GPGLL"));

Sorry about that.

Also, I wasn't really suggusting this as a fix to the problem you are
seeing, though there was an off chance that it could help if you were
running out of RAM.  Strange things happing when your stack grows down
into your variable space.

It was more the case that it can save you lots of RAM if you have many
strcmp()'s using constant strings.

-Brian

On Tue, Apr 12, 2005 at 09:30:18PM -0400, wbounce wrote:
> DomainKey-Signature: 
> To: <AVR-Chat@yahoogroups.com>
> From: "wbounce" <wbounce@safeplace.net>
> Date: Tue, 12 Apr 2005 21:30:18 -0400
> Subject: RE: [AVR-Chat] Strcmp() problem stepping through AVR Studio
> 
> Thanks Brain for the suggestion. I did that and AVR Studio is still
> messed up.

On Apr 12, 2005, at 10:05 PM, arhodes19044 wrote:

> Here is the error report from make:
>
> ----------------------------------------
>> "make.exe" all
> make.exe: *** No rule to make target `all'.  Stop.
>
>> Process Exit Code: 2
> ---------------------------------------------------

[...]

> Any ideas from anyone now?  I am fresh out of ideas of what is wrong.

Your error message makes perfect sense. The rule tree for the target 
"all" is incomplete. From the make.info document:

`No rule to make target `XXX'.'
`No rule to make target `XXX', needed by `YYY'.'
      This means that `make' decided it needed to build a target, but
      then couldn't find any instructions in the makefile on how to do
      that, either explicit or implicit (including in the default rules
      database).

I *know* the following Makefile works. Save it as "Makefile", 
capital-M. Also either create an empty file named ".depend" (dot 
depend) or comment out the last line. If you "make depend" then a new 
.depend will be created including all the #include dependancies it 
found in your sources. Make sure the indented lines are indented with 
tabs. Some makes are sensitive, some are not. I forgot which way GNU 
make permits/requires.

Very little editing would be needed to convert this to your project. 
Just the MCU line, SRCS, and change "object.elf", "object.bin", and 
"object.list" if you don't like that name for the final product.

#
#$Id: Makefile,v 1.27 2005/03/22 22:31:36 dkelly Exp $
#
CC= avr-gcc
#MCU=atmega8
#MCU=atmega16
#MCU=atmega32
#MCU=atmega163
#MCU=atmega323
#MCU=atmega64
MCU=atmega128

CFLAGS= -O -gdwarf-2 -Wall -ffreestanding -mmcu=$(MCU)
LDFLAGS= -Wl,-Map,$@.map

.SUFFIXES:
.SUFFIXES: .c .o .bin .elf .hex .srec .list

.c.o:
	$(CC) $(CFLAGS) -c $<

.elf.bin:
	avr-objcopy -R .eeprom -O binary $< $@

.elf.hex:
	avr-objcopy -O ihex $< $@

.elf.srec:
	avr-objcopy -O srec $< $@

#
#  This is a fun conversion, creates an assembly dump
#  including C source lines interspersed as comments.
#
.elf.list:
	avr-objdump -DS $< > $@

#  one per line makes CVS diffs easier to read
SRCS = \
	main.c \
	uarts.c \
	timers.c \
	cmm.c \
	cmm_cmd.c \
	misc.c \
	it.c \
	eeprom.c

OBJS = $(SRCS:.c=.o)

all:	object.elf object.bin object.list

object.elf: $(OBJS)
	$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS)
	avr-size $@

clean:
	rm -f *~ *.elf *.cof *.bin *.hex *.srec *.s *.o *.pdf *core *.list 
*.map

# BSD make automatically reads .depend if it exists
depend: $(SRCS)
	$(CC) -E -M $(SRCS) > .depend

# GNU make apparently must be told to include .depend
include .depend


--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

Hi Tony,

> My path is:
> 
> %SYSTEMROOT%\system32;%SYSTEMROOT%;%SYSTEMROOT%\system32
> \WBEM;F:\winavr\bin;F:\winavr\utils\bin;C:\PROGRA~1\ATITEC~1
> \ATICON~1;C:\Program Files\ATI Technologies\ATI Control Panel

It sounds like there's a make.exe that's in one of these directories:
%SYSTEMROOT%\system32
%SYSTEMROOT%;%SYSTEMROOT%\system32\WBEM
F:\winavr\bin

and it's not compatible with the make that comes with WinAVR.

Putting the make.exe into the "current" directory causes the correct
one to be executed.

Try removing the make.exe and try this instead:

f:\winavr\utils\bin\make

iIf that works and typing make by itself doesn't, then there's almost
certainly another make earlier in your path.

-- 
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/

--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:
> 
> Here is the error report from make:
> 
> ----------------------------------------
> > "make.exe" all
> make.exe: *** No rule to make target `all'.  Stop.
> 
> > Process Exit Code: 2
> ---------------------------------------------------
> 

Hmmm, I had exactly the same problem lately. If only I would remember 
what I did to fix it....

Did you install WinAVR as a user or with admin rights?

Stefan

I installed it with administrator rights.

-Tony

--- In AVR-Chat@yahoogroups.com, "Stefan Wimmer" <yahoo@w...> wrote:

> Hmmm, I had exactly the same problem lately. If only I would remember 
> what I did to fix it....
> 
> Did you install WinAVR as a user or with admin rights?
> 
> Stefan

Great idea.  I did not thnk of that myself,  but it was suggested to 
me before.  When I heard that suggestion I was POSITIVE that it was 
the problem.  Unfortunately it is NOT the case.  I scoured my 
computer for another make program.  Did not find one.  I was STILL so 
sure that I deleted the entire path except the winavr references.  No 
difference.

I still suspect that make is confused by the fact that it does not 
reside on the C drive, and it expects to be there in some basic way.

-Tony

--- In AVR-Chat@yahoogroups.com, Dave Hylands <dhylands@g...> wrote:
> Hi Tony,
> 
> > My path is:
> > 
> > %SYSTEMROOT%\system32;%SYSTEMROOT%;%SYSTEMROOT%\system32
> > \WBEM;F:\winavr\bin;F:\winavr\utils\bin;C:\PROGRA~1\ATITEC~1
> > \ATICON~1;C:\Program Files\ATI Technologies\ATI Control Panel
> 
> It sounds like there's a make.exe that's in one of these 
directories:
> %SYSTEMROOT%\system32
> %SYSTEMROOT%;%SYSTEMROOT%\system32\WBEM
> F:\winavr\bin
> 
> and it's not compatible with the make that comes with WinAVR.
> 
> Putting the make.exe into the "current" directory causes the correct
> one to be executed.
> 
> Try removing the make.exe and try this instead:
> 
> f:\winavr\utils\bin\make
> 
> iIf that works and typing make by itself doesn't, then there's 
almost

> certainly another make earlier in your path.
> 
> -- 
> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/

I will try out your makefikle as soon as I get home.  I will look at 
those suffix lines on my version of the makefile to see if I can tell 
why the path is an issue.

The makefile must assume SOMETHING about SOMETHING so that the path 
to F: will not work, but C: will work.  

In what way does your Makefile differ from the makefile included with 
the AVR demo project?

That makefile is sufficiently opaque that I really do understall all 
of what it is doing.

I wonder if I use Mfile to create a new makefile whether this will be 
a functional makefile.

-Tony


--- In AVR-Chat@yahoogroups.com, David Kelly <dkelly@h...> wrote:
> 
> On Apr 12, 2005, at 10:05 PM, arhodes19044 wrote:
> 
> > Here is the error report from make:
> >
> > ----------------------------------------
> >> "make.exe" all
> > make.exe: *** No rule to make target `all'.  Stop.
> >
> >> Process Exit Code: 2
> > ---------------------------------------------------
> 
> [...]
> 
> > Any ideas from anyone now?  I am fresh out of ideas of what is 
wrong.
> 
> Your error message makes perfect sense. The rule tree for the 
target 
> "all" is incomplete. From the make.info document:
> 
> `No rule to make target `XXX'.'
> `No rule to make target `XXX', needed by `YYY'.'
>       This means that `make' decided it needed to build a target, 
but
>       then couldn't find any instructions in the makefile on how to 
do
>       that, either explicit or implicit (including in the default 
rules
>       database).
> 
> I *know* the following Makefile works. Save it as "Makefile", 
> capital-M. Also either create an empty file named ".depend" (dot 
> depend) or comment out the last line. If you "make depend" then a 
new 
> .depend will be created including all the #include dependancies it 
> found in your sources. Make sure the indented lines are indented 
with 
> tabs. Some makes are sensitive, some are not. I forgot which way 
GNU 
> make permits/requires.
> 
> Very little editing would be needed to convert this to your 
project. 
> Just the MCU line, SRCS, and change "object.elf", "object.bin", and 
> "object.list" if you don't like that name for the final product.
> 
> #
> #$Id: Makefile,v 1.27 2005/03/22 22:31:36 dkelly Exp $
> #
> CC= avr-gcc
> #MCU=atmega8
> #MCU=atmega16
> #MCU=atmega32
> #MCU=atmega163
> #MCU=atmega323
> #MCU=atmega64
> MCU=atmega128
> 
> CFLAGS= -O -gdwarf-2 -Wall -ffreestanding -mmcu=$(MCU)
> LDFLAGS= -Wl,-Map,$@.map
> 
> .SUFFIXES:
> .SUFFIXES: .c .o .bin .elf .hex .srec .list
> 
> .c.o:
> 	$(CC) $(CFLAGS) -c $<
> 
> .elf.bin:
> 	avr-objcopy -R .eeprom -O binary $< $@
> 
> .elf.hex:
> 	avr-objcopy -O ihex $< $@
> 
> .elf.srec:
> 	avr-objcopy -O srec $< $@
> 
> #
> #  This is a fun conversion, creates an assembly dump
> #  including C source lines interspersed as comments.
> #
> .elf.list:
> 	avr-objdump -DS $< > $@
> 
> #  one per line makes CVS diffs easier to read
> SRCS = \
> 	main.c \
> 	uarts.c \
> 	timers.c \
> 	cmm.c \
> 	cmm_cmd.c \
> 	misc.c \
> 	it.c \
> 	eeprom.c
> 
> OBJS = $(SRCS:.c=.o)
> 
> all:	object.elf object.bin object.list
> 
> object.elf: $(OBJS)
> 	$(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(OBJS) $(LDLIBS)
> 	avr-size $@
> 
> clean:
> 	rm -f *~ *.elf *.cof *.bin *.hex *.srec *.s *.o *.pdf *core 
*.list 
> *.map
> 
> # BSD make automatically reads .depend if it exists
> depend: $(SRCS)
> 	$(CC) -E -M $(SRCS) > .depend
> 
> # GNU make apparently must be told to include .depend
> include .depend
> 
> 
> --
> David Kelly N4HHE, dkelly@H...
> 
======================================================================
==
> Whom computers would destroy, they must first drive mad.

On Wed, Apr 13, 2005 at 05:33:20PM -0000, Stefan Wimmer wrote:
> 
> 
> --- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:
> > 
> > Here is the error report from make:
> > 
> > ----------------------------------------
> > > "make.exe" all
> > make.exe: *** No rule to make target `all'.  Stop.
> > 
> > > Process Exit Code: 2
> > ---------------------------------------------------
> > 
> 
> Hmmm, I had exactly the same problem lately. If only I would remember 
> what I did to fix it....

The problem is that make can't find a combination of its SUFFIXES rules
combined with the files it can find in its current directory to create
the files listed on the all: target.

The Makefile I posted explicitly wipes the SUFFIXES rules make inherits,
then defines its own list of SUFFIXES and rules for converting from one
suffix to another. This sort of thing is particularly important when
using make for something slightly different than its usual native
purpose. In this case for creation of cross-compiled code.

By spelling out exactly the rules I want make to use I should have far
less problems in the future maintaining the code if anything in my
environment changes. The exact same Makefile produces the exact same
code with GNU Make on both FreeBSD and WinXP, and with BSD make on
FreeBSD.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:
> I still suspect that make is confused by the fact that it does not 
> reside on the C drive, and it expects to be there in some basic way.

I have WinAVR installed on a D: drive.  That's also where my WinNT 
directory is.  Even if the system directory were on a different 
drive, though, it shouldn't matter.

Don't forget that on NT variants (Win2K, XP, etc.) there are actually 
two different sets of path information.  One for the system and one 
for the user.  The effective path for any particular user is the 
combination of the two.  To see what the combined path is just type 
PATH followed by the Enter key at the DOS prompt.


> 
> -Tony
> 
> --- In AVR-Chat@yahoogroups.com, Dave Hylands <dhylands@g...> wrote:
> > Hi Tony,
> > 
> > > My path is:
> > > 
> > > %SYSTEMROOT%\system32;%SYSTEMROOT%;%SYSTEMROOT%\system32
> > > \WBEM;F:\winavr\bin;F:\winavr\utils\bin;C:\PROGRA~1\ATITEC~1
> > > \ATICON~1;C:\Program Files\ATI Technologies\ATI Control Panel
> > 
> > It sounds like there's a make.exe that's in one of these 
> directories:
> > %SYSTEMROOT%\system32
> > %SYSTEMROOT%;%SYSTEMROOT%\system32\WBEM
> > F:\winavr\bin
> > 
> > and it's not compatible with the make that comes with WinAVR.
> > 
> > Putting the make.exe into the "current" directory causes the 
correct

> > one to be executed.
> > 
> > Try removing the make.exe and try this instead:
> > 
> > f:\winavr\utils\bin\make
> > 
> > iIf that works and typing make by itself doesn't, then there's 
> almost
> > certainly another make earlier in your path.
> > 
> > -- 
> > Dave Hylands
> > Vancouver, BC, Canada
> > http://www.DaveHylands.com/

On Apr 13, 2005, at 5:43 PM, Don Kinzer wrote:

>> I still suspect that make is confused by the fact that it does not
>> reside on the C drive, and it expects to be there in some basic way.
>
> I have WinAVR installed on a D: drive.  That's also where my WinNT
> directory is.  Even if the system directory were on a different
> drive, though, it shouldn't matter.

My "XP Pro Service Pack 1" WinAVR (of Feb 2005 vintage) is on 
F:\WinAVR\ same as Tony. And mine works without any editing of PATH 
other than that which the WinAVR installer performed.

Make is being found. Make isn't finding something it needs. I don't 
know where GNU Make picks up its default ruleset but I believe therein 
lies Tony's problem. The Makefile I posted nukes all (or at least most 
of) the default rules and establishes its own.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

--- In AVR-Chat@yahoogroups.com, Dave Hylands <dhylands@g...> wrote:
> 
> Try removing the make.exe and try this instead:
> 
> f:\winavr\utils\bin\make

> Dave Hylands
> Vancouver, BC, Canada
> http://www.DaveHylands.com/

I did this as you said.  Here is the result.
--------------------------------------------------------

F:\WinAVR\Project_RealTime>make clean

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

Cleaning project:
rm -f realtime.hex
rm -f realtime.eep
rm -f realtime.cof
rm -f realtime.elf
rm -f realtime.map
rm -f realtime.sym
rm -f realtime.lss
rm -f realtime.o  F:/WinAVR/AVRlib/timer128.o
rm -f realtime.lst  F:/WinAVR/AVRlib/timer128.lst
rm -f realtime.s  F:/WinAVR/AVRlib/timer128.s
rm -f realtime.d  F:/WinAVR/AVRlib/timer128.d
rm -f .dep/*
-------- end --------


F:\WinAVR\Project_RealTime>f:\winavr\utils\bin\make.exe clean
f:\winavr\utils\bin\make.exe: *** No rule to make target `clean'.  
Stop.

--------------------------------------------------------------

So, when I use the make program in the current directory it works.  
When I use it while it resides elsewhere, it gags.

No other make programs (exe or com) exist elsewhere, and especially 
not in the path.

I am totally confused, but I can make it work by keeping a version 
of make in the current directory.  I guess I will continue this work-
around....

I find that I need to keep AVRLib H and C files in the current 
directory.  It makes references more simple.....

-Tony

--- In AVR-Chat@yahoogroups.com, "arhodes19044" <spamiam@c...> wrote:
 
> I still suspect that make is confused by the fact that it does not 
> reside on the C drive, and it expects to be there in some basic 
way.
 
Hi Tony,

this is definitely not hte case. I have WinAVR sitting on drive D: 
ands everything wokts after I came over exactly the same problems 
you now have.

One thin I had to do was to weed out my path variable. I have now 
this line as the first in my autoexec.bat in the root directory of 
the boot drive (C: in my case):
PATH C:\WINDOWS;C:\WINDOWS\COMMAND;C:\PROGRA~1
\ULTRAE~1;D:\AVRGCC\WINAVR\BIN;D:\AVRGCC\WINAVR\UTILS\BIN

This autoexec.bat is called when a DOS program is launched.

How does your path look like?

Stefan