AVR-GCC compiler does not consider a defined macro

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

Hi guys.

 

Why does not AVR-GCC compiler consider a defined macro?

 

In main.c file I wrote

...
#include "keypad.h"

int main(void)
{
        ...

	while (1)
	{
		keypad_timer_isr();
                ...
	}
}

In keypad.h file I wrote

...
#define KEYPAD_TIMER_DEBOUNCING
#ifdef KEYPAD_TIMER_DEBOUNCING
void keypad_timer_isr(void);
#endif
...

In keypad.c file I wrote

#include "keypad.h"
...
#ifdef KEYPAD_TIMER_DEBOUNCING
void keypad_timer_isr(void)
{
    ...
}
#endif
...

when I build solution in Atmel Studio 7, I receive

What is the problem?

 

Note 1: In codevisionAVR, I have no this problem.

 

Note 2:

 

 

Post is edited.

 

This topic has a solution.
Last Edited: Mon. Sep 5, 2016 - 11:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just in case: did you #include "keypad.h" in keypad.c?

ɴᴇᴛɪᴢᴇᴎ

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

Yes of course. As I said, I have no problem in CV.

 

Thanks my friend.

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

Well, you just edited your post and added it: it wasn't there when I asked the question. :-)

 

Do you use -O0 in AS7 too?

ɴᴇᴛɪᴢᴇᴎ

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

Yes you are true. I forgot to write it.

Yes I use. I forgot to write it too. I added it in note 2.

I apologized my friend.

Thanks.

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

mosakazemi wrote:
Yes I use. I forgot to write it too. I added it in note 2.

Alright. I don't use CV nor AS, so I have a hard time guessing what app the screenshots show. :-p

 

I think there's missing information here: I cannot believe avr-gcc got that wrong…

Can you show us what's inside keypad_timer_isr()?

ɴᴇᴛɪᴢᴇᴎ

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

Everything looks ok from here:

$ avr-gcc -Wall -mmcu=atmega328 -o test test.c keypad.c
$ avr-objdump -d test
…
00000080 <main>:
  80:	cf 93       	push	r28
  82:	df 93       	push	r29
  84:	cd b7       	in	r28, 0x3d	; 61
  86:	de b7       	in	r29, 0x3e	; 62
  88:	0e 94 47 00 	call	0x8e	; 0x8e <keypad_timer_isr>
  8c:	fd cf       	rjmp	.-6      	; 0x88 <main+0x8>

0000008e <keypad_timer_isr>:
  8e:	cf 93       	push	r28
  90:	df 93       	push	r29
  92:	cd b7       	in	r28, 0x3d	; 61
  94:	de b7       	in	r29, 0x3e	; 62
  96:	df 91       	pop	r29
  98:	cf 91       	pop	r28
  9a:	08 95       	ret

 

ɴᴇᴛɪᴢᴇᴎ

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

In AS7 there is a tick box (may be under "General"?) that switches on the -save-temps option. Use that and then study the .i files that are left behind after the build. In particular it's the keypad.i one that should be most revealing.

 

I'm wondering if, perhaps there's some kind of non-printable in the above that we're not seeing?

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

surprise what a bad mistake!

 

I checked keypad.i file and I realized that the keypad.h file address which is opened in AS7 is in previous location before I cut the whole project folder and paste in new location.

 

I don't expect it.

 

why does this happen? If I move copy the project directory in new location and then click in project file, why the previous opened header files in AS7 loaded from previous location not new location?

 

Thanks for your replies my dear friends.

 

Edited post.

Last Edited: Tue. Sep 6, 2016 - 06:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mosakazemi wrote:
why does this happen? If I move the project directory in new location and then click in project file, why the previous opened header files in AS7 loaded from previous location not new location?

Sorry, can't help you with that.

ɴᴇᴛɪᴢᴇᴎ

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

mosakazemi wrote:
 If I move the project directory in new location and then click in project file, why the previous opened header files in AS7 loaded from previous location not new location?

Presumably, because your Include Paths are still pointing to the old location?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi thanks. How do I check it?

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

Build with the -H option. It will show you where headers are being found by the C preprocessor

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

clawson wrote:

Build with the -H option. It will show you where headers are being found by the C preprocessor

 

How do I build with -H option? I'm a newbie in AVR-GCC. smiley

 

Thanks.

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

awneil wrote:

Presumably, because your Include Paths are still pointing to the old location?

 

Now, how can I change it?

 

Thanks awneil.

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

hello everyone 

i just use avr studio 6.

and the compiler didn't find header file such as delay.h , iom16 and many other files (Error    1    delay.h: No such file or directory)

 how to access it in building solution

thanks

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

Show the code.

 

The correct inclusion for the delays in avr-gcc is:

#include <utils/delay.h>

and you should not be including a header for atmega16 directly. Just use:

#include <avr/io.h>

in all AVR programs for avr-gcc and a flag that is passed at build time will arrange for that to then include iom16.h if that is what the code is being built for.

 

If you have code that looks something like:

#include <delay.h>
#include <iom16.h>

it has almost certainly been written for a different AVR C compiler, not avr-gcc.

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

thanks 

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

if you have a guid please forward it for me 

best regards 

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

Assuming by GUID you mean globally unique identifier What do you need a GUID for? Never the less, if you google GUID then I'd imagine you'll find an online generator

 

Edit: having seen theusch's comment I'm guessing that was a typo and you really meant guide ha!

Last Edited: Tue. Nov 1, 2016 - 01:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

M.F.Hashem wrote:
i just use avr studio 6.
M.F.Hashem wrote:
if you have a guid please forward it for me

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Your program code is written for Codevision.

Download and install the free Evaluaton version of Codevision.

Unlike the nightmare of GCC, Codevision comes with built-in help and examples.
You will find it easier to debug too.

It will be fine for most small student programs.
If your flash code is more than 4kB, you need to buy a full licence.

David.

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

david.prentice wrote:
You will find it easier to debug too.
CV has it's own debugger now? I thought it relied on using the Studio debugger - has that changed?

 

What puzzles me is that the code above is so simple it looks like it's been written from scratch. So I wonder why the poster chose to type Codevision syntax into the GCC compiler in the first place?

 

Or was this code downloaded from an internet site somewhere?

 

EDIT: OK so I picked a fairly unique (positively odd looking) line from that code and googled it. There was ONE result across the entire internet:

 

https://www.avrfreaks.net/forum/b...

 

I do wonder what made the poster pick this of all the potential LED blinking code he could have found as the example to use in Studio 7?

 

EDIT2: nope I cannot contain my puzzlement! That thread even says:

something is going wrong ....LED is not blinking though it lit up

so not only does it seem an odd choice to start with it seems especially odd when the original poster was reporting a problem and there is no sign of any resolution in that thread?!?

 

I'll never understand how the internet works!

Last Edited: Tue. Nov 1, 2016 - 02:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code in message #18 looks like regular Codevision.

Mind you,  I don't see an #include < io.h>

 

No,  CV does not have a separate debugger.   It uses the regular AS7 debugger.

The "easiness" is down to the variables being visible in the debugger.   Even if they are held in registers.

 

It is often a bit of a lottery with GCC to see register variables.

 

David.

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

I guess that makes "COFF" a better debug format than "DWARF2".

 

It's true that DWARF2 is a bit long in the tooth. I think they are up to DWARF4 and I think it "fixes" things like tracking variables in registers and stuff. Sadly the avr-gcc does not seem to have whatever is necessary to create DWARF4.

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

I don't think there is anything wrong with DWARF2.    COFF is not very good with filenames.

 

I think it comes down to what the Compiler actually remembers to put in the debug info.

And CV is not as "clever" as GCC when it comes to several optimisations.

 

David.

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

clawson wrote:
Sadly the avr-gcc does not seem to have whatever is necessary to create DWARF4

 

Not really. Just that the default DWARF version for the Atmel toolchain is configured to DWARF2 so that the AS debugger doesn't choke.

Regards

Senthil

 

blog | website

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

Then why isn't the debugger upgraded to handle DWARF4 if it would give a "better" experience, like knowing that 'count' is really in R25 or whatever it is?

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

clawson wrote:
Then why isn't the debugger upgraded to handle DWARF4 if it would give a "better" experience

 

Guess the idea is to let gdb (avr-gdb in this case) handle DWARF rather than making the AS debugger itself chase and implement the latest DWARF features.

Regards

Senthil

 

blog | website

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

OK so are you saying that if I use -gdwarf-4 when building and tell AS7 to switch to avr-gdb for debugging that I might get a "better" debugging experience?

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

clawson wrote:
OK so are you saying that if I use -gdwarf-4 when building and tell AS7 to switch to avr-gdb for debugging that I might get a "better" debugging experience?

 

Yes, if it works :). avr-gdb hasn't gotten much love recently, and I don't think the Atmel Studio guys really tests debugging with avr-gdb. They use arm-*-gdb much more extensively though, IIRC, that's the default option for debugging SAM devices.

Regards

Senthil

 

blog | website

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

clawson wrote:

OK so are you saying that if I use -gdwarf-4 when building and tell AS7 to switch to avr-gdb for debugging that I might get a "better" debugging experience?

 

Jupp. Until it crashes, that is :) 

 

As Senthil says, it is there, but we have not enabled avr-gdb by default (there are still some cases that our debugger is 'better' than gdb). However our debugger does not understand dwarf4, so the default is dwarf2. (We do both run and do tests with avr-gdb, so it does work for normal use, by all means).

 

On ARM, arm-gdb is used by default (and I think we use dwarf4... should probably check that)

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.