AVR32 tools on Cygwin - make: command not found

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sure my issue demonstrates my lack of experience with embedded linux, the AVR32 tool chain and cygwin but I'm out of options at this point so here it goes...

I originally got cygwin installed manually (so I could get nano) and was able to create an example to build for AVR32 linux - i.e. hello world.

Somewhere along the line I installed WINAVR and when I went back into cygwin to make my AVR32 linux example I got some error related to WINAVR make.

I uninstalled WINAVR, and tried again with no success. Then I tried reinstalling the BSP1.0 with my existing cygwin environment which didn't work either. Then I tried completely removing BSP1.0 and reinstalling which didn't work either.

Then I tried completely removing cygwin and BSP1.0 and reinstalling both fresh. However now when I try to build my example the bash shell complains that it can't find the make command.

$ make
bash: make: command not found

I could use some help here ...

my next step is to try to unistall and manually clean out my registry to really remove cygwin (in the registry and removing the c:\cygwin folder and try fresh again.

Any idea what might be wrong and more importantly how I might be able to correct it.

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

Is there a make.exe in your c:\cygwin\bin\?
If you have that file - then your PATH is wrong, add c:\cygwin\bin\.
If you have no make.exe - for some reason it was not installed when you install cygwin.
I used setup.exe from official site to install cygwin, with it you can simply select to reinstall make, press Continue and bob's your uncle.

Make is a part of cygwin, don't know how is it related to WINAVR.

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

When you install WINAVR, it has its own make packaged in with it and it adds its bin directory to the system $PATH. It sounds like when Cygwin resolves make it incorrectly gives priority to the WINAVR entry in $PATH. You can either explicitly state which make to use (run /cygdrive/c/cygwin/bin/make rather than just make, I know it's a long one!) or better, check your $PATH and reorder the entries such that the Cygwin bin directory has higher priority. This all assumes you have done as p@ko has suggested and make sure make is really in your cygwin bin directory! If it isn't, setup.exe from the cygwin website can reinstall all the make tools and hopefully fix it all.

I have Cygwin and WINAVR running happily here, I haven't had a problem, so it certainly can be done!

S.

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

Thanks p@ko - I was able to find make in the cygwin installer and get it added it...

now I get a path problem that didn't exist when I first got my hello world to compile.

my hello.c file below is in /tmp/hello
#include
#include

int main(int argc, char** argv)
{
int i = 0;
int j = 0;
for(i = 0; i==1000; i++)
{
j+=i; // Add I to J ever iteration
}
printf("Hello World!\n");
return 0;

}

$ make
avr32-linux-gcc -Wall -g -c -o hello.o hello.c
hello.c:2:22: error: avr32/io.h: No such file or directory
make: *** [hello.o] Error 1

I seem to have a path problem with the tools as this did compile under cygwin and run on my stk1000 before.

I can explicitly point to the correct header file but I'm not sure which one
io.h sits in
/usr/local/avr32/include/avr32
/usr/local/avr32-linux/include/asm
/usr/local/avr32-linux/include/asm-avr32
/usr/local/avr32-linux/include/linux
/usr/local/avr32-linux/include/sys
and cygwin has its own version under:
/usr/include

I assume I might have a problem with stdio.h as well as it sits in:
under cygwin:
/usr/include
/usr/include/sys
under the AVR tool path
/usr/local/avr32/include
/usr/local/avr32/include/sys
/usr/local/avr32-linux/include
/usr/local/avr32-linux/include/bits

it seems as though there is there some path that is not setup correctly in cygwin for the BSP tools...

so I have 2 questions:
1.) Assuming I'm comiling it for avr32-linux which stdio.h & io.h headers should I be including?
2.) What path information needs to in the cygwin environment so that it will compile as my originally installed tools did it i.e. using the original paths in my source file?

Thanks for the help thus far - at least I'm making some progress....

ELO

my makefile is listed below for reference
TARGET=hello.elf
OBJECTS=hello.o
CC=avr32-linux-gcc
CFLAGS=-Wall -g # warnings, debugging symbols
LDFLAGS=-static
LIBS=

.PHONY: all
all: $(TARGET)

$(TARGET): $(OBJECTS)
$(CC) $(LDFLAGS) -o $@ $^ $(LIBS)

.PHONY: clean
clean:
-$(RM) $(TARGET) $(OBJECTS)

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

The easiest way is to use command
avr32-linux-gcc -Wall -g -c -o hello.o hello.c -I/usr/local/avr32-linux/include/

You may set

CFLAGS=-Wall -g -I/usr/local/avr32-linux/include/

to get the same result.

Since your avr32-linux-gcc fails to find
I think it is not configured correctly.
If you copy your /usr/local/avr32-linux/ folder to /usr/avr32-linux/ it will work (I think), but that's not the best solution.

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

The question is why doesn't this install to the correct path then in my subsequent "fresh" install?

I find it a bit peculiar that when I first installed I was able to generate & compile this relatively quickly

It almost seems like the BSP 1.0 tools installer doesn't properly set up some path environment variables.

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

Woha, there is not any #include for the Linux compiler (avr32-linux-gcc). The avr32/io.h is for standalone applications, using avr32-gcc. There are no headers for accessing the low level bitfields in the modules, since they will not be accessable from userspace in Linux.

If you want to do something with a peripheral in Linux you will have to write a driver. Atmel has already provided drivers for most of the hardware on the AP7000 already, so have a look in the menuconfig for the kernel :)

Hans-Christian