Mac based AVR development issue

avr-gccccompilerosx

Ok, so I reinstalled my development enviroment on the mac using the latest build of avr-gcc (4.4.2), avr-libc and avrdude from the Fink project.

Problem is when compiling I keep on getting a linker issue "multiple definition of …".

I have narrowed it down to a floating point issue associated with "libm.a" (using strtod()). All indications says to just include this library, but i'm unsure of how to do this in my Make file (below).

DEVICE     = atmega128
CLOCK      = 8000000
PROGRAMMER = -c stk600 -P usb
OBJECTS    = main.o a2d.o buffer.o gps.o nmea.o uart2.o vt100.o rprintf.o timer128.o tsip.o
FUSES      = -U hfuse:w:0x99:m -U lfuse:w:0xC2:m

AVRDUDE = avrdude $(PROGRAMMER) -p $(DEVICE)
COMPILE = avr-gcc -std=gnu99 -Wall -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE)

all:    main.hex

.c.o:
    $(COMPILE) -c $< -lm -o $@

.S.o:
    $(COMPILE) -c $< -lm -o $@

.c.s:
    $(COMPILE) -S $< -lm -o $@

flash:  all
    $(AVRDUDE) -U flash:w:main.hex:i

fuse:
    $(AVRDUDE) $(FUSES)

install: flash fuse

load: all
    bootloadHID main.hex

clean:
    rm -f main.hex main.elf $(OBJECTS)

main.elf: $(OBJECTS)
    $(COMPILE) -lm -o main.elf $(OBJECTS)

main.hex: main.elf
    rm -f main.hex
    avr-objcopy -j .text -j .data -O ihex main.elf main.hex

disasm: main.elf
    avr-objdump -d main.elf

cpp:
    $(COMPILE) -E main.c

Best Answer

Your makefile should compile each C file into object code, then use the linker to combine the objects with libraries. You don't need -lm for each compiled file.

In your makefile, you are using $(COMPILE) as both compiler and linker, which is fine for GCC, but is probably confusing matters.

all:    main.hex

.c.o:
    $(COMPILE) -c $< -o $@

.S.o:
    $(COMPILE) -c $< -o $@

.c.s:
    $(COMPILE) -S $< -o $@

main.elf: $(OBJECTS)
    $(COMPILE) -lm -o main.elf $(OBJECTS)

Related Solutions

Electronic – Linux / Mac AVR Programming Suite

I agree with zklapow but check the projects section on AVR Freaks too. That's how I learnt back in the day before arduinos. Also, you will almost certainly have to read the datasheet for your chip to get anything useful done. There are no nice functions that, for example, read an analog pin in because there are so many parameters that the arduino environment hides from you. Let me give you an example:

 int ledPin =  13;    // LED connected to digital pin 13
 // The setup() method runs once, when the sketch starts
 void setup()   {                
   // initialize the digital pin as an output:
   pinMode(ledPin, OUTPUT);     
 }
 // the loop() method runs over and over again,
 // as long as the Arduino has power
 void loop()                     
 {
   digitalWrite(ledPin, HIGH);   // set the LED on
   delay(1000);                  // wait for a second
   digitalWrite(ledPin, LOW);    // set the LED off
   delay(1000);                  // wait for a second
 }

is roughly similar to the following C (not tested):

int main(void) {
    // I just randomly picked pin 6 on PORTB, this may not be the same on an arduino
    DDRB = (1<<6); // set pin to output in data direction register
    int i; // have to do this outside the for loop because of C standard

    while(1) {
        PORTB |= (1<<6); // send pin 6 high and leave other pins in their current state
        for (i=0; i<10000; i++); // delay

        PORTB &= ~(1<<6); // send pin 6 low
        for (i=0; i<10000; i++); // delay
    }
}

Sure, there are delay functions in some libraries and there may be output functions in other ones, but get used to writing code like this. The only way you can possibly know what all this PORTB and DDRB stuff means is to read the datasheet. I'm sorry to drone on about this but not enough people realize that the datasheet is a goldmine for information.

UC1698 based LCD driven by AVR

I wouldn't trust just any display library you find on the internet to drive the display. You might be better off writing your own display library for this display controller. If you do decide to use someone else’s library you will still need to familiarize yourself with the display controller datasheet and the code you are using to make sure it is doing what it's supposed to.

Do you know what communication mode you are using between the AVR and the display? Your display controller supports seven different communication modes using a combination of the BM pins, DB15, and DB13.

Related Topic