AVR Freaks

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

Posted by donblake: Mon. Dec 24, 2012 - 09:46 PM

I haven't seen this before - I accidentally bumped into this recently. Here's one example of inconsistencies in the io.h header files.

For the ATmega164, ATmega164A, and ATmega164P (all of which include iomxx4.h), the defines for DDRA are as follows:

#define DDRA	_SFR_IO8(0X01)
#define DDA7	7
#define DDA6	6
  . . .
#define DDA0	0

However, for the ATmega164PA, the defines for DDRA are as follows:

#define DDRA    _SFR_IO8(0x01)
#define DDRA7   7
#define DDRA6   6
  . . .
#define DDRA0   0

Why is this? These ATmega164PA defines don't agree with the Atmel documentation (doc8272.pdf) for the ATmega164A/PA/324A/PA/644A/PA/1284/P.

BTW: I'm using:

Quote:

Atmel Studio 6 (Version: 6.0.1996 - Service Pack 2)

Installed Packages: AVRGCC - 3.4.1.95
AVR Toolchain 8 Bit
Version: 3.4.1.830 - GCC 4.6.2

Don

Tags:

Tools, Atmel Studio (AVR-related), ATmega16, ATmega164A, ATmega164P, ATmega164PA

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29989 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Mon. Dec 24, 2012 - 10:02 PM

It seems correct DDRA is 0x01 (0x21). I thing GCC used to address all I/O as RAM addresses and added 0x20 to all I/O addresses? Maybe the new toolchain in AS6 doesn't?

John Samperi

Ampertronics Pty. Ltd.

* Electronic Design * Custom Products * Contract Assembly

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

Posted by donblake: Mon. Dec 24, 2012 - 10:08 PM

js wrote:

It seems correct DDRA is 0x01 (0x21). I thing GCC used to address all I/O as RAM addresses and added 0x20 to all I/O addresses? Maybe the new toolchain in AS6 doesn't?

No argument there. But why is, for example, DDA7 used for bit 7 with the ATmega164/A/P and DDRA7 used with the ATmega164PA?

Don

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29989 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Mon. Dec 24, 2012 - 10:16 PM

Hmm don't know. With the Xmegas all of that has (correctly) disappeared and now we only have 8 bit masks al 8 bit position definitions.

// Generic Port Pins
#define PIN0_bm 0x01 
#define PIN0_bp 0
#define PIN1_bm 0x02
#define PIN1_bp 1
#define PIN2_bm 0x04 
#define PIN2_bp 2
#define PIN3_bm 0x08 
#define PIN3_bp 3
#define PIN4_bm 0x10 
#define PIN4_bp 4
#define PIN5_bm 0x20 
#define PIN5_bp 5
#define PIN6_bm 0x40 
#define PIN6_bp 6
#define PIN7_bm 0x80 
#define PIN7_bp 7

As they are defintions you can use anything instead of DDA7 or DDRA7 and it would still work as long as the bit definition equal to 7.

But I know you know that. :-)

John Samperi

Ampertronics Pty. Ltd.

* Electronic Design * Custom Products * Contract Assembly

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

Posted by ChaunceyGardiner: Mon. Dec 24, 2012 - 11:33 PM

I tend to use the Pxn symbols for this. For instance,

DDRA = 1 << PA3;

That may not be "correct" but it works.

Sid

Life... is a state of mind

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

Posted by donblake: Wed. Dec 26, 2012 - 02:44 AM

ChaunceyGardiner wrote:

I tend to use the Pxn symbols for this. For instance,
DDRA = 1 << PA3;
That may not be "correct" but it works.

That'll work for many devices but not all. For the ATmega164PA and many more, PA3 is not defined. The defines for PORTA bits are PORTAx instead of PAx.

Don

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 04:41 AM

donblake wrote:

ChaunceyGardiner wrote:
I tend to use the Pxn symbols for this. For instance,
DDRA = 1 << PA3;
That may not be "correct" but it works.
That'll work for many devices but not all. For the ATmega164PA and many more, PA3 is not defined. The defines for PORTA bits are PORTAx instead of PAx.

It works just fine for Atmega164PA if you use AS6.

Where did you get your header files ?

Sid

Life... is a state of mind

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29989 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Wed. Dec 26, 2012 - 06:43 AM

This is part of the ASM include file for the Mega164PA

; ***** PORTA ************************
; PORTA - Port A Data Register
.equ	PORTA0	= 0	; Port A Data Register bit 0
.equ	PA0	= 0	; For compatibility
.equ	PORTA1	= 1	; Port A Data Register bit 1
.equ	PA1	= 1	; For compatibility
.equ	PORTA2	= 2	; Port A Data Register bit 2
.equ	PA2	= 2	; For compatibility
.equ	PORTA3	= 3	; Port A Data Register bit 3
.equ	PA3	= 3	; For compatibility
.equ	PORTA4	= 4	; Port A Data Register bit 4
.equ	PA4	= 4	; For compatibility
.equ	PORTA5	= 5	; Port A Data Register bit 5
.equ	PA5	= 5	; For compatibility
.equ	PORTA6	= 6	; Port A Data Register bit 6
.equ	PA6	= 6	; For compatibility
.equ	PORTA7	= 7	; Port A Data Register bit 7
.equ	PA7	= 7	; For compatibility

It defines BOTH "For compatibility", maybe newer GCC header files no longer support it?

John Samperi

Ampertronics Pty. Ltd.

* Electronic Design * Custom Products * Contract Assembly

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 09:22 AM

Yes, they do.

Sid

Life... is a state of mind

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

#10

Posted by donblake: Wed. Dec 26, 2012 - 07:10 PM

ChaunceyGardiner wrote:

Where did you get your header files ?

Quote:

Atmel Studio 6 (Version: 6.0.1996 - Service Pack 2)

Installed Packages: AVRGCC - 3.4.1.95
AVR Toolchain 8 Bit
Version: 3.4.1.830 - GCC 4.6.2

The header file (iom164pa.h) is in the \Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\avr\include\avr directory.

Which version of Atmel Studio/AVRGCC are you using?

Don

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

#11

Posted by donblake: Wed. Dec 26, 2012 - 07:20 PM

js wrote:

It defines BOTH "For compatibility", maybe newer GCC header files no longer support it?

Yes, I see that in m164PAdef.inc in the \Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel/AVRAssembler\2.1.51.64\avrassembler\include folder.

I DO NOT see that in the iom644pa.h file in the \Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\avr\include\avr folder.

Strange!

Don

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29989 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

#12

Posted by js: Wed. Dec 26, 2012 - 09:56 PM

I see what you mean, it's different from the header file in winAvr. Don't know the reason why of course, maybe just copy those definitions from the winAvr header files for those older projects which use PAx etc.

I hopeAS6 is consistent and use PORTxx for all chips, I'm still using winAvr for C projects.

I'm using assembler with AS6 for a chip which is not supported for debugging in AS4.

John Samperi

Ampertronics Pty. Ltd.

* Electronic Design * Custom Products * Contract Assembly

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

#13

Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 10:23 PM

donblake wrote:

ChaunceyGardiner wrote:
Where did you get your header files ?
Quote:
Atmel Studio 6 (Version: 6.0.1996 - Service Pack 2)

Installed Packages: AVRGCC - 3.4.1.95
AVR Toolchain 8 Bit
Version: 3.4.1.830 - GCC 4.6.2
The header file (iom164pa.h) is in the \Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\avr\include\avr directory.

Which version of Atmel Studio/AVRGCC are you using?

I am using AS6.

You're looking in the wrong header file.

I don't know why you think you need to look in a header file, the compiler will tell you if you try to use a symbol that doesn't exist.

Anyway, the proper file to include is not iom164pa.h or any of its cousins. You should include avr/io.h - which in turn includes several files, including avr/portpins.h.

Sid

Life... is a state of mind

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

#14

Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 10:29 PM

js wrote:

I hopeAS6 is consistent and use PORTxx for all chips

It does. Both PORTxn and Pxn.

Sid

Life... is a state of mind

alexan_e

Level: Resident

Joined: Thu. Jul 5, 2007

Posts: 994 View posts

Location: Greece

#15

Posted by alexan_e: Wed. Dec 26, 2012 - 10:54 PM

js wrote:

I'm still using winAvr for C projects.

I guess I'm not alone in the world...
You're lucky you didn't get an outdated tools lecture like I did in another thread for using winavr. :roll:

It would be interesting to create a poll about users of winavr and users of AS5/AS6 (at least for chips that are supported in both)

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

#16

Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 11:05 PM

alexan_e wrote:

js wrote:
I'm still using winAvr for C projects.

I guess I'm not alone in the world...
You're lucky you didn't get an outdated tools lecture like I did in another thread for using winavr. :roll:

You missed the point, then. I don't care what tools you use.

What was annoying to me was that I spent time discussing the performance of some code with you - after you brought it up - and you didn't disclose the fact that you use antiquated tools until the end of the discussion.

Sid

Life... is a state of mind

alexan_e

Level: Resident

Joined: Thu. Jul 5, 2007

Posts: 994 View posts

Location: Greece

#17

Posted by alexan_e: Wed. Dec 26, 2012 - 11:22 PM

And what about

Quote:

...you don't only want to create "good" code with outdated tools - you also want to make sure that your solution sucks whenever you decide to upgrade to what is already the best toolchain

That works both ways, a solution should be tested in different versions and even to compilers from other vendors in order to get an all round verdict.
The "best toolchain" I suppose is a matter of opinion.

Alex

"For every effect there is a root cause. Find and address the root cause rather than try to fix the effect, as there is no end to the latter."
Author Unknown

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

#18

Posted by ChaunceyGardiner: Thu. Dec 27, 2012 - 12:08 AM

alexan_e wrote:

And what about

Quote:
...you don't only want to create "good" code with outdated tools - you also want to make sure that your solution sucks whenever you decide to upgrade to what is already the best toolchain

That works both ways, a solution should be tested in different versions and even to compilers from other vendors in order to get an all round verdict.
The "best toolchain" I suppose is a matter of opinion.

If efficient code is important, you should start by selecting a toolchain that generates efficient code.

If you have to use a lesser toolchain, you should optimize for that but document what you have done. That way you have at least a chance to remember it when you finally get decent tools.

Sid

Life... is a state of mind

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29989 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

#19

Posted by js: Thu. Dec 27, 2012 - 03:41 AM

Quote:

a poll about users of winavr and users of AS5/AS6

No need for a poll for me, I will still use AS4 (and winAvr for C projects) for supported chips, for one thing it doesn't take 90 seconds to start.

However I have also AS6 installed on a new laptop which was originally purchased for the sole purpose of running AS6 and I'm using it with a chip which is not supported by AS4 for debugging.

I'm working with assembler on that chip so no GCC toolchain involved, I have only played around with a couple of older C projects and alternating between winAvr and the Toolchain just to get a feel of things.

AS6 WILL get better, it took me almost 2 years before I even downloaded it but AS4 is doing all I need to do at the moment.

Maybe when I'm forced to get another desktop when Win XP is no longer supported and I can get a 32+ cores, zillion squiggabytes of everything I will instal AS6 on it. :-)

John Samperi

Ampertronics Pty. Ltd.

* Electronic Design * Custom Products * Contract Assembly

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

#20

Posted by donblake: Thu. Dec 27, 2012 - 02:56 PM

ChaunceyGardiner wrote:

You're looking in the wrong header file.

I don't know why you think you need to look in a header file, the compiler will tell you if you try to use a symbol that doesn't exist.

Anyway, the proper file to include is not iom164pa.h or any of its cousins. You should include avr/io.h - which in turn includes several files, including avr/portpins.h.

I am including . I'm looking in the header file because the compiler is telling me I'm trying to use a symbol that doesn't exist.

Quote:

Error 1 'DDC4' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 184 12 4x4x4_ledcube
Warning 2 each undeclared identifier is reported only once for each function it appears in E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 184 12 4x4x4_ledcube
Error 3 'DDC5' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 184 28 4x4x4_ledcube
Error 4 'DDC6' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 184 44 4x4x4_ledcube
Error 5 'DDC7' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 184 60 4x4x4_ledcube
Error 6 'DDC0' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 185 12 4x4x4_ledcube
Error 7 'DDC1' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 185 28 4x4x4_ledcube
Error 8 'DDC2' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 185 44 4x4x4_ledcube
Error 9 'DDC3' undeclared (first use in this function) E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.c 185 60 4x4x4_ledcube

Now, if I change from ATmega164PA to, say, ATmega164P:

Quote:

Build started.
Project "4x4x4_ledcube.cproj" (Compile target(s)):
Target "Compile" in file "D:\Program Files (x86)\Atmel\Atmel Studio 6.0\Vs\Compiler.targets" from project "E:\Electronics\AVR\Code\WinAVR\4x4x4_ledcube\4x4x4_ledcube.cproj" (entry point):
Task "RunCompilerTask"
D:\Program Files (x86)\Atmel\Atmel Studio 6.0\make\make.exe "4x4x4_ledcube.o"
Building file: .././4x4x4_ledcube.c
Invoking: AVR/GNU C Compiler : (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2
"D:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin\avr-gcc.exe" -funsigned-char -funsigned-bitfields -DF_CPU=14745600 -Os -fpack-struct -fshort-enums -g2 -Wall -c -std=gnu99 -MD -MP -MF "4x4x4_ledcube.d" -MT"4x4x4_ledcube.d" -MT"4x4x4_ledcube.o" -mmcu=atmega164p -o"4x4x4_ledcube.o" ".././4x4x4_ledcube.c"
Finished building: .././4x4x4_ledcube.c
Done executing task "RunCompilerTask".
Done building target "Compile" in project "4x4x4_ledcube.cproj".
Done building project "4x4x4_ledcube.cproj".

Build succeeded.

Don

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

#21

Posted by donblake: Thu. Dec 27, 2012 - 03:46 PM

ChaunceyGardiner wrote:

Anyway, the proper file to include is not iom164pa.h or any of its cousins. You should include avr/io.h - which in turn includes several files, including avr/portpins.h.

BTW: I didn't know about portpins.h. I will switch over to the generic PORTn, DDn, and PINn defines. Thanks.

Don

Level: Posting Freak

Joined: Fri. Mar 9, 2012

Posts: 1452 View posts

Location: North Carolina, USA

#22

Posted by ChaunceyGardiner: Thu. Dec 27, 2012 - 10:07 PM

donblake wrote:

ChaunceyGardiner wrote:
You're looking in the wrong header file.

I don't know why you think you need to look in a header file, the compiler will tell you if you try to use a symbol that doesn't exist.

Anyway, the proper file to include is not iom164pa.h or any of its cousins. You should include avr/io.h - which in turn includes several files, including avr/portpins.h.

I am including . I'm looking in the header file because the compiler is telling me I'm trying to use a symbol that doesn't exist.

Quote:
Error 1 'DDC4' undeclared (first use in this function)

The point is that the compiler didn't tell you that PA3 doesn't exist. You made that claim, thereby dismissing a simple solution to your problem without even trying it. It seems very likely that you made that mistake because you were looking in the wrong header file.

Sid

Life... is a state of mind

Level: Posting Freak

Joined: Sat. Jan 3, 2004

Posts: 1554 View posts

Location: Binghamton, NY, USA

#23

Posted by donblake: Fri. Dec 28, 2012 - 01:00 AM

ChaunceyGardiner wrote:

The point is that the compiler didn't tell you that PA3 doesn't exist. You made that claim, thereby dismissing a simple solution to your problem without even trying it. It seems very likely that you made that mistake because you were looking in the wrong header file.

You're correct. Point taken. My bad.

Don

aarons

Level: New Member

Joined: Fri. Dec 28, 2012

Posts: 4 View posts

#24

Posted by aarons: Fri. Dec 28, 2012 - 11:28 PM

I just ran into this same issue. Code I was building (AS6 6.0.1996) for an ATMega324A broke when I switched to a 324PA.

On my linux box with an older version of avr-libc on it, none of the headers in that directory contain the DDR{A,B,C,D}N defines. In the version from AS6, a handful do, but not all.

Does that suggest that things were moving to the DDR convention but not everything was changed?

I changed things to use PORT{A,B,C,D}N in my code, is that the canonical solution? I just don't want to end up with code that fails to build with some future version because it was relying on some deprecated defines.

steve17

Level: Raving Lunatic

Joined: Tue. Sep 7, 2004

Posts: 6713 View posts

Location: New York State

#25

Posted by steve17: Sat. Dec 29, 2012 - 10:47 PM

There are omissions in every io....h file I've ever used. Apparently most of the omissions are for symbols nobody uses except me. It used to be easy to fix these files when they were in Winavr. But now Atmel has put them in the Program Files directory, and they are a pain to change.

Is there an easy way to get the Atmel Studio installer to put them somewhere else?