clawson 
I'm just starting to play with my very first Xmega (an xmega32A4U) and my first question:
Did I miss something - what lives between 0x0020..0x002F?.
I understand:
0x0000..0x000F are the general purpose registers, then
0x0010..0x001F are the VPORTs and
0x0030..0x003F has CPU specific registers like SPL, SPH, SREG, CCP, RAMP*, EIND
but surely they cannot have wasted 0x0020..0x002F which is the only other locations in range of IN/OUT?
Cliff
condemned 
iox32a4.h turns up:
#define OCD (*(OCD_t *) 0x002E) /* On-Chip Debug System */
and
/* OCD - On-Chip Debug System */ #define OCD_OCDR0 _SFR_MEM8(0x002E) #define OCD_OCDR1 _SFR_MEM8(0x002F)
So that leaves 0x0020 to 0x002D to ponder over.
indianajones11 
...but surely they cannot have wasted 0x0020..0x002F which is the only other locations in range of IN/OUT ?
clawson
Too bad, they could've at least added more Virtual ports with it...
indianajones11 Have they lost the plot or something?
clawson
Cliff have you tried coding for USB yet and how did it go if you did ?
js 
What's wrong with having unused addresses? Maybe they are reserved for future devices? Look at the I\O address space for most Mega chips, dozens of "spare" unused addresses.
And Cliff watch you language, remember it is an Atmel forum... :)
clawson
What's wrong with having unused addresses?
I'm talking about the 0x00..0x3F address range - the locations where IN/OUT can be used in preference to LDS/STS. These are "precious" locations yet it seems that Atmel have wasted at least 16 of the 64 possible locations. I don't know if you know about Xmega but they have these things called VPORTs (four of them - 4 registers for each) which allow you to map any four out of PORTA..PORTR to a low location so the DIR/IN/OUT registers are in range of the IN/OUT instructions. It's a great feature as you get to pick which of your ports are in the "fast access" area (in fact they are in range of SBI/CBI too as they are at 0x10..0x1F). But then 0x20..0x2F is virtually unused. While it would be out of range of SBI/CBI at least some more ports mapped there could have benefitted from IN/OUT access.
BTW here is a very short program I've been testing the facilities with in the simulator:
int main(void) {
// map A, B, C and D to the virtual ports
PORTCFG_VPCTRLA = PORTCFG_VP02MAP_PORTA_gc | PORTCFG_VP13MAP_PORTB_gc;
//PORTCFG_VPCTRLB = PORTCFG_VP02MAP_PORTC_gc | PORTCFG_VP13MAP_PORTD_gc;
//PORTB_DIR = 0xFF;
//PORTB.DIR = 0xFF;
VPORT1_DIR = 0xFF;
//VPORT1.DIR = 0xFF;
while(1) {
VPORT1_OUT |= (1 << 3);
}
}
The first active line there maps PORTA=VPORT0, PORTB=VPORT1. The next commented line would map PORTC=VPORT2, PORTD=VPORT3.
The following two commented lines are two ways of doing the same thing (setting PORTB to output) but these involve an STS up at about 0x600 somewhere (which is where the real DDRB, or should I say PORTB.DIR, lives).
The uncommented line actually sets the PORTB to output by writing to the DIR register of VPORT1. (the following line shows the alternative access method .DIR rather than _DIR) The code inside the loop setting bit 3 of VPORT1 (PORTB) generates the SBI I was hoping for.
Cliff