inconsistencies in io.h header files

Log in or register to post comments
Go To Last Post
28 posts / 0 new
Author
Message
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
#1
Posted by donblake: Mon. Dec 24, 2012 - 09:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29210 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of smoke)
Posted by js: Mon. Dec 24, 2012 - 10:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
Posted by donblake: Mon. Dec 24, 2012 - 10:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29210 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of smoke)
Posted by js: Mon. Dec 24, 2012 - 10:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
ChaunceyGardiner
ChaunceyGardiner's picture
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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
Posted by donblake: Wed. Dec 26, 2012 - 02:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
ChaunceyGardiner
ChaunceyGardiner's picture
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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29210 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of smoke)
Posted by js: Wed. Dec 26, 2012 - 06:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
ChaunceyGardiner
ChaunceyGardiner's picture
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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, they do.

Sid

Life... is a state of mind

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
Posted by donblake: Wed. Dec 26, 2012 - 07:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
Posted by donblake: Wed. Dec 26, 2012 - 07:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29210 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of smoke)
Posted by js: Wed. Dec 26, 2012 - 09:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
ChaunceyGardiner
ChaunceyGardiner's picture
Level: Posting Freak
Joined: Fri. Mar 9, 2012
Posts: 1452 View posts
Location: North Carolina, USA
Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 10:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
ChaunceyGardiner
ChaunceyGardiner's picture
Level: Posting Freak
Joined: Fri. Mar 9, 2012
Posts: 1452 View posts
Location: North Carolina, USA
Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 10:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
alexan_e
alexan_e's picture
Level: Resident
Joined: Thu. Jul 5, 2007
Posts: 994 View posts
Location: Greece
Posted by alexan_e: Wed. Dec 26, 2012 - 10:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
ChaunceyGardiner
ChaunceyGardiner's picture
Level: Posting Freak
Joined: Fri. Mar 9, 2012
Posts: 1452 View posts
Location: North Carolina, USA
Posted by ChaunceyGardiner: Wed. Dec 26, 2012 - 11:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
alexan_e
alexan_e's picture
Level: Resident
Joined: Thu. Jul 5, 2007
Posts: 994 View posts
Location: Greece
Posted by alexan_e: Wed. Dec 26, 2012 - 11:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
ChaunceyGardiner
ChaunceyGardiner's picture
Level: Posting Freak
Joined: Fri. Mar 9, 2012
Posts: 1452 View posts
Location: North Carolina, USA
Posted by ChaunceyGardiner: Thu. Dec 27, 2012 - 12:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
js
js's picture
Level: Moderator
Joined: Wed. Mar 28, 2001
Posts: 29210 View posts
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of smoke)
Posted by js: Thu. Dec 27, 2012 - 03:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
Posted by donblake: Thu. Dec 27, 2012 - 02:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
Posted by donblake: Thu. Dec 27, 2012 - 03:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
ChaunceyGardiner
ChaunceyGardiner's picture
Level: Posting Freak
Joined: Fri. Mar 9, 2012
Posts: 1452 View posts
Location: North Carolina, USA
Posted by ChaunceyGardiner: Thu. Dec 27, 2012 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
donblake
donblake's picture
Level: Posting Freak
Joined: Sat. Jan 3, 2004
Posts: 1569 View posts
Location: Binghamton, NY, USA
Posted by donblake: Fri. Dec 28, 2012 - 01:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Top
aarons
aarons's picture
Level: New Member
Joined: Fri. Dec 28, 2012
Posts: 4 View posts
Posted by aarons: Fri. Dec 28, 2012 - 11:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 6337 View posts
Location: New York State
Posted by steve17: Sat. Dec 29, 2012 - 10:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Top
ChaunceyGardiner
ChaunceyGardiner's picture
Level: Posting Freak
Joined: Fri. Mar 9, 2012
Posts: 1452 View posts
Location: North Carolina, USA
Posted by ChaunceyGardiner: Sat. Dec 29, 2012 - 11:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aarons wrote:
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.

I use the Pxn symbols. I think they are less likely to be broken as they match the actual pin names used in the datasheets.

Pxn also seems more consistent when using them with DDRx and PINx. PORTxn (almost) implies PORTx to me.

Sid

Life... is a state of mind

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98214 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sun. Dec 30, 2012 - 02:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Usually the contents of ioXXX.h in AVR-Libc start life in the Atmel XML files for the part which are (a) supposed to match the datasheet and (b) may actually have something to do with the VHDL (or whatever) that generates the AVR. So any such inconsistency may be at the very heart of the chip design and is just the preference of the silicon author. So I'd take a look at the corresponding XML from Atmel.

It also probably doesn't help that Atmel have chosen to branch AVR-Libc development without feeding their changes back upstream where they could be peer-reviewed and corrected by the open development community.

Talking of which this thread seems to be about WinAVR, not Toolchain in fact so may be off-topic for AS5/6, should I move it?

Top
steve17
steve17's picture
Level: Raving Lunatic
Joined: Tue. Sep 7, 2004
Posts: 6337 View posts
Location: New York State
Posted by steve17: Sun. Dec 30, 2012 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought this was about the io...h files which used to be in WinAvr but are now in Program Files/Atmel/.....

The symbols I found missing for AVRs like Xmega32a4u are CPU, USB, and GPIO, if I recall correctly. Someone thought they defined them but they are defined as types CPU_t, USB_t and GPIO_t, and those types were not defined. Like I said, most people no doubt don't use these symbols, but I do.

Top