So here is the error:

C:\Nerdkits\Code\Current1>make
cc     main.c   -o main
process_begin: CreateProcess(NULL, cc main.c -o main, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [main] Error 2

And here is the MakeFile:

GCCFLAGS=-g -Os -Wall -mmcu=atmega328p 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm

AVRDUDEFLAGS=-c avr109 -p m328p -F -b 115200 -P com3

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

MCU=atmega328p
ProjectName=main

all:    $(ProjectName)

$(ProjectName).hex: $(ProjectName).c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o $(ProjectName).o $(ProjectName).c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex $(ProjectName).o $(ProjectName).hex

$(ProjectName).ass: $(ProjectName).hex
    avr-objdump -S -d $(ProjectName).o > $(ProjectName).ass

$(ProjectName)-upload:  $(ProjectName).hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:$(ProjectName).hex:a

    avr-size -B $(ProjectName).hex

The MakeFile is one I just grabbed from another folder I do not know if it ever worked :-(

Anybody see any thing obvious or can you interpret the error code for me so I know where to look. I am not sure what line it is failing on.

Thanks,

Ralph

Well I switched to a known working MakeFile, now I get this for errors:

C:\Nerdkits\Code\Current1>make
make -C ../libnerdkits
make[1]: Entering directory `C:/Nerdkits/Code/libnerdkits'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `C:/Nerdkits/Code/libnerdkits'
avr-gcc -g -Os -Wall -mmcu=atmega328p  -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfsca
nf -lscanf_flt -lm -o main.o main.c ../libnerdkits/delay.o ../libnerdkits/lcd.o
../libnerdkits/uart.o
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccw3C4Ch.o: In function `main':
C:\Nerdkits\Code\Current1/main.c:32: undefined reference to `adc_setchannel'
C:\Nerdkits\Code\Current1/main.c:33: undefined reference to `adc_init'
C:\Nerdkits\Code\Current1/main.c:43: undefined reference to `adc_read'
C:\Nerdkits\Code\Current1/main.c:44: undefined reference to `adc_emafilter'
C:\Nerdkits\Code\Current1/main.c:48: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:48: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:48: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:50: undefined reference to `adc_getresistence'
C:\Nerdkits\Code\Current1/main.c:52: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:52: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:52: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:56: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:56: undefined reference to `uart_puts'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccw3C4Ch.o:C:\Nerdkits\Code\Current1/main.c:5
6: more undefined references to `uart_puts' follow
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccw3C4Ch.o: In function `main':
C:\Nerdkits\Code\Current1/main.c:57: undefined reference to `acs712_getcurrent'
C:\Nerdkits\Code\Current1/main.c:61: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:61: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:61: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:63: undefined reference to `uart_puts'
make: *** [main.hex] Error 1

Here are my #includes:

#include "uart/uart.h"

#include "adc/adc.h"

#include "acs712/acs712.h"

What is the correct syntax for the path for the GCC compiler?

I'd take the answer about the first MakeFile if anyone chatches it.

Ralph

Ralph -

Can't be sure about this but in the second case it looks like the object files associated with "adc.h" and "acs712.h" (the adc.o and acs712.o files) aren't included in the LINKOBJECTS line. I'm not sure where the function "uart_puts" is located but you may need to include that object file as well. I'm assuming the 3 files that are part of your "include" statements are in sub directories below your project directory (or you may need the "../" modifier).

In the first case, it looks like a whole other compiler is being called, maybe one on your system that is in the default search path. I noticed the line...

all:    $(ProjectName)

is calling a make file "rule" that doesn't exist since it will expand to...

all: main

and all your rules (expanded) are:

main.hex:
main.ass:
main-upload

You may need to re-write it to:

all: $(ProjectName)-upload   or   all: $(ProjectName).hex

Thanks pcbolt!

Here is my known working MakeFile that I am using now:

GCCFLAGS=-g -Os -Wall -mmcu=atmega328p 
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt -lm

AVRDUDEFLAGS=-c avr109 -p m328p -b 115200 -P com3

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

all:    main-upload

main.hex:   main.c
    make -C ../libnerdkits
    avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o main.o main.c ${LINKOBJECTS}
    avr-objcopy -j .text -O ihex main.o main.hex

main.ass:   main.hex
    avr-objdump -S -d main.o > main.ass

main-upload:    main.hex
    avrdude ${AVRDUDEFLAGS} -U flash:w:main.hex:

And here are my current errors:

C:\Nerdkits\Code\Current1>make
make -C ../libnerdkits
make[1]: Entering directory `C:/Nerdkits/Code/libnerdkits'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `C:/Nerdkits/Code/libnerdkits'
avr-gcc -g -Os -Wall -mmcu=atmega328p  -Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf
_flt -lm -o main.o main.c ../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.
o
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccqW0oae.o: In function `main':
C:\Nerdkits\Code\Current1/main.c:33: undefined reference to `adc_setchannel'
C:\Nerdkits\Code\Current1/main.c:34: undefined reference to `adc_init'
C:\Nerdkits\Code\Current1/main.c:44: undefined reference to `adc_read'
C:\Nerdkits\Code\Current1/main.c:45: undefined reference to `adc_emafilter'
C:\Nerdkits\Code\Current1/main.c:49: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:49: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:49: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:51: undefined reference to `adc_getresistence'
C:\Nerdkits\Code\Current1/main.c:53: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:53: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:53: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:57: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:57: undefined reference to `uart_puts'
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccqW0oae.o:C:\Nerdkits\Code\Current1/main.c:57: more un
defined references to `uart_puts' follow
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp/ccqW0oae.o: In function `main':
C:\Nerdkits\Code\Current1/main.c:58: undefined reference to `acs712_getcurrent'
C:\Nerdkits\Code\Current1/main.c:62: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:62: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:62: undefined reference to `uart_puts'
C:\Nerdkits\Code\Current1/main.c:64: undefined reference to `uart_puts'
make: *** [main.hex] Error 1

It appears my #include path is working, but maybe not:

#include "uart/uart.h"
#include "adc/adc.h"
#include "acs712/acs712.h"

Now re: "it looks like the object files associated with "adc.h" and "acs712.h" (the adc.o and acs712.o files) aren't included in the LINKOBJECTS line. "

There are no .o (object) files!! Should these preexist I have an adc.c, uart.c and acs712.c file so I might be able to compile them and make the object files. I thought the compiler would make them automatically. Do I tell the compiler to make them in the MakeFile LINKOBJECTS= line?

re: "I'm not sure where the function "uart_puts" is located"

uart_puts is in Root/uart/uart.h (#include "uart/uart.h")

extern void uart_puts(const char *s );

All of the "undefined references" are in their associated .h files (at least all that I have checked so far).

So I think my newest question is what about those .o (object) files. Do I need to pre make them?

Ralph

Ralph -

I don't think the compiler will automatically compile any of the adc.c, uart.c, acs712.c files without you telling it to. Also, it won't link them into your final upload file without you telling it to. In your last post, I would take this line...

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o

And add

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o ../libnerdkits/uart.o
LINKOBJECTS+=uart/uart.o adc/adc.o acs712/acs712.o

At this point the compiler will complain that it can't find the .o files unless you put in a rule to create them. You can create a new rule and put it at the end of you make file like this...

adc/adc.o: adc/adc.c
    avr-gcc ${GCCFLAGS} -o adc/adc.o -c adc/adc.c

If you precompile adc.o you won't need to do this. This applies to the other two files as well. There are slicker ways to do this but you'd have to get Noter to tell you how.

I "tried" pre-compiling adc.c etc but that failed. I "thought" I had done that before on another project but can not remember exactly how I did it.

So Paul you still around, anything to add? I sure would appreciate the help and thanks pcbolt I will try your modifications.

Ralph

Since it's a one time compile, do it manually instead of using a make file. In a command window navigate to where uart.c resides and compile with this command:

        avr-gcc -g -Os -c -Wall -mmcu=atmega328p uart.c -o uart.o

Then do the same for the other two changing the command for their specific names ...

        avr-gcc -g -Os -c -Wall -mmcu=atmega328p adc.c -o adc.o

        avr-gcc -g -Os -c -Wall -mmcu=atmega328p acs712.c -o acs712.o

Then add the objects to your main makefile like pcbolt shows in his post -

LINKOBJECTS+=uart/uart.o adc/adc.o acs712/acs712.o

If you find you are changing uart.c, adc.c, or acs712.c often then consider creating makefiles for each of them but compile only, no linking.

Hello Ralph,

I am pretty sure that part of your problem is with your include files as well?

    #include "uart/uart.h"
    #include "adc/adc.h"
    #include "acs712/acs712.h"

Aren't these lines saying "from the install directory for the AVR Tool Chain look for subdirectory uart and then find file uart.h"? (etc... For the other 2)

Do you really and truly have a "subdirectory uart in the install directory for the AVR Tool Chain where uart.h is located"?

My includes for the "Sample Nerdkit Programs" are:

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"
#include "../libnerdkits/uart.h"

So this "backs up one level from the current directory looks for subdirectory libnerdkits and finds delay.h". Also in the same directory are the "object files".

I have my own libraries for various thing. When I am working on updating those libraries this is the makefile I use for that:

    PROJ-1=mylcd
    PROJ-2=mytaskmanager
    PROJ-3=mysyserr
    PROJ-4=myuart
    PROJ-5=myeeprom
    GCCFLAGS=-g -Os -Wall -mmcu=atmega328p 
    GCCFLAGS-NOLINK=-c 
    LINKFLAGS=
    AVRDUDEFLAGS=-c avr109 -p m168 -b 115200 -P COM1
    LINKOBJECTS=./${PROJ-1}.o ./${PROJ-2}.o ./${PROJ-3}.o ./${PROJ-4}.o ./${PROJ-5}.o

    all:    ${PROJ-1}.hex ${PROJ-2}.hex ${PROJ-3}.hex ${PROJ-4}.hex ${PROJ-5}.hex main.hex
        avr-size -B ${PROJ-1}.o
        avr-size -B ${PROJ-2}.o
        avr-size -B ${PROJ-3}.o
        avr-size -B ${PROJ-4}.o
        avr-size -B ${PROJ-5}.o
        avr-size -B main.o
        avr-objdump -t -S -D main.o > main.asm

    ${PROJ-1}.hex:  ${PROJ-1}.c
        make -C ../libnerdkits
        avr-gcc ${GCCFLAGS-NOLINK} ${GCCFLAGS} -o ${PROJ-1}.o ${PROJ-1}.c
        avr-objcopy -j .text -O ihex ${PROJ-1}.o ${PROJ-1}.hex

    ${PROJ-2}.hex:  ${PROJ-2}.c
        make -C ../libnerdkits
        avr-gcc ${GCCFLAGS-NOLINK} ${GCCFLAGS} -o ${PROJ-2}.o ${PROJ-2}.c
        avr-objcopy -j .text -O ihex ${PROJ-2}.o ${PROJ-2}.hex

    ${PROJ-3}.hex:  ${PROJ-3}.c
        make -C ../libnerdkits
        avr-gcc ${GCCFLAGS-NOLINK} ${GCCFLAGS} -o ${PROJ-3}.o ${PROJ-3}.c
        avr-objcopy -j .text -O ihex ${PROJ-3}.o ${PROJ-3}.hex

    ${PROJ-4}.hex:  ${PROJ-4}.c
        make -C ../libnerdkits
        avr-gcc ${GCCFLAGS-NOLINK} ${GCCFLAGS} -o ${PROJ-4}.o ${PROJ-4}.c
        avr-objcopy -j .text -O ihex ${PROJ-4}.o ${PROJ-4}.hex

    ${PROJ-5}.hex:  ${PROJ-5}.c
        make -C ../libnerdkits
        avr-gcc ${GCCFLAGS-NOLINK} ${GCCFLAGS} -o ${PROJ-5}.o ${PROJ-5}.c
        avr-objcopy -j .text -O ihex ${PROJ-5}.o ${PROJ-5}.hex

    main.hex:   main.c ${PROJ-1}.hex  ${PROJ-2}.hex ${PROJ-3}.hex ${PROJ-4}.hex ${PROJ-5}.hex
        make -C ../libnerdkits
        avr-gcc ${GCCFLAGS} -o main.o main.c ${LINKOBJECTS}
        avr-objcopy -j .text -O ihex main.o main.hex

This way since each of the libraries hex files are checked against their corresponding source if I had made any changes that the corresponding library gets recompiled prior to recompiling the program I am testing the library in.

For my "normal programs" where I am just using my libraries, without making changes to them, I have just put their ".h" and ".o" file into the "libnerdkits" just to keep everything together.

#include "uart/uart.h" searches relative to the current directory.

#include <uart/uart.h> searches relative to the AVR toolchain directory.

If Ralph's include files were not being found he would not get all the undefined references to functions defined in them.

Actually I guess he is telling it to "look in the current directory for subdirectory uart and then look for uart.h"... (For searching in the AVR Tool Chain Installation Directory I guess it would be bracketed by "<" and ">".

My main thought was to get Ralph to think about what he "has done" vs "what he wants to do"...

It seems that the way he has the ".h" and ".o" files setup, or at least how they seemed to be setup VIA his source and makefile, creates alot of potential complications.

So "yes" while "include files are being found" are they the "ones he expects/wants to be found"?

I think I ran into a problem when two object/library files were named the same. ("uart/uart.o" and "../libnerdkits/uart.o" even though they are in separate directories.) My problem with that could have been something else, but I do know that now I don't do that anymore regardless.

Does Ralph really have/want 2 separate "uart.o" files?

Or

Is there only supposed to be 1?

I think linking with two object files named the same is not a problem as long as they don't both contain one or more functions with the same name. So possibly he is ok with both but if errors occur one or the other will need to be removed from his LINKOBJECTS.

LINKOBJECTS=../libnerdkits/delay.o ../libnerdkits/lcd.o
LINKOBJECTS+=uart/uart.o adc/adc.o acs712/acs712.o

However, it is not good practice to duplicate object file names within a project.

So yes I have subdirectories in my program folder (Root/uart/uart.c and uart.h) etc.

And like Noter said the files must be being found so I believe the path syntax is correct.

I do not need any references to libnerdkits.

What does the += in LINKOBJECTS do. I have not tried that yet.

I do not have any uart.o files will they be compiled when I compile the main.c program?

I am just trying to run (compile) some example code I found off the web for the ACS712 current sensor. But it did not come with a MakeFile so I was just using a default Nerdkit MakeFile.

Thanks once again everyone.

Ralph

In make the += just appends to the string. Kind of like the += in C where it just adds to the number.

No, the uart and other two objects will not be compiled when you compile the main program. They will be compiled when you navigate a command window to their directory and execute the appropriate avr-gcc command from my prior post to manually compile them. Unless you change them it only has to be done once so it's not worth the time and effort to create or modify a make file for a single compile. The object files don't go away unless you delete them so no need to compile every time.

Otherwise the easiest thing is to copy the libnerdkits make file into each of the sub directories and modify it to compile the single source in the directory. Then if you want you can add each of these new make files to your main make file in the same fashion as the libnerdkits make file is called just before the compile/link of your main program.

Once again Paul I am indebted to you.

I compiled the individual files making the object files and then compiled my main.c program perfect!!

Now where can I put this thread so that next year I can find it, sure would be nice to have a Library.

Now I have to add my stepper motor code and LCD output to the ACS712 code.

That ACS712 sure is a nice chip. So far I have just done DC but it also does AC.

Ralph

Hello Ralph,

So is ALL OF THIS stuff you are doing with Stepper Motors, and Current Measurements for your Solar Panel Sun Tracker?

You had mentioned that before...

Curious...

Hi Jim, specifically no but it could be adapted.

This thread specifically was to help me run a ACS712 library that I had found on the web.

I was hoping the library might give me more sensitivity in my current measurements.

The Solar Panel Sun Tracker is still on my list.

Ralph

Hi Ralph

You have mentioned that the ACS712 chip does AC current. You may be aware of this but,I thought I would point out that reading AC current would not be as straight forward as reading DC is.

In a typical sin wave AC the current at any given instant varies. Half of the time the current is flowing one direction and the other half of the time the current is flowing the other direction. With induction and capacitance in the circuit the current/voltage relationship can be complex. Basically it is not possible get a meaningful current measurement on AC with just one reading, or a simple average of a number of readings, as can be done with DC. By repeatedly sampling the current over at least one full AC cycle and determining the RMS (root mean square) the effective AC current is determined.

In the case of the ACS712 chip measuring AC current the voltage output would cycle up and down once each AC cycle just as the voltage does but not necessarily I phase with the voltage supply. If the Micro takes an ADC reading it would read the current at a specific instant in the cycle. In order to get the effective AC current you will have to incorporate a hardware or software method of determining the RMS value of the variance from the 2.5 volt output level. I believe that a simple average of the ACS712 output voltage would always be 2.5 Volts when measuring AC current. The chip is capable of measuring the current in both polarities. 2.5 volt output is representative of no current.

In the past I have made use of a chip that is very similar to the ACS712 to take a detailed look at the relationship of current vs voltage on AC motors. I did not do much experimenting but it is possible with an oscilloscope to see phase lag and the influence of stating capacitors at motor start up. This type of experimenting could definitely be dangerous and possibly costly because of the higher voltages often used on AC line voltage motors. I am not recommending anyone attempt to work with AC line voltage, but the results were interesting.

I just thought you may not have considered the added level of complexity in measuring AC current and voltage levels.

Darryl

Hi Darryl, thanks! Exactly, that is why I was trying to use the ACS712 library I had found on the web it is setup to do AC. Darn wish I could find the link.

There are a lot of Arduino projects using the ACS712 and lots of discussions on the web.

It is such a simple component to use, I got some pre-made modules that are nice except the pins are backwards and need to be reversed.

I tried the 5 amp module to see if I could get more sensitivity but I am seeing the same as with the 30 amp module I was trying to measure my stepper motor current which you helped me with.

Because of the lack of real sensitivity I am looking at the A3967, A3977 stepper drivers I can put a encoder on the first stepper and get a pulse which in turn will drive another stepper motor in sync with the first. We will talk about this concept in another thread :-)

Ralph

I use these when the pins are not on the bottom side of a module for insertion into a breadboard.

Dupont Wire Male to Female

Yeah, I have also seen some using 90 degree pins so they stand off the breadboard.

These are kind of silly, the components and the indicator led face the breadboard.

It's a easy change, obviously not made by users.

Ralph