Moved from thread referencing posts 4, 5, and 8. The ATMega64/128 chips have a stray IO register definition that causes the ASF IOPORT routines to fail.
OH and there's a "trick" you can use on AVRs that works for almost every port of every AVR. The registers are always in the order:
PIN
DDR
PORT
So you only need be given one address. For example if you are given DDRB then the PIN register is addr-1 and the PORT register is addr+1 though I guess the user is most likely to want to use:
Led red(&PORTB);in which case DDR is addr-1 and PIN is addr-2. The point being they don't have to pass all of PORTB, DDRB, PINB.
No doubt someone will be along in a minute to point out some example of an AVR/port where this three address sequence is broken! ;-)
clawson wrote:
No doubt someone will be along in a minute to point out some example of an AVR/port where this three address sequence is broken! ;-)
ATMega64/128 PORTF.
(three minutes
)
A follow up to my earlier post regarding this breaking my IOPorts class. This is something Atmel needs to know about.
The latest, and surely some previous, ASF code for the IOPORT services and drivers for the ATMega series in ASF/common/services/ioport/ioport.h and ASF/common/services/ioport/mega/ioport.h are written based on that same assumption. Any ATMega64/128 projects that wish to use this ASF code will fail, tested and verified.
This is the struct in the file ASF/common/services/ioport/mega/ioport.h
/* I/O Ports */
typedef struct PORT_struct {
volatile uint8_t PINCRL; /* I/O Port PIN DATA READ ONLY */
volatile uint8_t DIR; /* I/O Port Data Direction Set */
volatile uint8_t PORTDATA; /* I/O Port DATA register */
} PORT_t;
I wonder how many other ATMega chips have a stray port define?