Atmel Studio - andygock uart compile error (undefined reference)

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

Dear all,

 

I'm moving from the Arduino IDE to the Atmel Studio environment. I have already succesfully written a couple of firmwares without relying on any Arduino library.

I'm now adding UART support by including Andygock library (https://github.com/andygock/avr-uart).

 

I placed the uart.h and uart.c files in the project directory and included the "uart.h" file in the main.c file.

 

The errors I get are the following:

"undefined reference to `uart0_available' "

"ld returned 1 exit status."

 

The same errors occur if I try to call any another function of the library.

 

I attach the compile output of the Atmel Studio 7.0

 

Thank you in advance for your support.

 

Gianluca

Attachment(s): 

Last Edited: Thu. Nov 9, 2017 - 11:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As well as including uart.h you have to add uart.c to the list of files in the project so it is also compiled /linked.

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

Thank you for the suggestion. I tryed that, but unfortunately I still get the same errors.

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

May I ask, why are you moving from Arduino to Studio7?  Are you using AVR devices that aren't covered by Arduino?  Are you using a debugger that has breakpoints to examine variables?  Are the Arduino libraries too big, or have too much overhead for your application?

 

I recommend and use Arduino because it is straightforward, easy to use, and reliable.  But I'm also interested in all the opportunities for applications that are not either available or easy-to-do in Arduino and why people chose not to use Arduino.

 

Thank you,

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

You're going to have to give more details of what, exactly, you did - clearly, it wasn't (quite) right!

 

Looking at your build log, we can see that only main.o is being passed to the Linker:

 

Invoking: AVR/GNU Linker : 4.9.2
"C:\Program Files\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o Dynalock_32u4.elf  main.o   -Wl,-Map="Dynalock_32u4.map" ...

 

so the addition of the uart.c to the project has not "stuck" 

 

Maybe post a screenshot of the Solution Explorer - showing what is in the Project ?

 

Instructions here: http://www.avrfreaks.net/comment...

 

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

To Simonetta

Reasons for moving to Atmel Studio (all of what you said):

  • Development for any AVR
  • Deeper learning of the 8-bit AVR and possibly further step forward to more powerfull MCUs
  • Debugger functionality
  • Better control on execution timing

 

 

To Awneil

I attached two screenshots:

 

no.1 shows the explorer tree without the uart.c and uart.h

no.2 shows the explorer tree with the uart.c and uart.h also included

 

In both cases in the error list I get the same errors posted above.

 

 

Attachment(s): 

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

Add them under the project (Dynalock_32u4), not the solution (Solution Items).
 

David (aka frog_jr)

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

Already tryed, but unfortunately that's not the issue.

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

I suspect it may be related to the following (in uart.c line 174-176):

#elif defined(__AVR_ATmega8U2__) || defined(__AVR_ATmega16U2__) || defined(__AVR_ATmega16U4__) || \
      defined(__AVR_ATmega32U2__) || defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega32U6__)
	/* ATmega with one USART, but is called USART1 (untested) */

I created a project and tried compiling for the ATmega328P device and had no problems.

Changing to ATmega32U4 for the device, I get errors...

 

David (aka frog_jr)

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

frog_jr wrote:
Add them under the project (Dynalock_32u4), not the solution (Solution Items).

gisgari wrote:
Already tryed, but unfortunately that's not the issue.

Did you try a Rebuild? (Effectively the same as a Clean and a Build, i.e. everything is rebuilt.)

 

Even if you have another problem causing errors, leave the files where frog_jr said. That is where they are supposed to be.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"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]

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

gisgari wrote:
I attached two screenshots

Better to embed them - so that they are visible in the thread.

 

That's what the instructions I gave show how to do.

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

Header files should NOT be added. They should only be referenced by #include statements within the appropriate files.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Awneil,

Sorry I missed the embedding step, I'll re-read your link and will do it correctly next time.

 

JohanEkdahl wrote:
Did you try a Rebuild? (Effectively the same as a Clean and a Build, i.e. everything is rebuilt.)

Yes, that didn't help.

 

 

frog_jr wrote:
I created a project and tried compiling for the ATmega328P device and had no problems. Changing to ATmega32U4 for the device, I get errors...

I tryied compiling for ATmega328P and all went smoothly!!

I highligth that I have left only uart.c (and not uart.h) in the solution explorer under the project as suggested.

 

I assume now it is something to do with the #elif statements in the library. Could this be the way to follow?

 

 

 

Last Edited: Sun. Nov 12, 2017 - 12:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gisgari wrote:
I assume now it is something to do with the #elif statements in the library. Could this be the way to follow?

Well, as frog_jr highlighted, you are in the section where it specifically says:

/* ATmega with one USART, but is called USART1   (untested) */

 

And the error you said were getting was:

"undefined reference to `uart0_available' "

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

I noticed that in uart.h header file USART0_ENABLED is defined as a defult setting while USART1_ENABLED, USART2_ENABLED, USART3_ENABLED are not (commented out).

 

When using Atmega32u4 the library expect USART_1 to be used, thus all functions related to uart1 (beginning with uart1).

 

The firmware get compiled correctly if:

 

  • USART1_ENABLED is defined (uncommented) in section below (row 97 of uart.h)
    /* Enable USART 1, 2, 3 as required */
    /* Can be defined in compiler symbol setup with -D option (preferred) */
    #ifndef USART0_ENABLED
    	#define USART0_ENABLED /**< Enable USART0 */
    #endif
    //#define USART1_ENABLED
    //#define USART2_ENABLED 
    //#define USART3_ENABLED
  • Functions related to uart1 are used.

 

 

Hope this can help other having the same issue.

 

Thank all of you to have pointed me to right direction.

 

Gianluca

 

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

gisgari wrote:
Hope this can help other having the same issue.

Perhaps you should raise it as an Issue on GitHub ... ?

 

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

I have never done it, but surely I can try!

 

I'm now trying to implement a function that returns a string out of data retrieved with several call of uart_getc() function.

 

Basically, I would like to have a function similar to the Arduino Serial.read(). Is there any example around?

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

Most people would simply use a circular buffer then just keep pulling characters until an "end mark" such as \n.