RE: [avr-gcc-list] Xmega class confusion?

[Weddington, Eric]

> -----Original Message-----
> From: Erik Walthinsen [mailto:address@hidden 
> Sent: Friday, June 04, 2010 2:45 AM
> To: Weddington, Eric; avr-gcc-list
> Subject: Re: [avr-gcc-list] Xmega class confusion?
> 
> On 06/03/2010 05:05 PM, Weddington, Eric wrote:
> > Also take a look at the comments for avr.c in the patch. 
> There it shows the classification of the devices. Those 
> devices that are in an architecture that says ">  64K RAM" 
> means the possibility of using external RAM.
> Right, that's the table I copied into my original post.  
> There are two 
> inconsistencies I'm trying to understand and make sure are correct:
> 
> 1) the 32a4 is listed as avrxmega3, which is 8-64KB Flash, and >64KB 
> RAM.  Problem is, *only* the A1 series chips have an EBI, so 
> the 32a4 is 
> not capable of more than the 4KB it comes with.  The 32d4 is 
> correctly 
> listed as avrxmega2, <=64KB RAM.

Ok, I'll take a second look.

> 
> 2) all the class boundaries are very clearly delineated as 
> far as which 
> boundaries are *in* the window, and which are *outside*.  
> avrxmega5 is 
> listed as > 64KB and <= 128KB (and >64KB RAM), yet the only chip ever 
> put in that range is the 64a1.  That's inconsistent, as 64KB 
> is not > 64KB.
> 
> !!!!! *brainstorm* I think I might have realized where the 
> confusion is, 
> and how it can be rectified in comments and documentation:
> 
> The > <= window for flash *includes* the bootloader space.  
> That means 
> the 64a4 is actually 64KB + 4KB, so it falls within the "> 
> 64KB" rule. 
> If that's the reason, then the comments and docs should indicate that 
> "flash size includes bootloader", and that will clear up any 
> confusion. 

IIRC, that is correct. Anatoly Sokolov originally made this organization.

 

>   I can draft a patch to that effect.

We just have to modify those comments in the patch.
 
> > And yes this patch will be in the next toolchain release, of course.
> Do you mean the mainline binutils/gcc release, or WinAVR et al?

Both, sort of. It will be in a toolchain distribution release, but not 
specifically WinAVR because WinAVR has been discontinued. This patch will also 
eventually make it to the upstream projects. I'm hoping sometime over the 
summer.