[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Weddington, Eric
Subject: RE: [avr-gcc-list] Xmega class confusion?
Date: Thu, 3 Jun 2010 19:03:20 -0600


> -----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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]