>> There are plans for introducing multiple address spaces in the next C
>> standards, but I'm not holding my breath waiting for the
>> implementations.
>
> Exactly right, and in the end that was the downfall of the AVR for
> me. That's why I don't really see the point of these new big
> devices. As the memories get bigger and the I/O more capable, the core
> must be taking up proportionally less and less area. So why not go for
> a 32 bitter and be done with it?
>
> -- 
>
> John Devereux

There are multiple AVR32's on the market already ;-)

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

David Brown wrote:

> David Kelly wrote:
> > David Brown wrote:
> >
> >> As for making it entirely von Neumann, I think that's a bit too big a
> >> change - but it would have been perfectly possible to make the flash
> >> accessible in the data space as well (in the same way as the eeprom is
> >> now mapped into the data space).  You'd need 24-bit pointers to access
> >> it, but it would still be a very useful feature.
> >
> > What AVR has EEPROM mapped into data space?
> >
>
> The XMega - at least for reading the eeprom (I haven't read the
> datasheets in detail).
>
> > Using lpm isn't terribly painful. No doubt motivated C compiler authors
> > could hide the AVR FLASH constant data access mechanics, if only there
> > was motivation.
>
> No, you can't hide it.  C only understands a single address space for
> data.  There is no way to express ideas such as a pointer that is
> accessed by "lpm" instead of "ld", and there is no way to write a
> function with a pointer parameter which will work with both a pointer to
> flash and a pointer to ram.  There is plenty of motivation for C
> compiler writers, but they are restricted by the language and by
> existing compiler parts (since most compilers share parts with other
> targets).  Solutions include macro wrappers (used by avr-gcc - fully
> standard C, but a bit ugly), abusing the "const" keyword (used by
> ImageCraft, until recent versions - very clear and neat, but
> non-standard and causes trouble for other use of "const"), a new "flash"
> keyword (used by IAR - neat and clear, but non-standard), and
> generalised pointers (the only standards-compliant way to get full
> pointer functionality - but big and slow).
>
> There are plans for introducing multiple address spaces in the next C
> standards, but I'm not holding my breath waiting for the implementations.

The Philips MX51 core extension, handled this by keeping the opcode
basis of separate memory, but also overlaying/re-mapping the DATA
space into the
TOP of code space. That halves the memory span, but once you have gone
past
64K, no uC I have seen get anywhere close to filling up the 24/32 bit
address
space.
The result is the low level stuff stays the same, but you can access
ANY
code as data (and I guess, jump into RAM and run code there.. ?.)

It would have been an obvious thing to do on the XMEGA ?

-jg

Hans-Bernhard Br&ouml;ker <HBBroeker@t-online.de> writes:

> David Brown wrote:
>
>> No, you can't hide it.  
>
> Au contraire.  It can be done, and it has been done.
>
>> C only understands a single address space for data.  
>
> That's correct, but not as relevant to the issue at hand as one might
> think.  The trick is that there's no requirement that the single
> address space known by C map directly to any of the address spaces of
> the CPU. E.g. in the Keil C compiler for the 8051, a standard C
> pointer is constructed of two parts: one byte to identify the memory
> space, and two bytes to hold the actual address.
>
> The downside, of course, is that such pointers are big, clumsy and
> CPU-expensive to handle.  Every access has to be decoded by somewhat
> involved code that checks which memory space is being used, and then
> accesses the relevant address.  Which is why in addition to the C
> standard pointer type, Keil supports memory space-specific pointers
> that don't cause the extra cost or storage.

Which is precisely what he meant by the "big and slow" "generalised
 pointers" in the bit you snipped!

-- 

John Devereux

David Brown wrote:

> No, you can't hide it.  

Au contraire.  It can be done, and it has been done.

> C only understands a single address space for 
> data.  

That's correct, but not as relevant to the issue at hand as one might 
think.  The trick is that there's no requirement that the single address 
space known by C map directly to any of the address spaces of the CPU. 
E.g. in the Keil C compiler for the 8051, a standard C pointer is 
constructed of two parts: one byte to identify the memory space, and two 
bytes to hold the actual address.

The downside, of course, is that such pointers are big, clumsy and 
CPU-expensive to handle.  Every access has to be decoded by somewhat 
involved code that checks which memory space is being used, and then 
accesses the relevant address.  Which is why in addition to the C 
standard pointer type, Keil supports memory space-specific pointers that 
don't cause the extra cost or storage.

David Brown <david@westcontrol.removethisbit.com> writes:

> David Kelly wrote:
>> David Brown wrote:
>>
>>> As for making it entirely von Neumann, I think that's a bit too big
>>> a change - but it would have been perfectly possible to make the
>>> flash accessible in the data space as well (in the same way as the
>>> eeprom is now mapped into the data space).  You'd need 24-bit
>>> pointers to access it, but it would still be a very useful feature.
>>
>> What AVR has EEPROM mapped into data space?
>>
>
> The XMega - at least for reading the eeprom (I haven't read the
> datasheets in detail).
>
>> Using lpm isn't terribly painful. No doubt motivated C compiler
>> authors could hide the AVR FLASH constant data access mechanics, if
>> only there was motivation.
>
> No, you can't hide it.  C only understands a single address space for
> data.  There is no way to express ideas such as a pointer that is
> accessed by "lpm" instead of "ld", and there is no way to write a
> function with a pointer parameter which will work with both a pointer
> to flash and a pointer to ram.  There is plenty of motivation for C
> compiler writers, but they are restricted by the language and by
> existing compiler parts (since most compilers share parts with other
> targets).  Solutions include macro wrappers (used by avr-gcc - fully
> standard C, but a bit ugly), abusing the "const" keyword (used by
> ImageCraft, until recent versions - very clear and neat, but
> non-standard and causes trouble for other use of "const"), a new
> "flash" keyword (used by IAR - neat and clear, but non-standard), and
> generalised pointers (the only standards-compliant way to get full
> pointer functionality - but big and slow).
>
> There are plans for introducing multiple address spaces in the next C
> standards, but I'm not holding my breath waiting for the
> implementations.

Exactly right, and in the end that was the downfall of the AVR for
me. That's why I don't really see the point of these new big
devices. As the memories get bigger and the I/O more capable, the core
must be taking up proportionally less and less area. So why not go for
a 32 bitter and be done with it?

-- 

John Devereux

David Kelly wrote:
> David Brown wrote:
> 
>> As for making it entirely von Neumann, I think that's a bit too big a 
>> change - but it would have been perfectly possible to make the flash 
>> accessible in the data space as well (in the same way as the eeprom is 
>> now mapped into the data space).  You'd need 24-bit pointers to access 
>> it, but it would still be a very useful feature.
> 
> What AVR has EEPROM mapped into data space?
> 

The XMega - at least for reading the eeprom (I haven't read the 
datasheets in detail).

> Using lpm isn't terribly painful. No doubt motivated C compiler authors 
> could hide the AVR FLASH constant data access mechanics, if only there 
> was motivation.

No, you can't hide it.  C only understands a single address space for 
data.  There is no way to express ideas such as a pointer that is 
accessed by "lpm" instead of "ld", and there is no way to write a 
function with a pointer parameter which will work with both a pointer to 
flash and a pointer to ram.  There is plenty of motivation for C 
compiler writers, but they are restricted by the language and by 
existing compiler parts (since most compilers share parts with other 
targets).  Solutions include macro wrappers (used by avr-gcc - fully 
standard C, but a bit ugly), abusing the "const" keyword (used by 
ImageCraft, until recent versions - very clear and neat, but 
non-standard and causes trouble for other use of "const"), a new "flash" 
keyword (used by IAR - neat and clear, but non-standard), and 
generalised pointers (the only standards-compliant way to get full 
pointer functionality - but big and slow).

There are plans for introducing multiple address spaces in the next C 
standards, but I'm not holding my breath waiting for the implementations.

David Brown wrote:

> As for making it entirely von Neumann, I think that's a bit too big a 
> change - but it would have been perfectly possible to make the flash 
> accessible in the data space as well (in the same way as the eeprom is 
> now mapped into the data space).  You'd need 24-bit pointers to access 
> it, but it would still be a very useful feature.

What AVR has EEPROM mapped into data space?

Using lpm isn't terribly painful. No doubt motivated C compiler authors 
could hide the AVR FLASH constant data access mechanics, if only there 
was motivation.

Ulf Samuelsson wrote:

> "Vladimir Vassilevsky" <antispam_bogus@hotmail.com> skrev i meddelandet 
> news:wZHxj.9956$5K1.7906@newssvr12.news.prodigy.net...

>>I bet in less then 2 years it will be discontinued,
> 
> OK, I take you on.
> Would you accept a $10 bet!

Fine with me. I state that more then one of the devices of ATXmega 
family will be discontinued no later then in 2 years after the it will 
show up in stock at DigiKey.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Le Fri, 29 Feb 2008 09:32:13 +0100, Ulf Samuelsson a écrit:

> "Vladimir Vassilevsky" <antispam_bogus@hotmail.com> skrev i meddelandet 
> news:wZHxj.9956$5K1.7906@newssvr12.news.prodigy.net...
>>
>>
>> Ulf Samuelsson wrote:
>>
>>> For people in this newsgroup that has been wondering...
>>>
>>>
>>> Key features
>>> * ATmegaAVR core (just higher frequency)
>>> * 1.6V-3.6V operation
>>> * Flash (max 384 kB)/SRAM/EEPROM
>>> * 32 Mhz operation (max 32 MIPS)
>>
>>
>> No, thanks.
>>
>> I bet in less then 2 years it will be discontinued,
> 
> OK, I take you on.
> Would you accept a $10 bet!
Do not panic guys! I manage the fund bets.

Now attention ladies and gentlemen, nothing more going !


> 
> The standard AVR family will not be replaced by this, since
> the X-Mega is not a 5 Volt device.
> 
>> as it is usual with Atmel. The recommended replacement would be, say, 
>> Y-Mega or Z-Mega, which are almost compatible except for some fine issues 
>> and the unpredictable changes in the configuration bits. Ahhhh, the cost 
>> will be higher, too.
> 
>>
>>
>> Vladimir Vassilevsky
>> DSP and Mixed Signal Design Consultant
>> http://www.abvolt.com
>>
> 
> 
>



-- 
HBV

>>
>> Is the AVR opcode map fully packed ? - just use a spare one ?
>>
>>  They have added opcodes over the years, but DROPPING an opcode is much 
>> more dangerous. (and would be a no-no - "safe superset" is tolerable. )
>>
>
> I believe it is mostly full, but there should be some space left.  The 
> datasheets and application notes do not have a summary ordered by opcode, 
> so it's not easy to see.
>
> Certainly dropping opcodes is much more involved than adding new ones, and 
> should only be done if there is a great deal to gain.
>
>>
>>>> The decision was made to not change the CPU core.
>>>>
>>>
>>> Obviously that's the decision - the AVR designers are not daft, and it's 
>>> easy to see the advantages that changes like these would have.  I 
>>> therefore assume they felt improvements to the core would be too 
>>> disruptive to the design or the tools.
>>
>> and keep in mind they have AVR32 (& ARM ) in the stable as well.
>> So 'creeping featurism' of the core is not going to open new markets,
>> but just give more overlap with AVR32.
>>
>
> Atmel's microcontrollers already overlap - if this was a worry for them, 
> then the AVR Mega 256 would not exist, and probably not the XMegas either.
>

Freescale would REALLY be in trouble...

>> The sizzle in uC these days is less the core, and more the peripherals
>> - and from  what I've seen of the xmega peripherals they have done a nice 
>> job in advancing the peripheral suite.
>>
>
> Yes, it's the peripherals that make the XMega particularly interesting. 
> It's also worth noting that doubling the frequency of the core makes more 
> of a difference than the speed increases that could be gained with 
> enhancing the cpu.

Actually, for the 3V market, the performance is quadrupled.

>
>> Perhaps some will now 'morph-over' into AVR32 / LPC51 ?
>>
>> Seems they never wanted 'not enough uarts' to be a design-miss :)
>>

No, it is regularity of design, which matters.
Also this simplifies development kits.
If you develop an I/O module on a separate PCB for the digital block,
then you can connect it to any of the digital I/O ports on the chip.


>
> We recently did a design with a AVR Mega that needed a total of 6 uart 
> channels, so it needed an external UART device.  The XMega would have 
> fitted very nicely here.
>
>> They also fixed some of the blindspots, and made it less of a step-back
>> from a 80C51 ;).
>>
>> interrupt priority levels are now there, and port toggle is also
>> possible & I think I saw some means of better SFR mapping too....
>>
>> (no register bank switching, but perhaps with DMA and Event control,
>> you have fewer critical interrupts alive anyway... )
>>
>> -jg
>>
>>



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB