> Eric Weddington wrote:
> atmega128a atmega168pa atmega16a atmega324pa atmega32a
> atmega32u6 atmega64a atmega88pa atmega8a attiny13a
For anyone that is keeping score these are the new devices since
the last public release of AVRStudio 4.14.589, that are now in
the just released version, 4.15.623:
AT90USB82, ATmega128A, ATmega168PA, ATmega16A, ATmega16U4,
ATmega324PA, ATmega32A, ATmega32HVB, ATmega32U6, ATmega64A,
ATmega88PA, ATmega8A, ATtiny10, ATtiny13A, ATxmega128A3,
ATxmega256A3, ATxmega256A3B, ATxmega64A3
> Rolf Ebert, wrote:
> My reason for asking are the separate XML files in AVR Studio.
> I have simply looped over all devices that have XML files.
Rolf, if it helps you any I wrote a program that aggregates all of
the individual XML files into one single XML file. This is for
the AVRDude GUI I've been hacking on, all to slowly. It
standardizes many of the sections to a single format for
downstream tools to use. The file is unencumbered by Atmel
distribution issues, that the Studio part description files have.
Source code and the preprocessed file may be found here:
http://www.designer-iii.com/AVR/PartDescriptionXMLAggregator/
> Even if a device is a complete one to one replacement we need
> to teach the new alias name to the compiler.
I cringe every time I hear about a die shrink "that will not
change anything to the end user". I've been burned by parts
that are "drop in" several time in the past. To say nothing
of the regulator can of worms such changes can open
by added a letter like "A" to the part number.
Is there anyway to distinguish these new parts from the running
program to take advantages of new features?
--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/ http://www.designer-iii.com/
http://www.unusualresearch.com/
_______________________________________________
AVR-libc-dev mailing list
AVR-libc-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-libc-dev
