Die lange erwarteten XMEGA-Controller von Atmel scheinen langsam Gestalt anzunehmen. Auf der Atmel-Webseite sind sie seit heute erstmals unter den Produkten aufgeführt.

Die XMEGA-Reihe basiert auf dem erfolgreichen 8 Bit AVR-Kern, enthält aber einige interessante Neuerungen:

• DMA
• Crypto-Engine für AES und DES: einfach Key und Daten in Register schreiben, der Rest läuft automatisch
• Event-System: ähnlich Interrupts, aber für die Kommunikation zwischen Peripherieeinheiten ohne CPU-Beteiligung

Die Speicherausstattung ist mit bis zu 256 kB Flash und 16 kB RAM ähnlich wie bei den ATmegas, dazu kommen bis zu 8 UARTs, mehrere bis zu 2 MS/s schnelle 12 Bit AD- und DA-Wandler sowie 8 Timer. Für Bastler gibt es allerdings eine schlechte, wenn auch nicht überraschende Nachricht: es sind keine 5 V-kompatiblen Modelle angekündigt (die spezifizierte Betriebsspannung ist 1,6 bis 3,6 V), DIL-Gehäuse sucht man ebenfalls vergeblich.

Mehr Informationen gibt es auf der XMEGA-Webseite von Atmel und im ATxmega Manual.

Das mit den 5V ist natuerlich bloed... :( Gerade wenn man mit
CMOS-Bausteinen arbeiten will, fuer die 5V eigentlich schon bald zu
wenig ist. Aber ansonsten sind die Dinger echt heiss. Leider hab ich nen
Foliensatz gesehen auf dem Stand dass mit Massenprodukltion fruehestens
im Q1 2009 angefangen wird. Fuer Q1/Q2 2008 sind lediglich Samples
beziehbar. Die ganz grossen Modelle mit mehr als 64 Pins sind uebrigens
nur im BGA-Gehaeuse erhaeltlich.

Michael

Michael G. wrote:
> Fuer Q1/Q2 2008 sind lediglich Samples beziehbar.

Theoretisch. Praktisch eher nicht, zumindest für Normalkunden. Zumindest
wurde mir das am Atmel Stand auf der Embedded World gesagt.
Preislich sollten die ein kleinwenig über den vergleichbaren ATmegas
liegen, die dann zunehmend auslaufen.

Erhältlich sollen die ab Mitte 2008 sein. Ich rechne aber eher mal mit
Ende 2008.

Nett finde ich auch die mit 128MHz laufende Peripherie.

Michael G. wrote:

> Die ganz grossen Modelle mit mehr als 64 Pins sind uebrigens
> nur im BGA-Gehaeuse erhaeltlich.

Laut der Webseite gibt's neben CBGA100 immer noch TQFP100.  Irgendwie
muss man die Teile ja schließlich auch in den STK600 reinstecken
können...

TQFP100 ist zwar mit 0,5-mm-Raster nicht gerade das allerbastler-
freundlichste auf der Welt, aber zumindest keine Änderung gegenüber
den derzeit größten ATmegas (ATmegaXXX0) und hobbymäßig schon noch
beherrschbar.

Ich hab gerade nen 144pinner Verlötet, alles im Rahmen des möglichen,
die Platine war allerdings gefertigt.

Ich freue mich auch schon sehr auf die Controller :D

DMA und  Eventsystem finde ich besonders Interessant, auch im Bezug auf
den schnellen ADC. Von den vielen Timern brauch ich garnicht erst
anfangen zu schwärmen :D

Es gibt wahrscheinlich auch noch kein einziges Exemplar ohne USB zu
kaufen.

Und, dass es kein Ethernet gibt, stört mich auch noch ein wenig ;)

Andreas Kaiser wrote:
> Es gibt wahrscheinlich auch noch kein einziges Exemplar ohne USB zu
> kaufen.

DIE aussage musst du mir erstmal erklären !

Marc Seiffert wrote:

> DIE aussage musst du mir erstmal erklären !

Siehe Benedikt. Bis die jetzt angekündigten Varianten verfügbar sein
werden, wird noch einige Zeit ins Land gehen. Bis dahin gibt es also
weder welche mit USB noch welche ohne USB.

USB und Ethernet kommen warscheinlich noch (laut Atmel Stand auf der
Embedded)

Mich amüsiert halt die Begeisterung etwas, mit der sich viele auf alles
stürzen was neu ist, bloss weil es neu ist und alles was neu ist
unbedingt immer zwangsläufig viel besser sein muss als alles bekannte.
Der HABEN MUSS!!!!! Effekt ;-)

PS: Bei Controllern ist man deutlich besser dran, wenn man nicht der
Erstkunde ist, sondern anderen bei der Fehlersuche den Vortritt lässt.

Naja also der IS ja auch wirklich um einiges "besser" als die jetzigen
Megas... ;) Und klar muss ich den haben hehe...

Benedikt K. wrote:

> Preislich sollten die ein kleinwenig über den vergleichbaren ATmegas
> liegen, die dann zunehmend auslaufen.

Wenn Atmel tatsächlich signalisiert haben sollte, dass die bestehenden
Linien in wenigen Jahren eingestampft werden, dann wünsche ich Atmel
eine gute Nacht. Denn damit würden sie sie allen vom Volumen her
signifikanten Kunden signalisieren, dass man besser heute als morgen
eine andere zeitlich stabilere Plattform suchen sollte, also sowohl um
die alten als auch die neuen AVRs einen Bogen machen sollte.

Oops wrote:

>>den vergleichbaren ATmegas liegen, die dann zunehmend auslaufen.
>
> Vermute ich richtig, das das auch eine Aussage von der Embedded war?

Ja.

> Haben die irgendeinen Zeitpunkt genannt? Oder wann welche Modelle
> auslaufen?

Nein. Die haben nur gesagt, dass die XMEGAs dann die normalen ATmegas
etwas verdrängen sollen, die dann langsam zurückgehen. So habe ich das
zumindest verstanden.
So wie Atmel aber bisher gefahren ist, wird es aber 1. lange dauern, und
2.  irgendeinen Ersatz geben, der zumindest großteils kompatibel ist. So
war es ja auch bisher bei den Classic AVRs.
Ich denke also nicht, dass Atmel in nächster Zeit die alten AVRs
komplett aufgeben wird, langfristig dagegen schon (wie bei allen
Hersteller werden die 5V Bauteile irgendwann ausgemustert, notfalls über
einen steigenden Preis.)

Klar, ich hab auch den "Haben-Wollen-Effekt" bei mir festgestellt.

Für was braucht man bitte die Krypto-Engine? Ich könnte mir kein Produkt
vorstellen, bei dem man ein XMEGA benutzen würde und größere Datenmengen
zu verschlüsseln hätte.
MP3-Player: Der AVR wird wohl zu schwach sein MP3s alleine zu
dekodieren.
Kleinere Geräte mit wenig Speicher: die können auch grad noch in
Software en/dekodieren.
Festplatten-Controller mit AVR: trotzdem zu laaaangsam...

Habt ihr da ne Idee?

Vieleich haben die sich das bei M$ abgeschaut und man kann dann nur noch
zertifizierte Hardware mit DRM an die Ports anschliessen ;-)

Gruß Jörg

Benedikt K. wrote:

> wie bei allen Hersteller werden die 5V Bauteile irgendwann
> ausgemustert, notfalls über einen steigenden Preis.)

Die Originalfabrikation vom ab 1971 produzierten NE555 wurde erst 2003
eingestellt, und auch das nur weil die letzte zur Fertigung geeignete
Fabrik abgebrannt war und beliebig viele Zweithersteller existierten.

FBI wrote:
> laut Atmel Webseite sollen die ATxmega128A1 und ATxmega64A1 ab sofort
> verfügbar sein ("available now"). Preis: US$3.75/3.50 ("10k unit
> price").

Ich war auch auf der Embedded World. Die Teile sind echt noch nicht
erhältlich. Es sind nur erste Muster im TQFP100 für das STK600 existent.

Oops wrote:
> Gab's denn auf der Embedded schon Muster von ATxmega128A1 und
> ATxmega64A1?

Ja.
Ein STK600 war das glaube ich mit einem LCD drauf und ein paar Tastern
und LEDs. Daneben ein zweites. Beide über TWI verbunden. Auf Tastendruck
wurde eine codierte Message übertragen, dekodiert und die entsprechende
LED angesteuert.

Dann war noch ein kleines Board da, das von einer SD Karte glaube ich,
Wave Files über den internen DAC abspielte.

Ich war heut auch auf der Embedded und da sagte man mir, bei den
ATmegaXXX ist kein Auslaufen geplant, sondern die ATXmega werden
ungefähr im selben Preissegment wie die jetzigen großen Megas sein und
diese ein wenig im Preis nach unten drücken; Aussage war: Mehr Leistung
zum gleichen Preis.

Gute Nacht
Wolfgang

cool. gerüchte gibt es ja schon lange. mit einer taktfrequenz von 32MHz
wird die "rechnerische" leistung eigentlich in etwa verdoppelt. obwohl
ich noch nie an der grenze eines avrs war finde ich das ziemlich
interessant.

weiss jemand etwas genaueres über die programmierung? über die
C-Programmierung gibt es nun eine doku auf der atmel site. Aber wie
sieht es aus mit Assembler??? ich habe im datenblatt auch keine
assemblerbefehle gefunden?!?

ATmega2560: 135 Befehle.
ATxmega A: 135 Befehle.
Beantwortet das deine Frage?

135 = 135

also in etwa das selbe!?!

Ja. Bei dem Infomaterial das ich mitgenommen habe, steht: Pin und
Softwarekompatibel zu den ATmegas.

Was mir noch gesagt wurde, ist:
1. angeblich ist die gnu-tool-chain schon fertig, soll demnächst
veröffentlicht werden
2. AVR-Studio ist angeblich auch schon fertig, soll auch bald raus
kommen
3. Atmel will einen eigenen Shop für die Entwicklungstools eingerichtet
haben, nur da finde ich bisher nichts auf der Seite. Wäre stark, wenn's
dort dann die Chips auch schon in kleinen Stückzahlen für ein paar Euro
geben würde.

MfG
Wolfgang

Anonymous wrote:

> Solange Atmel keine normalen DIL ICs anbietet werden die sich das Teil
> von meiner Seite aus in den A. schieben können.

Meinst du, ein anonymer Hintern interessiert irgendeinen Halbleiter-
Hersteller?

@ anonymer Hintern

meinst du ? das wir paar Hobbybastler für Atmel das große Geschäft
darstellen ? Die Aabsatzquoten durch Hobbybastler bewegen sich doch
HÖCHSTENS im einstelligen %-Bereich, da überlegt sich die Fa. Atmel
sicher 2 mal ob sie wirklich speziell für uns angepasste Produkte
rausbringt. Vor allem wenn man bedenkt, das unter den Hobbybastlern
wiederrum auch ein großteil mit SMD-Bauteilen sehr zufrieden ist, bzw.
diese sogar präferiert (ich baue nur noch ab und an THT um alte Bauteile
loszuwerden ;) )

Marc Seiffert wrote:
> Vor allem wenn man bedenkt, das unter den Hobbybastlern
> wiederrum auch ein großteil mit SMD-Bauteilen sehr zufrieden ist, bzw.
> diese sogar präferiert (ich baue nur noch ab und an THT um alte Bauteile
> loszuwerden ;) )

Eben... geht mir genauso. Solange die Pitches nicht so fein werden, dass
man das Layout nicht mehr hinbekommt oder von grossen BGAs die Rede ist,
die man nur mit Multilayer besiegen kann, ist es doch vollkommen OK. Ich
komme mit QFP und sogar SSOP-Packages eigentlich wunderbar zurecht. Der
Platzgewinn ist doch auch enorm.

die Bastler und Studenten von heute sind die Ingenieuere von morgen, ich
glaube nicht das Atmel keinen Wert auf diese Gruppe legt. Aber an SMD
Bauform soll es doch nun wirklich nicht liegen, per Adpater oder als
fertiges CPU-Modul kann man solche Prozessoren immer noch einsetzen.
Gerade die Module sind interessant weil man da ja z.B. heute schon
ARM+viel Ram+viel Flash draufbekommt in Grösse etwa eines DIP40
Gehäuses.
Interessanter finde ich die (hoffentlich noch bald kommenden) Megas mit
integriertem USB, Ethernet oder CAN. Gerade wo heute alles vernetzt wird
braucht man einfache und billige Lösungen. Geht natürlich schon mit
Mega+Enc28J60, aber eine integrierte ein-Chip Lösung wäre da schon
smarter.

Wer am Werkzeug und am Lernen spart, sollte nicht über kleine
IC-Bauformen herziehen, die noch dazu viel praktischer sind. Solange da
immer noch Pins dran sind, ist die Welt doch in Ordnung.

Mike wrote:

> Hat sich ja nix geändert.
> Nur die Startup- und Header-Files müssen ergänzt werden.

Naja, der Compiler leider auch.  Hat sich doch bisschen mehr geändert,
bspw. sind jetzt die IO- und MMIO-Adressen gleich (nicht mehr mit
Offset 0x20), weil man das Einblenden der CPU-Register in den RAM-
Adressraum aufgegeben hat.  Außerdem, wenn ich es recht gesehen habe,
können einige der Xmegas mehr als 64 KiB RAM adressieren.

Eric Weddington arbeitet da seit einiger Zeit dran, und Anatoly
Sokolov ist ebenfalls involviert.

Paul Baumann wrote:
>>Doch nur eine Handvoll Stümper.
> Es heißt SMD. Das zum Stümper.
SMT ist der Oberbegriff (Surface Mount Technology), SMD bezeichnet die
Bauteile an sich (Surface Mounted Device(s))...

@ Olaf

also bei z.B. nem DIL20 auf nen SO20 ist tatsächlich nur ein kleiner
Platzgewinn vorhanden...der Unterschied zwischen DIL28 und TQFP32(Mega8)
ist dagegen enorm. Ich kann dir gerne layouts schicken die das
einwandfrei Belegen ;) Ausserdem ist es arg Vorteilhaft, wenn man auf
der Rückseite SMD-Bauteile hat und auf der Vorderseite nur die stecker
u.ä. ;)

ansonnsten, manchmal wenns schnell gehen soll oder ich eh Platz ohne
ende habe ist THT ja auch ganz praktisch, geht flott aufgebaut und ist
weit leichter zu "debuggen"....auf nem THT-Board kann man praktisch
alles nochmal neu verdrahten, auf nem SMT nicht...aber eigentlich sollte
das layout ja eh Fehlerfrei sein wenn denn mal realisiert wird ;)

Gruß, Marc

Jadeclaw wrote:

> Und hier kommt der große Vorteil von THT zum Tragen -->
> Steckbretttauglich.

Gut gepaart mit dem großen Nachteil von Steckbrettern: ihrer
enormen Kapazität.

Wenn du mit den Xmegas basteln willst, wirst du kaum um sowas wie
einen STK600 herum kommen (und selbst dort haben sie sicher schon
Ärger mit Kapazitäten und Leitungslängen).

Olaf wrote:
>> Der Platzgewinn ist doch auch enorm.
>
> Ich sehe im privaten Umfeld eigentlich keinen so grossen
> Platzgewinn. Dadurch das man nur schlecht zwischen zwei
> Beinen routen kann verliert man auch wieder was.

Willst Du mir sagen dass Du es mit einer professionell gefertigten
Platine schaffen willst bei einem Pitch-Abstand eines SSOP oder TQFP
eine Leiterbahn durchzurouten? Ich glaube es mal kaum ;)

Ich habe auf der eingebetteten Welt gestern mitgehört, wie ein Atmeller
zu den anderen meinte, dass er ja so glücklich wäre, weil die XMegas im
Demoaufbau alle noch laufen... da darf sich jetzt jeder selber denken,
ob nur allgemein die Software oder speziell die Xmega Chips gemeint
waren. :-)

Ansonsten habe ich sie bezüglich DebugWire Doku gelöchert und leider
eher peinliche Ausreden gehört. Das DebugWire Protokoll soll nach wie
vor nicht veröffentlicht werden, weil es 1. nicht gut dokumentiert ist
(LOL) und 2. es schon genug Probleme für den Endkunden im Zusammenhang
mit den offiziellen DebugWire Tools (AVR Dragon und JTAG ICE mkII) gäbe,
wegen fuse Umstellung per ISP vor und nach dem Debuggen (naja...). Und
ausserdem sei Atmel ja trotzdem nicht am reinen Toolverkauf als
Kerngeschäft interssiert... (öööh, hä? Wie passt das zu 1. und 2.?)

Ich hatte leider den Eindruck, dass den beiden Herren alles andere als
bewusst war, dass die Bastler von Heute u.U. durchaus die 100k
Bestellungen von Morgen mitbestimmen...

Oliver Keller wrote:

> Ansonsten habe ich sie bezüglich DebugWire Doku gelöchert und leider
> eher peinliche Ausreden gehört.

Willst du denn ernsthaft einen AVR Dragon selbst nachbauen?

Gerade der Bereich DebugWIRE ist doch damit erschöpfend und
preiswert abgedeckt.

> Und
> ausserdem sei Atmel ja trotzdem nicht am reinen Toolverkauf als
> Kerngeschäft interssiert... (öööh, hä? Wie passt das zu 1. und 2.?)

Das passt schon.  Sie wollen halt die Tools nur nicht völlig für
lau pflegen und unterstützen.  Gewissermaßen bezahlst du mit einem
JTAG ICE mkII außer der Hardware einen kleinen Teil der
Entwicklungskosten und eine oder zwei Stunden Support, die du
damit im Laufe der Lebensdauer des ICE früher oder später ja doch
generieren wirst.

> Ich hatte leider den Eindruck, dass den beiden Herren alles andere als
> bewusst war, dass die Bastler von Heute u.U. durchaus die 100k
> Bestellungen von Morgen mitbestimmen...

Ja, und?  Bei den 100k-Bestellungen kauft dein Chef die 10 JTAG ICEs
aus der Portokasse.  Das Einzige, was ich sehe, das Sinn hat ist,
dort (gerade im Zusammenhang mit den Xmegas) zu nerven, dass man die
Teile künftig auch mit dem AVR Dragon debuggen kann.  Die wesentlichen
Industrieanwender werden ohnehin beim JTAG ICE bleiben.  Erstens
könnte man ganz offiziell den Endkundensupport für den Dragon auf
ein Minimum reduzieren (während JTAG ICE Kunden welchen bekommen),
zweitens macht der Dragon im rauhen Laborbetrieb keinen Spaß.  Allein
die Gefahr, dass er auf Grund des fehlenden Gehäuses irgendwo einen
Kurzschluss verursacht, sollte gut die paar Hunderter für ein richtiges
ICE ausmachen, nimm noch dazu die Zeit, die man mit dem Basteln der
Kabel verbringen darf -- eine Ingenieursstunde kostet ab EUR 50
aufwärts.

Um allen Gerüchten vorzubeugen, ist es wohl das beste, die Teile zu
testen. Bin mal auf die Samples gespannt. Wenn die Teile bestehen,
werden wir sie auch zu Hunderten verbauen :-).

Jörg Wunsch wrote:
> Willst du denn ernsthaft einen AVR Dragon selbst nachbauen?

Ich finde die Vorstellung das schön simple DebugWire günstig zu nutzen,
trotz AVR Dragon, immernoch reizvoll:
Ein DIY Debugger, der wirklich zum günstigen Preis der kleinen Atmel und
ATtinys passt, und damit auch zu wirklich günstigen uC
Einsteiger-Projekten wie arduino.cc (ab 20 euro pro board).

>> Ich hatte leider den Eindruck, dass den beiden Herren alles andere als
>> bewusst war, dass die Bastler von Heute u.U. durchaus die 100k
>> Bestellungen von Morgen mitbestimmen...
>
> Ja, und?  Bei den 100k-Bestellungen kauft dein Chef die 10 JTAG ICEs
> aus der Portokasse.

Genau und ich zahl jetzt und auch in Zukunft eben nicht 10 JTAG ICEs aus
der Portokasse für den privaten Einsatz.

> Allein die Gefahr, dass er auf Grund des fehlenden Gehäuses irgendwo
> einen Kurzschluss verursacht, sollte gut die paar Hunderter für ein
> richtiges ICE ausmachen, nimm noch dazu die Zeit, die man mit dem Basteln
> der Kabel verbringen darf -- eine Ingenieursstunde kostet ab EUR 50
> aufwärts.

Klar, da stimme ich dir gern zu! Aber für die DIY Leute könnte man doch
wenigstens sie Schnittstellen offenlegen. Gerade wenn man (Atmel)
annsonsten doch so schön durch AVR-GCC etc. freie Tools unterstützt.
Naja, wenn mir mal ganz arg langweilig ist, werde ich dem DebugWire im
Oszi zuschauen.

Oliver Keller wrote:

> Ich finde die Vorstellung das schön simple DebugWire günstig zu nutzen,
> trotz AVR Dragon, ...

> Ein DIY Debugger, der wirklich zum günstigen Preis der kleinen Atmel und
> ATtinys passt, ...

Ich zweifle, dass du das wirklich in irgendeiner Weise nennenswert
günstiger als mit dem Dragon hinbekommst.  Ich habe ungefähr eine
Vorstellung, was debugWIRE intern macht, das ist weit mehr an
Protokoll, als man je hätte in der simplen Mimik des alten JTAG
ICEs hinbekommen hätte.

> Klar, da stimme ich dir gern zu! Aber für die DIY Leute könnte man doch
> wenigstens sie Schnittstellen offenlegen. Gerade wenn man (Atmel)
> annsonsten doch so schön durch AVR-GCC etc. freie Tools unterstützt.

Das war doch auch ein langer Weg, bis sie gemerkt haben, wie viel ihnen
das an Reputation und damit letztlich auch Akzeptanz (und schließlich
Umsatz) bringt.

Jörg Wunsch wrote:
> Ich habe ungefähr eine Vorstellung, was debugWIRE intern macht

Könntest du das mal grob beschreiben (falls du das darfst), bzw. weißt
du zufällig für was der Dragon den ganzen SRAM braucht ?

Stimmt. Also kann Atmel zwar bis 3 zählen, aber im Dreistelligen haben
sie Schwierigkeiten. Denn das Family-Manual zu "A" Serie sagt 135, die
Datasheets 139.

ATXMEGA wrote:
> Xmega
> Xgiga
> Xtera
>
> :)
Ne, dann hätte die jetzt neuen schon ATgiga heißen müssen. Dann wohl
eher XXmega, XXLmega. :)

Aber mal im ernst, wenn Atmel für einen angenommenen Nachfolger wieder
die Taktzahl verdoppelt, könnten die dann 64 und 128 MHz...

Die Zukunft wird es zeigen. Wenn die XMEGAs am Markt erhältlich sind,
wird in ATMELs Küche sicher schon der nächste Turboproz gebastelt ;-)
32-Bit DSP mit AVR-Steuercontroller in einem Chip wäre doch geil :-))

Benedikt K. wrote:
> Jörg Wunsch wrote:
>> Ich habe ungefähr eine Vorstellung, was debugWIRE intern macht
>
> Könntest du das mal grob beschreiben (falls du das darfst), bzw. weißt
> du zufällig für was der Dragon den ganzen SRAM braucht ?

Ein paar Details würden mich jetzt auch bernnend interessieren...

Benedikt K. wrote:

>> Ich habe ungefähr eine Vorstellung, was debugWIRE intern macht

> Könntest du das mal grob beschreiben (falls du das darfst), bzw. weißt
> du zufällig für was der Dragon den ganzen SRAM braucht ?

Jens wrote:

> Darf ich mal etwas provokant fragen woher Deine Vorstellung
> bezüglich DebugWire stammt?

Nun, ich habe die Behandlung des JTAG ICE mkII (und damit auch des AVR
Dragon) zuerst in AVRDUDE und dann in AVaRICE eingebaut, zuerst JTAG
und später auch debugWIRE.  Dabei ist die Appnote AVR067 so wenig
aussagekräftig, dass das nicht ging, ohne auch den Support von Atmel
gelegentlich zu nerven.  Außerdem muss man auch für die Benutzung
wenigstens so einigermaßen die ,,Denkweise'' des ICE verstanden haben,
sonst kommt man da nicht weit.

Wie viel von der eigentlichen Arbeit bei debugWIRE dabei im ICE und
was im Zielprozessor realisiert ist, weiß ich detailliert natürlich
auch nicht, aber es würde mich absolut nicht wundern, wenn man (zur
Kostenersparnis) im Zielprozessor praktisch nichts außer der
Kommunikationsebene implementiert hätte.  Das heißt dann, dass viele
der Debug-Aktionen einzeln als CPU-Befehle in den Befehlsdekoder
injiziert und dort abgearbeitet werden.

Für den dicken RAM habe ich zwei Ideen (wahrscheinlich treffen beide
irgendwie zu).  Erstens benutzt AVR Studio eine Art "tag memory" im
ICE, mit der sich das ICE die Grenzen der Zeilennummern der
Hochsprache merkt.  Wenn man dann im AVR Studio eine Zeile in der
Hochsprache abarbeiten will, dann wird dies direkt an das ICE
weitergegeben, das so lange Befehle ausführen lässt, bis im tag memory
eine Adresse erreicht ist, die zu einer neuen Zeilennummer gehört.
Dieses tag memory gab's zwar auch schon beim alten JTAG ICE (dort
intern im ATmega16), aber da das mkII ja von vornherein für größere
CPUs (einschließlich AVR32 und Xmega) taugen sollte, braucht man da
natürlich entsprechend mehr.

Der zweite Grund dürfte sein, dass sich das ICE ja für jeden software
breakpoint die komplette originale Flash-ROM-Seite merken muss, damit
beim Erreichen des BREAKs dann diese Seite wieder in den Zielprozessor
zurück geschrieben werden kann.  Wenn man also eine hinreichend große
Anzahl an software BPs unterstützen können will (essenziell für
debugWIRE, das ja keine hardware BPs kennt wie JTAG), dann muss man
dafür ausreichend RAM vorhalten.

Travel Rec. wrote:
> Die Zukunft wird es zeigen. Wenn die XMEGAs am Markt erhältlich sind,
> wird in ATMELs Küche sicher schon der nächste Turboproz gebastelt ;-)
> 32-Bit DSP mit AVR-Steuercontroller in einem Chip wäre doch geil :-))
Soetwas ähnliches hat Atmel doch schon lange mit einem FPGA im Angebot.
http://www.atmel.com/dyn/products/devices.asp?family_id=627
Schade nur, das die Programmiertools kostenlos zu sein scheinen.

mr.chip wrote:

> Gerade als Hobbybastler ist man aber immer auf der Suche nach neuen
> Herausforderungen und leistungsfähigeren Controllern.

Geht mir durchaus auch so, allerdings gilt mein Interesse eher den
Architekturen, ich muss nicht unbedingt jedes Teil in die Finger nehmen
und irgendwo einlöten. Vor allem wenns nicht wirklich neuartig ist - was
bitte ist an ATxmega neu wenn man andere Architekturen kennt und nicht
nur die alten AVRs? In mancher Hinsicht sind sie praktischer als die
alten, aber das wars auch schon.

Ich in den AVRs eher den Ansatz für kleinere als für grössere Probleme
und keine Konkurrenz zu 32bit Architekturen. Entsprechend skeptisch bin
daher bei der 24bit Adressierung. Kann man machen, aber muss man das
unbedingt mit einem 8bitter machen?

Und was mich besondern enttäuscht hat: nach wie vor kein ROM im
Datenadressraum, d.h. die Unterscheidung zwischen Zeigern auf variable
Daten und solchen auf konstente Daten (Strings) bleibt erhalten. Bei
kleinen Programmen stört mich das nicht, bei grossen hingegen sehr.

> Eine Sache verstehe ich nicht ganz: Warum wechselt man nicht auf eine
> 16- oder gar 32-Bit Architektur?

Weil man die schon hat. 32bit jedenfalls. 16bit lohnt heute eher nicht
mehr, denn der mangelnden Adressierfähigkeit wird damit nicht wirklich
abgeholfen.

Andreas Kaiser wrote:

> Und was mich besondern enttäuscht hat: nach wie vor kein ROM im
> Datenadressraum

Es sollte wohl Harvard bleiben, weil das die Parallelisierung der
Buszugriffe erlaubt.  Und naja, willst du wirklich für die
Einsparung eines Takts unbedingt den ROM zur Hälfte vorbestimmt
in Daten und Befehle getrennt haben?

Das geht auch mit Harvard. Ausgerechnet Microchip macht es vor, eine
Firma die ja, was Rechnerarchitekturen angeht, nicht wirklich für
Geistesblitze bekannt ist. Aber bei PIC30 habe sie mal was richtig
gemacht: In der zweiten Hälfte des 64KB Datenadressraums ist ein Teil
vom Code-Flash eingeblendet.

Das dies hinsichtlich des internen Ablaufs nicht ganz trivial ist, ist
mir klar. Aber der Vorteil bei der Programmierung ist in meinen Augen
sehr wesentlich.

Mir wäre es lieber, es würde sich mal jemand aufraffen, dem GCC
Speichersegmente zu lehren...  Es gibt dafür einen Standardisierungs-
vorschlag im Rahmen eines "Embedded C"-Projekts.

Andreas Kaiser wrote:
> Das geht auch mit Harvard. Ausgerechnet Microchip macht es vor, eine
> Firma die ja, was Rechnerarchitekturen angeht, nicht wirklich für
> Geistesblitze bekannt ist. Aber bei PIC30 habe sie mal was richtig
> gemacht: In der zweiten Hälfte des 64KB Datenadressraums ist ein Teil
> vom Code-Flash eingeblendet.

Die habe auch kein externes Speicherinterface wie die AVRs. Daher hat
der AVR  für solche Spielchen garkeinen Platz.

> Das dies hinsichtlich des internen Ablaufs nicht ganz trivial ist, ist
> mir klar. Aber der Vorteil bei der Programmierung ist in meinen Augen
> sehr wesentlich.

Naja, es mindestens genau einen Krampf das passende Segment
einzublenden, vor allem: Was machst du wenn du eine Tabelle hast, die
größer ist als 32kByte ? Auf einem AVR kein Problem, aber bei einem
dsPIC ?

Das wäre zweifellos ein Fortschritt, erspart mir aber nicht nicht
entsprechende Attributierung der Pointer. Was bei eigenen auf dieser
Plattform entstandenen Programmen noch erträglich ist. Aber bei
Fremdprogrammen, wie beispielsweise TCP/IP-Stack oder Flash-Filesystem,
entsteht erheblicher Aufwand, wenn deren Autoren eher in der von-Neumann
Welt leben.

Bei uIP hatte ich deshalb einen eigenen Wrapper für "universal pointer"
implementiert. Sowas liesse sich in GCC auch innerhalb der
AVR-Adaptierung realisieren, auf Kosten von Laufzeitfunktionen für alle
indirekten Zugriffe.

Benedikt K. wrote:

> Die habe auch kein externes Speicherinterface wie die AVRs. Daher hat
> der AVR  für solche Spielchen garkeinen Platz.

Wer externen Speicher anbindet, hat das Problem meist nicht, da darin
wird sich noch oft ein Plätzchen für konstante Daten finden. Das
Daten-ROM liesse sich dann ausblenden.

> Naja, es mindestens genau einen Krampf das passende Segment
> einzublenden, vor allem: Was machst du wenn du eine Tabelle hast, die
> größer ist als 32kByte ?

(E)LPM will ich ja nicht verbieten. Mir geht es nicht um Monsterdaten,
sondern um die ganz alltäglichen Strings, Menutabellen usw. Für
spezielle Monster ist spezieller Code kein Problem.

Benedikt K. wrote:

> Naja, es mindestens genau einen Krampf das passende Segment
> einzublenden

Wobei Microchip das entsprechende Paging im Compiler erst neuerdings
macht, anfangs waren es  m.W. dort nur 32KB fix. Mir würden diese 32KB
reichen, für Code im dreistelligen KB-Bereich ziehe ich ohnehin andere
Lösungen vor.

Ralf LK wrote:

> Wirklich schade ist das Fehlen einer PLCC68 Variante,

Diese Gehäuse sind anscheinend noch exotischer als DIP, der Verbreitung
nach zu schliessen. Wenn man sich so umschaut, sind PLCCs fast nur dort
zu finden, wo pinkompatible Chips ihre Vorgänger von vor 20 Jahren
ersetzen, beispielsweise bei den 8051-Derivaten.

NXP hat vor ein paar Jahren den LPC2103 in PLCC44 angekündigt, schiebt
das aber seither immer brav vor sich her - dabei wäre das mal eine
schöne Mega32-Konkurrenz.

Mich hat an den jetzt verfügbaren Daten zum XMega verwundert, dass die
TQFP Gehäuse immer noch mit 0,8 mm Pitch kommen.
Das hätte bei den kleineren DIE's auch ruhig kleiner werden können.

Dann ist das ja nur der Anfang, die Familie ist ja nicht einmal komplett
vorgestellt - es fehlen zum Beispiel A2 und A5.
Wobei - sehr clever die dicksten Typen mit A1 zu benennen.

Und dann habe ich mich auf der Embedded am Stand eines Distributors über
die XMega's unterhalten, die ersten aus der Volumen-Produktion werden
wohl vielleicht sogar schon im März verfügbar werden.


Die neuen CAN/LIN AVR's finde ich fast schon interessanter als die
XMega's.
Bloss das man an die "Automotive" Teile in kleinen Stückzahlen quasi
nicht rankommt.

Und die AVR32 UC3B sollen zumindest als Muster zu bekommen sein.

Rudolph R. wrote:

> Mich hat an den jetzt verfügbaren Daten zum XMega verwundert, dass die
> TQFP Gehäuse immer noch mit 0,8 mm Pitch kommen.

Ist halt ein Standardgehäuse.  Wer klein bauen will, wird doch ohnehin
auf QFN/BGA gehen, die QFPs sind doch eher für Prototypen (und Bastler)
bzw. Dinge wie den STK600 gedacht.

0,5-mm-Raster in ZIF-Fassungen ist grässlich.  Die Dinger haben eine
beständige Neigung, dass die Pins genau zwischen die Kontaktfedern
rutschen.

Die A2 sind bei Spoerle gelistet (da sind die Dinger ja schon vor
Monaten aufgetaucht). Sollen 80 Pins haben.

Jörg Wunsch wrote:
> Ist halt ein Standardgehäuse.

Ja, und gibt es eben auch mit kleinerem Pitch, die AVR32 z.B. haben 0,5
mm.
Und deren DICE sind wahrscheinlich nicht kleiner als die der XMega.

> Wer klein bauen will, wird doch ohnehin
> auf QFN/BGA gehen, die QFPs sind doch eher für Prototypen (und Bastler)
> bzw. Dinge wie den STK600 gedacht.

Bei wenig Pins scheinen QFN und BGA nicht so geschickt zu sein.
Denn die machen das Layout komplexer, erfordern schnell vier Lagen und
mehr.

Die Masse-Fläche unter dem QFN bewirkt doch auch, dass man quasi nicht
mehr nach innen routen kann. Den Vorteil des kleineren Chip verschenkt
man also je nach Layout durch eine grössere Freifläche um diesen.

>> Was aber völlig verwirrt sind die vielen UART - Units (7 bzw. 8).

Nicht so unlogisch die vielen UARTs. Diese können auch im Master-SPI
Modus betrieben werden. Im Zuammenhang mit schnellem DMA Transfer macht
ein SPI Modul mit mehreren Peripherie keinen Sinn. Man benötigt dann
wirklich separate SPI Module. Zb. MMC/SD Karte und SPI-ADC/DACs können
quasi parallel Daten transferieren, und das dann in großen Mengen über
DMA. Ein einzigstes SPI-Modul müsste dann mit ChipSelects arbeiten und
kann immer nur eines der externen Devices zu einem Zeitpunkt ansteuern.

Was unverständilcher ist ist der Punkt warum überhaupt noch das
veraltete SPI Modul integriert wurde statt die USART-SPI-Module soweit
aufzubohren das sie auch im Slavemodus betrieben werden können.
Besonders weil die USART-SPI-Module eigentlich effizienter sind, sprich
Baudrateerzeugung, Doublebuffering der Rx/Tx Register, differenziertes
Interrupthandling etc.pp.

Eigentlich finde ich alle Verbesserung an fast jedem Modul der XMegas
interessant und schon längst überfällig.

2x ADC-Module die alle ADC Channel des MUX im Sweep-Modus schnell
sampeln können. Hat man zb. 8 Kanäle im ADC0 aktiviert und sampelt im
Sweep Modus, dann benötigt der ADC insgesamt 10+8+2 ADC-Takte um alle 8
Kanäle am MUX zu sampeln. Dh. der Sweepmodus sampelt alle aktiven ADC
Kanäle interleaved und nicht wie bisher sequientiell einen nach dem
anderen. Natürlich nicht zu vergessen die 2 Msps, die Gains usw.

Dann der DAC der auch als Input intern an den AC geroutet werden kann.
Ein einstellbarer Window-Comparator ist mit den 2 AC dann ohne Probleme
möglich, ohne externes Routing etc.pp.

Die Timer, alle haben jetzt von Hause aus einen variables TOP Register
und damit ist die Einstellung der Frequenz der Counter uniform gelösst.
Also nicht so wie bisher über Umwege über OCRxx Register die dann nicht
mehr als Comparematch Register benutzbar sind. Zudem kann man sie 2x
oder 4x mal schneller takten als den CPU Kern, wenn ich das richtig
verstanden habe. Geht über die PLL und der nachgeschalteten
Teilerkaskade.

Interessant sind auch die Input Capture Eigenschaften der Counter. Eine
Messung von zb. 16 Takten eines Signales inklusive Dutycycle und
Frequenz pro Takt ist jetzt vollautomatisch möglich, echt Klasse. Man
konfiguriert einen Counter im Input Capture Modus, er misst beide
Flanken des Signales, und speichert per DMA die gemessenen Werte gleich
in einen vorkonfigurierten SRAM Buffer. Signalsampling made easy ;) Zb.
für IR-Fernbedienungen wird das damit schon lächerlich einfach gemacht.
Naja, und endlich mal ausreichend viele Timer was den Softwaredruck
reduziert, man muß nicht mehr so geizen und alles in einen Timer
reinpfropfen und sich so Timingprobleme einhandeln. Über das Eventsystem
stehen so auch 32 bit breite Timer zur Verfügung.

Und das Eventsystem ist gut überlegt. Im Zusammenhang mit dem Timern,
deren PWM Modis und den Komparatoren könnte ich mir gut vorstellen das
man damit einen Synchronmoter fast ohne Softwareeingriff und ISRs
programnmmieren kann. Einfach über das Eventsystem verknüpfen.

Die Idee mit den virtuellen Ports finde ich als guten Kompromiss. Bisher
musste man immer abwägen welche Ports/Pins noch in den Registerbereich
gelegt werden bei denen man mit einfachen Opcodes drauf zugreifen kann.
Das führte bei Vielpinnern dazu das alle Ports in diesem Registerbereich
lagen und somit diesen wertvollen Bereich verbrauchten. Mit dem nun
virtuellen Mapping entscheidet der Programmierer welche der Ports er in
den virtuellen Bereich auslagern möchte. Dann kann er über diese
virtuellen Registerbeich mit den Single-Opcodes die Bits schnell
togglen, auslesen, setzen, löschen usw. das macht man natürlich nur mit
denjenigen Ports bei denen man schnell Bits verändern möchte, also ohne
RMW-Feature-Umweg in atomarer Weise.

Auch das Mapping des EEPROMs in den SRAM finde ich überlegt. Das
vereinfacht den Zugriff auf den EEPROM erheblich.

Bleibt nur zu hoffen das alle Versprechungen auch in Hardware
reibungsfrei laufen und es nicht erst Jahre dauert bis alle Fehlerchen
beseitigt sind.
Eventuell könnte die Anzahl der DMA Kanäle ein bischen wenig sein.

Alles in allem ist zwar der Core noch ein 8Bit AVR aber der Rest ist für
mich ein echter Fortschritt und das betrifft jedes Peripheriemodul.

Gruß Hagen

Irgendwo hatte ich vor kurzem eine Übersicht gesehen, bei der der
hauptsächliche Unterschied zwischen den Klassen A1 bis A5 aufgelistet
ist. Hat da zufällig jemand die Adresse auch noch gefunden?

Wolfgang

Wie ich sehe ist das TWI-Modul in den XMega auch nicht besser geworden,
schade auch.
Wäre nett, wenn das Teil im Slave-Modus wenigstens Auto-ACK machen
würde.

Die mit dieser Unit notwendige Interrupt-Funktion finde ich deutlich zu
komplex, das sieht mir nach erheblich zu viel Software-Overhead aus.

Was ich bis jetzt in Sachen TWI rausgelesen habe,
hat sich aber was geändert,
es gibt den Smart-Mode, bei dem man mit dem Lesen des Datenregisters
auch gleich ein (N)ACK senden kann, als Master oder Slave. Ob's ein ACK
oder NACK wird muss man aber immer noch vorher angeben.

Man muss kein TWINT wie bei den aktuellen AVRs per Software setzen, das
Schreiben ins Datenregister sendet gleich los und wertet (N)ACK aus.

Nur DMA-Anbindung gibts keine, im Vergleich zu USART oder SPI, das wärs
noch gewesen ;-)

Ich habe das TWI bisher nicht als Schwachstelle der Megas gesehen. Ob
man den Status nun durchs Lesen vom Register weiterschaltet oder
explizit, das halte ich nicht wirklich für wichtig, nicht bei den dabei
üblichen Bitraten.

Wichtiger wäre es, mal ein SPI mit brauchbarer Slave-Funktion zu
bringen. Wie Atmel sich das bei einem ungepufferten Datenregister
vorstellt ist mir nämlich bislang nicht klar geworden.

Also ich frage mich schon ein wenig, wozu das ganze. Die Teile sind von
den Spezifikationen her den ARMs sehr ähnlich. Anscheinend haben die im
Prinzip die selben Anwender im Visier.

Etwas wirklich 'revolutionäres' wie beispielsweise richtig viel RAM
findet man da ja auch nicht. Bei 16 kiByte ist Schluss.

Als Nachfolger der ATMega Controller wird das irgendwie nicht
überzeugend, zumal DIP-Gehäuse noch fehlen. In vielen Anwendungen ist
man froh darüber, wenn man ein Sofwareupdate einfach durch Wechseln des
Chips durchführen kann. Das können auch noch viele Kunden selbst machen.
Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur
wenige Rechner serienmäsig.

Christian Berger wrote:
> Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur
> wenige Rechner serienmäsig.

Dafür gibt es Booloader/self-Programming.

Andreas Schwarz wrote:
> Christian Berger wrote:
>> Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur
>> wenige Rechner serienmäsig.
>
> Dafür gibt es Booloader/self-Programming.

Theoretisch ja, aber selbst dann musst Du noch eine Datenverbindung vom
Programmierrechner zum Gerät aufbauen. Es ist viel einfacher einfach
einem Kunden einen DIP-Chip zuzuschicken und ihm zu sagen, dass er den
einfach auswechseln soll. So werden schon seit Jahren Softwareupdates
auf Telefonanlagen gemacht. Der große Vorteil ist auch, dass es ein
Prozess ist, den der Kunde komplett versteht. Das schafft Vertrauen.
Falls die neue Softwareversion nicht funktioniert, so steckt er halt den
alten Chip ein.

Christian Berger wrote:
> Andreas Schwarz wrote:
>> Christian Berger wrote:
>>> Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur
>>> wenige Rechner serienmäsig.
>>
>> Dafür gibt es Booloader/self-Programming.
>
> Theoretisch ja, aber selbst dann musst Du noch eine Datenverbindung vom
> Programmierrechner zum Gerät aufbauen. Es ist viel einfacher einfach
> einem Kunden einen DIP-Chip zuzuschicken und ihm zu sagen, dass er den
> einfach auswechseln soll. So werden schon seit Jahren Softwareupdates

Und dann verkehrt herum einbaut.

> auf Telefonanlagen gemacht. Der große Vorteil ist auch, dass es ein
> Prozess ist, den der Kunde komplett versteht. Das schafft Vertrauen.
> Falls die neue Softwareversion nicht funktioniert, so steckt er halt den
> alten Chip ein.

Ist bestimmt eine Lösung, doch da heute eh schon alles vernetzt ist,
halte ich einen Bootloader durchaus für eine gute Variante.

Philipp Burch wrote:

> Und dann verkehrt herum einbaut.

Es gibt auch Kunden, die nicht ganz blöd sind. Nebenbei kannst Du
denen dann ja sogar einen neuen Chip verkaufen


> Ist bestimmt eine Lösung, doch da heute eh schon alles vernetzt ist,
> halte ich einen Bootloader durchaus für eine gute Variante.

Oh ja, darauf freue ich mich schon, wenn ich mich mal die Firmware von
Türklingeln per Internet austauschen kann. :)

Dietmar E wrote:
> [...] wenn der Kunde ein USB-Kabel ansteckt.

An welchen Pins der XMEGAs befinden sich gleich noch die USB-Signale?
;)

>>Dinge wie LCD-Ansteuerung, I2C, AC97, SD-Interface, USB oder Ethernet
>>sind natürlich auch Wünsche für 8 Bit.
>>Im Minimum hätte ich aber USB erwartet.

Das könnte noch kommen. Ich bin nämlich stutzig geworden. Es gibt den
CPU_Clock=Peripherie_Clock. Diese werden durch 2 einstellbare Vorteiler
gefüttert. Diese Vorteiler erzeugen zwei zusätzliche Clocks für
Peripherie die 2x oder 4x schneller als die ALU getaktet werden können
und das synchron zur ALU. Schön dachte ich, suchste doch mal diejenige
Peripherie raus die mit diesen Takten arbeiten kann. Es gibt sie nicht.
Ich habe kein einzigstes Modul gefunden das mit diesen beiden Takten
arbeiten kann. Das legt den Verdacht nahe das diese beiden Taktquellen
für zukünftige Erweiterungen vorgesehen sind die dann 2x oder 4x
schneller getaktet werden können als die max. möglichen 32Mhz der
Standardperipherie/ALU. Ich hatte nämlich gehofft das man zb. die
Timer/Counter mit diesen beiden höheren Takten antreiben kann, is aber
nich.

Auch gibt es so einige Verweise auf AppNotes die nicht vorhanden sind.
Die Funktionsweise des Erweitereten Waveform Modules, der
High-Resolution-Modules und des EIBs sind defakto undokumentiert.

Gruß Hagen

>>Die Ergänzungen wie 'virtual port' läßt (letzte) Schwächen entfallen

Du meinst "auffallen" oder ?

Ich finde die 4 virtuallen Ports im Addressbereich 0x0010 bis 0x0020
garnicht als so schlechten Kompromis. Das Design der AVR-8Bitter ist nun
mal so wie es ist und Atmel stand vor dem Problem wie man mehr als 4
Ports pro Chip denoch so ansteuern kann das sie ohne RMW schnell
manipuliert werden können. Wenn man zb. Ports A,B,C,D,E,F hat dann wird
es in den seltensten Fälle vorkommen das man an all diesen Ports zum
gleichen Zeitpunkt mal schnell Bits wackeln möchte. Also legt man sich
die Ports als Resource so auf diese 4 virtuellen Ports wie man es
benötigt um schnell die entsprechenden Pins ansprechen zu können, das
ginge ja sogar dynamisch zur Laufzeit zu konfigurieren.

Durch diese "Beschränkung" bekommt man dem User-Register-Bereich
geschenkt, Addresse 0x0000 bis 0x000F in dem man eigene Daten ablegen
kann, zb. eben Bitfields die man dann mit schnellen atomaren Opcodes
manipulieren kann.

Auch die zwei zusätzlichen FLASH Pages mit den Kalibrierungswerten,
Chip-IDs und eigenen Daten finde ich gut. Per SPI und Anwendungssoftware
programmierbar.

Gruß Hagen

Christian Berger wrote:

> So werden schon seit Jahren Softwareupdates
> auf Telefonanlagen gemacht.

Du übertreibst.  Meine alte Euracom hat zwar noch gesteckte ROMs (für
die ich leider nichmal mehr Images bekomme beim Lieferanten, ich darf
ihn noch für die ROMs mit löhnen, wenn ich einen Update haben will),
aber bereits das Nachfolgemodell hatte Flash-ROMs.

Wenn du schon unbedingt die Firmware physisch und zum Kunde-stöpselt-
selbst haben willst, dann währe wohl sowas wie eine SD-Karte
einigermaßen zeitgemäß.  Selbst die ist deutlich kleiner als ein
DIP-40.

Dietmar E wrote:
>> Es ist viel einfacher einfach einem Kunden einen DIP-Chip zuzuschicken
>
> Wieso Einfacher? Es ist im Gegenteil viel einfacher für alle Seiten,
> wenn der Kunde ein USB-Kabel ansteckt. Wer schickt denn heute noch ICs.
> Der Aufwand ist viel zu hoch: Bestellungen annehmen, IC kaufen,
> programmieren, Rechnungen schreiben, versenden, Garantie übernehmen. Und
> der Kunde muss lange warten, das Gerät öffnen (damit kann man es nicht
> versiegeln), bricht vieleicht noch ein Beinchen ab. Nö.

OK, dann muss der also irgendwoher einen passenden funktionierenden
Rechner finden. Dann muss der Kunde auch noch irgendwie das Programm zum
Laufen bekommen. Und zu guter letzt muss er noch so nahe an das Gerät
mit seinem Rechner herankommen, dass das USB-Kabel reicht.

Rechnung musst Du sowieso schreiben und verschicken. Und die
Wahrscheinlichkeit, dass der Kunde beim Auswechseln einen
unkorrigierbaren Fehler macht ist geringer als bei irgendwelchen
Software-updates per USB.

Hagen Re wrote:
> Ich hatte nämlich gehofft das man zb. die
> Timer/Counter mit diesen beiden höheren Takten antreiben kann, is aber
> nich.

Genau das soll möglich sein. Wurde mir auf der Embedded gesagt und wurde
auch so vorgeführt.

Leider erkenne ich das aus den Datenblättern nicht so. Dort wird Clk_Per
vom Timer benutzt und der ist identisch zum Clk_MCU.
Der Prescaler der Timer kann nicht auf Clk_Per2x oder Clk_Per4x
eingestellt werden.

Es sei denn die Datenblätter verraten noch nicht alles.

Geil wäre es, denn den ICP oder PWM mit 128Mhz laufen zu lassen wäre
nicht schlecht.

Gruß hagen

Zu der PLL würde ich sagen -> siehe Tiny45.

Benedikt K. wrote:
> Hagen Re wrote:
>> Ich hatte nämlich gehofft das man zb. die
>> Timer/Counter mit diesen beiden höheren Takten antreiben kann, is aber
>> nich.
>
> Genau das soll möglich sein. Wurde mir auf der Embedded gesagt und wurde
> auch so vorgeführt.

Haben sich die Leutz darüber ausgelassen, bei wieviel MHz da dann Schluß
ist?

Hagen Re wrote:
> Es sei denn die Datenblätter verraten noch nicht alles.
Die Datenblätter verraten noch so einiges nicht, z.B. Stromverbräuche,
Anschlußeigenschaften, Stabilität und Toleranzen von ADC/DAC etc.

Gruß
Jadeclaw.

Jadeclaw Dinosaur wrote:

> Haben sich die Leutz darüber ausgelassen, bei wieviel MHz da dann Schluß
> ist?

32MHz CPU Takt, 128MHz Peripherie. Wie hoch man die übertakten kann,
keine Ahnung.

Hagen Re wrote:
>>>Dinge wie LCD-Ansteuerung, I2C, AC97, SD-Interface, USB oder Ethernet
>>>sind natürlich auch Wünsche für 8 Bit.
>>>Im Minimum hätte ich aber USB erwartet.
>
> Das könnte noch kommen. Ich bin nämlich stutzig geworden. Es gibt den
> CPU_Clock=Peripherie_Clock. Diese werden durch 2 einstellbare Vorteiler
> gefüttert. Diese Vorteiler erzeugen zwei zusätzliche Clocks für
> Peripherie die 2x oder 4x schneller als die ALU getaktet werden können
> und das synchron zur ALU.
>

Bis jetzt hat der USB auf den ATmegas aber eher nur alleine einen
Nutzen. Da die PLL nur einige wenige ganzahlige Vielfache aus der
BasisClock, also dem Quarz, machen kann, kann man sich aussuchen, ob man
USB oder UART haben muss. Es gibt keine Einstellung in der man den UART
mit 0% Toleranz betreiben kann und den USB ebenfalls verwenden kann.

Ich hoffe daher schwer, dass ATMEL in die X-Serie auch einen internen
Oszillator einbaut, der dann per PLL für den USB genutzt werden kann und
es erlaubt einen UART durch ein externes Quarz mit gerader Baudrate zu
betreiben. Oder aber sie bohren den 32kHz Oszillator so auf, dass man
mit seinem Clock auch andere Peripherie betreiben kann. Dann kann man
dort das passende Quarz für die UARTs anschließen.

Naja, warum eigentlich, am PC gibt es den UART eh nicht mehr, also warum
soll die Peripherie ihn behalten... War eine Schnittstelle, von der wir
uns nun nach 20? 30? 50? Jahren verabschieden müssen. Ist einfach zu
genormt, definiert, einfach, ausgereift, unverschlüsselt, von jedem zu
leicht implementierbar....

Gruß, Ulrich

Jadeclaw Dinosaur wrote:
> Hagen Re wrote:
>> Es sei denn die Datenblätter verraten noch nicht alles.
> Die Datenblätter verraten noch so einiges nicht, z.B. Stromverbräuche,
> Anschlußeigenschaften, Stabilität und Toleranzen von ADC/DAC etc.
>
Auch die genauen Prozessorbefehle finde ich noch nirgends. Ich wüsste
gerne was es mit der Aussage einer 8/16 Bit CPU auf sich hat. Die ATMEGA
hatten ja schon MOVW, ADIW und SBIW. Die Sache mit dem tmp Register
scheint jedenfalls beibehalten worden zu sein. Wäre schön gewesen wenn
es hier die Möglichkeit gegeben hätte die 16 Bit I/O Register in einem
Schritt in die Register kopieren zu können (ohne das man Beinflussungen
durch Interrupts beachten muss).

das Thema ist doch geklärt. Es ist ein ATmega, 8Bit. Die 16 Bit sind
quasi Werbung mit dem Hintergrund das man über den EBI ja bis zu 16Mb an
Speicher dranhängen kann. Die 16Bit haben nichts mit der MCU zu tun
allerhöchstens mit dem externen Speicherinterface und eventuell mit der
Breite der Timer etc.pp.

Die Aussage ist auch klar ersichtlich -> XMega kann 1 zu 1 bestehende
ATMega Projekte übernehmen mit den gewohnten Compilern.

Gruß Hagen

>>Ich hoffe daher schwer, dass ATMEL in die X-Serie auch einen internen
>>Oszillator einbaut, der dann per PLL für den USB genutzt werden kann und

schätze das du da lange warten kannst. Deine Forderung ist eine
Forderung nach zwei komplett getrennten und nicht synchronen
Taktdomains, das wird meiner Meinung garantiert nicht kommen, da dies
für einen 8 Bitter einfach zu viel Logik zur Synchronisation mit der ALU
benötigt. Wenn dann wird es so aussehen das der XMega mit USB
ausgestattet wird. Dieses USB wird dann über einen der drei Takte
(synchron zueinander) Clk_Per, Clk_Per2 oder Clk_Per4 erfolgen. Dabei
muß dann der Controller mit einem externen Takt laufen der exakt die
geforderten 48Mhz für den USB einhält. Also zb. 12Mhz Quartz, PLL auf x4
und davon abgeleitet ein MCU Takt mit Teiler 1,2,4,8,16.

Wie gesagt, der PLL Takt kann durch zwei einstellbare Teiler auf 3
verschiedene zueinander synchrone Takte runtergeteilt werden. Da ich in
den datenblättern bisher kein einzigstes Peripheriemodul gefunden habe
das die beiden höheren Takte benutzt, diese Takte also ungenutzt
scheinen, ist die Wahrscheinlichkeit hoch das man sie für spätere
Erweiterungen vorgesehen hat. Vorausgesetzt die Datenblätter enthalten
das was man später im Silizium verkauft.

Gruß Hagen

>> Werde nächste Woche mal die ersten Tests mit einem STK600 machen können.
>> Mal sehen, was die Controller so alles drauf haben.

zwei Fragen:
Wo hast du das STK600 her und wo die Controller? Kann man die Controller
schon sampeln?

Haben die XMEGAS nicht einen fractional baud rate generator, womit der
hickhack mit den baudratenquarzen eh ein ende hat?

Ich empfehle mal, sich das XMega-Manual zu ziehen:
http://www.atmel.com/dyn/resources/prod_documents/...
und mal in die USART-Sektion ab Seite 223 zu schauen.
Dort ist das mit dem fractional baud rate generator erklärt.
Inklusive Formelsatz auf Seite 226.

Kurzerklärung für die, die kein Englisch können:
Der fractional baud rate generator funktioniert dergestalt,
daß einzelne Takte zusätzlich eingefügt werden,
um den Abtastpunkt wieder auf Bitmitte zu bringen.
Nach außen hin sieht es so aus, als ob da ein
Jitter auf dem Takt drauf ist, dies ist jedoch vertretbarer
als ein höherer konstanter Fehler.
Ganz ohne Baudratenquarz kommt man allerdings auch hier nicht aus,
da bei sehr hohen Baudraten der Teilerfaktor nicht beliebig
verkleinerbar ist. Im normalen Bereich (< 40kBaud)
sieht es aber anders aus, da sollte jetzt alles gehen,
was man in der Bastelkiste findet.

Gruß
Jadeclaw.

So ein Glück, dass es FT232RL gibt.

Ulrich P. wrote:
> Bis jetzt hat der USB auf den ATmegas aber eher nur alleine einen
> Nutzen. Da die PLL nur einige wenige ganzahlige Vielfache aus der
> BasisClock, also dem Quarz, machen kann, kann man sich aussuchen, ob man
> USB oder UART haben muss. Es gibt keine Einstellung in der man den UART
> mit 0% Toleranz betreiben kann und den USB ebenfalls verwenden kann.

Ich lese im PDF ewas von "High Resolution Baud Rate Generator", also
eventuell wird man jetzt auch ohne Baudratenquarz was reißen können.

> Als Nachfolger der ATMega Controller wird das irgendwie nicht
> überzeugend, zumal DIP-Gehäuse noch fehlen.

DIP-Gehäuse sind heutzutage absolut irrelevant. Zu groß, zu teuer, dazu
u.U. noch Probleme aufgrund der Induktivität der Anschlüsse (z.B. Ground
Bounce).
Mich wundert eher, das Atmel, im Gegensatz zu div. anderen Herstellern,
die kleineren TQFPs nicht mit 0.5 mm Pitch anbietet (u.U. Vorteile beim
Layout gegenüber QFN).

> In vielen Anwendungen ist man froh darüber, wenn man ein Sofwareupdate
> einfach durch Wechseln des Chips durchführen kann. Das können auch noch
> viele Kunden selbst machen.

Wenn das Gerät schon eine irgendwie geartete Schnittstelle nach draußen
hat, dann hat der Kunde bzw. der Hersteller das auch (meistens) so
eingerichtet, dass er diese nutzen kann.

> OK, dann muss der also irgendwoher einen passenden funktionierenden
> Rechner finden. Dann muss der Kunde auch noch irgendwie das Programm zum
> Laufen bekommen. Und zu guter letzt muss er noch so nahe an das Gerät
> mit seinem Rechner herankommen, dass das USB-Kabel reicht.

Und zum Austausch des Controllers, nimmt der Kunde dann die Anlage, in
der das Gerät steckt, außer Betrieb, baut alles ab, nimmt das Gerät
auseinandern, tauscht den Controller aus (der nicht selten eingelötet
sein muss) und riskiert das andere ESD-empfindliche Bauteile den
Eingriff nicht überleben usw.?

> Rechnung musst Du sowieso schreiben und verschicken. Und die
> Wahrscheinlichkeit, dass der Kunde beim Auswechseln einen
> unkorrigierbaren Fehler macht ist geringer als bei irgendwelchen
> Software-updates per USB.

Rechnungen für Firmware-Updates? Solange das keine gravierenden
Änderungen sind (die der Kunde unbedingt haben wollte), haben diese
kostenlos zu sein...
Zur Fehleranfälligkeit an sich: Das hängt, neben der Software, eben auch
stark vom Controller ab (z.B. ob bestimmte Flash-Bereiche sicher vor
einem Überschreiben geschützt werden können, ob die Spannungsversorgung
vernünftig überwacht werden kann bzw. wird etc.).

> Ich hoffe daher schwer, dass ATMEL in die X-Serie auch einen internen
> Oszillator einbaut, der dann per PLL für den USB genutzt werden kann und
> es erlaubt einen UART durch ein externes Quarz mit gerader Baudrate zu
> betreiben.

Jein bzw. theoretisch ja, es gibt intern einen 2 MHz Osz. und 32 MHz
Osz, die sich automatisch mit einem externen Takt (32 kHz TOSC)
abgleichen können:
Full speed USB braucht 48 MHz +- 0.25 %, was sich auch mit passender
Genauigkeit mit 32768 Hz abgleichen lässt (0.1 %), Clock-Jitter sollte
auch die Spezifikation erfüllen (zumindest geht das z.B. bei Freescale
oder Cyan 1)). Bleibt nur noch aus 48/24/16 MHz einen passenden
UART-Takt zu erzeugen. Das geht bei 16 MHz und 24 MHz mit einem Fehler
kleiner 1 % z.B. für 230400, 115200, 57600, 38400 etc. (bei 16 MHz auch
460800 und 921600).

> Oder aber sie bohren den 32kHz Oszillator so auf, dass man
> mit seinem Clock auch andere Peripherie betreiben kann. Dann kann man
> dort das passende Quarz für die UARTs anschließen.

Nein, der Peripherietakt ist vom CPU-Takt abhängig. Ausnahme ist nur der
RTC.

1) http://www.freescale.com/files/32bit/doc/app_note/AN2539.pdf

Arc Net wrote:
>> Als Nachfolger der ATMega Controller wird das irgendwie nicht
>> überzeugend, zumal DIP-Gehäuse noch fehlen.
>
> DIP-Gehäuse sind heutzutage absolut irrelevant. Zu groß, zu teuer, dazu
> u.U. noch Probleme aufgrund der Induktivität der Anschlüsse (z.B. Ground
> Bounce).

Das ist einerseits verständlich. Andererseits wundert mich dagegen z.B.
Microchip, die selbst die neuen 33er dsPICs mit 40MIPs als DIP anbieten.

Es wird halt zur Folge haben, dass Universal-Kits wie der STK500
schwierig werden. Der STK500 hat ja fast alles bis 40 Pins drauf, und
das zu einen sehr vernünftigen Preis. Was preislich bei QFPs rauskommt
sieht man an den STK5xx-Piggibacks für Mega128, Mega256 usw. Da geht der
Löwenanteil der Herstellungskosten für die Fassung drauf, 3 solche
Dinger auf einem Basisboard dürfte zu teuer werden.

Arc Net wrote:
> Mich wundert eher, das Atmel, im Gegensatz zu div. anderen Herstellern,
> die kleineren TQFPs nicht mit 0.5 mm Pitch anbietet (u.U. Vorteile beim
> Layout gegenüber QFN).

Vielleicht, weil sie so kulant gegenueber uns armen Bastlern sind und
wissen, dass man 0.5mm-Pitch nur noch schlecht selber aetzen kann? Und
soviel an Platz gewinnt man gerade bei den kleineren Packages dadurch
auch nicht.

:-) Das will ich sehen!

so hat jeder seine Macken ;) aber stimmt, es liest sich grässlich

Gruß Hagen

Arc Net wrote:
> Jein bzw. theoretisch ja, es gibt intern einen 2 MHz Osz. und 32 MHz
> Osz, die sich automatisch mit einem externen Takt (32 kHz TOSC)
> abgleichen können:
> Full speed USB braucht 48 MHz +- 0.25 %, was sich auch mit passender
> Genauigkeit mit 32768 Hz abgleichen lässt (0.1 %), Clock-Jitter sollte
> auch die Spezifikation erfüllen (zumindest geht das z.B. bei Freescale
> oder Cyan 1)). Bleibt nur noch aus 48/24/16 MHz einen passenden
> UART-Takt zu erzeugen. Das geht bei 16 MHz und 24 MHz mit einem Fehler
> kleiner 1 % z.B. für 230400, 115200, 57600, 38400 etc. (bei 16 MHz auch
> 460800 und 921600).
>
>> Oder aber sie bohren den 32kHz Oszillator so auf, dass man
>> mit seinem Clock auch andere Peripherie betreiben kann. Dann kann man
>> dort das passende Quarz für die UARTs anschließen.

Es gibt einen Fractional Baud Rate Clock Generator. Habe ich oben
schonmal erwähnt, damit ist die Diskussion eigentlich hinfällig, da so
alle üblichen Baudraten mit kleinem Fehler erzeugt werden können. (Seite
225 im Manual)

Für den XMega gibt es zwei Datenblätter, ein Manual und eine
detaillierte Peripherie-Beschreibung.

Travel Rec. wrote:
> Für den XMega gibt es zwei Datenblätter, ein Manual und eine
> detaillierte Peripherie-Beschreibung.

Markiert als "Preliminary"

Michael G. wrote:

> Markiert als "Preliminary"

Das scheint bei Atmel normal zu sein.

Auch bei Modellen, die schon seit einiger Zeit allgemein verfügbar sind,
sind die Datenblätter teilweise noch als "Preliminary" gekennzeichnet.

Vielleicht verschlingt die Produktion so viel Manpower, daß für
ausgiebige Tests und Datenblattschreiberei keine Zeit bleibt ;-)

Travel Rec. wrote:
> Vielleicht verschlingt die Produktion so viel Manpower, daß für
> ausgiebige Tests und Datenblattschreiberei keine Zeit bleibt ;-)

OT: Keine Zeit ist doch immer nur ne Ausrede für kein Geld ;-)

Echt? ;-)

>Ich könnte mir etwas schöneres
>vorstellen, als alle Datenblätter zu "warten" und immer aktuell zu
>halten.

Das sind aber Arbeitsplätze.

Sind per ISP, JTAG und PDI programmierbar.

Martin wrote:

> Falls es nicht mehr möglich sein sollte, diese Prozessoren per SPI
> zu programmieren, dann wären diese so hoch gepriesenen Prozessoren
> für mich nicht zu gebrauchen, den die Tatsache, dass die
> ATMEGA-Familie über SPI programmierbar ist, hat für meine Projekte
> gewisse Vorzüge, die ich bei anderen Prozessoren nicht habe.

Welche Nachteile siehst Du denn bei PDI im Vergleich zu SPI?

Gut, man braucht einen neuen Adapter, aber in der praktischen
Anwendung dürfte PDI noch einfacher zu handhaben sein als SPI,
z.B. weil man nur noch einen drei- oder vierpoligen Stecker dafür
braucht und weil die Programmierschnittstelle am Controller keine
"normalen" Portpins belegt.


Egon wrote:

> Also bei den Angaben auf der Atmel Webseite zu den Tools für die
> Xmegs steht immer noch: "In-System Programming: AVRISP mkII
> In-System Programmer" ...

Ich nehme an, daß man dem AVRISP mkII per Firmware-Update beibringen
kann, sich mit den XMEGAs über PDI zu unterhalten.


Travel Rec. wrote:

> Sind per ISP, JTAG und PDI programmierbar.

Quelle?

"ISP" sagt erstmal nur, daß sie im eingebauten Zustand programmierbar
sind, aber nicht über welche Schnittstelle. Ich nehme aber mal an, Du
meintest SPI.

In den Datenblättern der XMEGAs konnte ich bisher keinen Anhaltspunkt
dafür finden, daß sie neben JTAG und PDI auch über SPI programmierbar
sind.

Halt, ich muß mich korrigieren: laut bestehendem Datensatz sind die
XMEGAs nur über PDI (was eine bidirektionale ISP-Schnittstelle
darstellt, in Verbindung mit dem RESET-pin) und über JTAG programmiert
werden. Kein ISP im altbekannten Sinn, also inkompatibel zu STK500,
AVR_ISP und bisheriger AVR_Dragon-Firmware.

Travel Rec. wrote:
> Halt, ich muß mich korrigieren: laut bestehendem Datensatz sind die
> XMEGAs nur über PDI (was eine bidirektionale ISP-Schnittstelle
> darstellt, in Verbindung mit dem RESET-pin) und über JTAG programmiert
> werden. Kein ISP im altbekannten Sinn, also inkompatibel zu STK500,
> AVR_ISP und bisheriger AVR_Dragon-Firmware.

Hallo,

ist das Protokoll wenigstens offen, so daß man sein Programmiergerät
modifizieren kann ?


Jogibär

Michael Jogwich wrote:

> ist das Protokoll wenigstens offen, so daß man sein Programmiergerät
> modifizieren kann ?

Wirf mal einen Blick in die Datenblätter, da findest Du alles.

>Theoretisch. Praktisch eher nicht, zumindest für Normalkunden. Zumindest
>wurde mir das am Atmel Stand auf der Embedded World gesagt.
>Preislich sollten die ein kleinwenig über den vergleichbaren ATmegas
>liegen, die dann zunehmend auslaufen.

Hatte gestern Vertreterbesuch ...
Mir wurde versichert, das die ATMegas nicht auslaufen werden.
Hab auch erste 2 Samples, mal sehn ...

>Erhältlich sollen die ab Mitte 2008 sein. Ich rechne aber eher mal mit
>Ende 2008.

Mass production soll in Juni starten.

Joachim wrote:

> Welchen Typ gibt es als erstes bzw. als Muster?

Das dürfte mit größter Wahrscheinlichkeit der ATxmega128A1 sein.

genau.

Interessant ist wohl leicht untertrieben, für einen normalen
ATMega128-16AU möchte Digikey €13,50, den entsprechenden XMega128 gibt's
für nichtmal die Hälfte: € 5,22. Wenn sich dieses Verhältnis auch bei
anderen Lieferanten in dieser Art fortsetzen sollte, sehe ich für so
einige ATMegas schwarz.

Gruß
Jadeclaw.

Jadeclaw Dinosaur wrote:
> Wenn sich dieses Verhältnis auch bei
> anderen Lieferanten in dieser Art fortsetzen sollte, sehe ich für so
> einige ATMegas schwarz.

Ob das vielleicht Atmels Absicht ist? ;-)

CSD-electronics wird die XMegas auch bald haben, sicher günstiger, als
Angelika.

Maria wrote:
> Ich bin auf Zilog ZNEO umgestiegen. 128kB Flash, 4kB RAM. 13 Register a
> 32-Bit.
>
> Im PLCC68 per Fassung auf Lochrasterkarte. Eine 2x3-polige Stiftleiste
> plus ein Widerstand bilden den Anschluss für das 20Euro
> USB-Programmier/Debug-Kabel.

Ich benutze zur Zeit dsPic33FJ128XX802.
128 kB Flash
16 kB RAM
40 MIPS
CAN,...

DIP28 Gehäuse.


Trotzdem wärs Interessant wenn man mal wüsste wanns die XMegas zu kaufen
gibt.

@Maria:
Habe das Ganze mal verglichen --> mit einem normalen ATMega1280.
Vorteil ZNEO: PLCC-Gehäuse (wegen der lochrastertauglichen Sockel);
IrDA-Encoder; OpAmp; DMA.
Nachteile ZNEO: Absturzfreudige IDE(deine Aussage); Timer langsam(max.
1/4 CPUtakt); Fehlendes EEProm.

Vorteile ATMega1280: Mehr Timer, die auch schneller sind(1/2 CPU-Takt);
mehr SRAM; EEPRom; mehr ADC-Eingänge; mehr PWM-Kanäle; stabile IDE(auch
ohne Make-File-Fummeleien, GCC wird automatisch gefunden); kompatibles
Upgrade möglich, wenn der Speicher nicht reicht(ATMega2560); kein
Spezialkabel/Spezialprogrammierer notwendig, man kann alles selbst
bauen; Externes Speicherinterface auch bei der 'kleinen' Version 1281;
Problemlos bei Endverbraucherlieferanten erhältlich.

Nachteile ATMega1280: Kein PLCC-Gehäuse, einlöten wird fummelig, wg.
TQFP-Gehäuse;, nur 16MHz CPU-Takt; kein DMA.

Noch Fragen?

Gruß
Jadeclaw.

>Was kostet die
>äquivalente Hardware für den ATxmega? Mehrere 100 Euro.#

Nicht ganz. Support für den AVR-ISP mkII ist angekündigt. Programmieren
kann man dann für 40 EUR. Debuggen wird eventuell mit dem Dragon möglich
sein. Ist noch nicht ganz ´raus.

Im SP1 zum AVR-Studio (Beta) sind die Files zum Programmieren der XMegas
mit dem mkII schon drin, siehe:
http://www.atmel.no/beta_ware/

mfg
wolfgang