www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Ist ATXMEGA etwa out?


Autor: Kaspar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!


Hab mir vor Kurzem das XPLAIN-Board bestellt. Die ersten Gehversuche mit 
dem neuen Prozessor ATXMEGA128A1 waren ein Erfolg.

Es ist einfach unglaublich, was dieser neue Prozessor alles kann. 
Zwischen ATMEGA und ATXMEGA ist tatsächlich ein Quantensprung.

Nur habe ich so das Gefühl, als würde dieser Prozessor bei der 
Allgemeinheit nicht ganz so gut ankommen. Woran mag das liegen?

Es ist nicht ganz einfach, einen einzelnen Prozessor zu bekommen, was 
meine Vermutung nur noch stärkt. Bisher blieben meine Bemühungen 
erfolglos.
Bei so manchem Anbieter hätte ich schon einzelne Prozessoren bestellt 
oder nachgefragt. Entweder man bekommt keine Antwort oder man wird auf 
ein paar Monate vertröstet.

Wie steht ihr dazu?
Setzt ihr den ATXMEGA überhaupt ein?
Oder gehört er bald ganz unverhofft zu einem längst vergessenen Flop?


LG

Kaspar

Autor: David ... (volatile)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Mine Fields (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaspar schrieb:
> Es ist nicht ganz einfach, einen einzelnen Prozessor zu bekommen, was
> meine Vermutung nur noch stärkt. Bisher blieben meine Bemühungen
> erfolglos.
> Bei so manchem Anbieter hätte ich schon einzelne Prozessoren bestellt
> oder nachgefragt. Entweder man bekommt keine Antwort oder man wird auf
> ein paar Monate vertröstet.

Das ist im Moment ganz normal und nicht nur beim XMEGA so.

Autor: Norbert L. (norbert_l64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürliches Wachstum folgt immer einer e-Funktion.
Noch sind wir bei t=0 ;-)

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATXMEGA schön und gut.... Aber wenn man etwas gescheites in annehmbarer 
Zeit machen will, so führt meiner Ansicht nach momentan an den 
Cortex-M3ern kaum ein Weg vorbei. 32-Bit, kein second-source-Problem, 
günstig, in großer Auswahl sofort lieferbar, reichlich ausgestattet, 
schnell,... die Liste ließe sich noch eine Weile fortsetzen :-)

Für die ATXMEGAS trifft meistens genau das Gegenteil zu. Wenn man nicht 
vollends Atmel-blind ist, tut man sich gut daran sich von den ATXMEGAS 
fern zu halten. (Meine Meinung)

GRuß: Dennis

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kaspar schrieb:
> Nur habe ich so das Gefühl, als würde dieser Prozessor bei der
> Allgemeinheit nicht ganz so gut ankommen.

Och nöö - dem ist nicht so.

Kaspar schrieb:
> Es ist nicht ganz einfach, einen einzelnen Prozessor zu bekommen, was
> meine Vermutung nur noch stärkt. Bisher blieben meine Bemühungen
> erfolglos.

Dann hast Du die falschen Lieferanten. Siehe Foto, Auszug heutiger 
Katalog www.TME.EU

Kaspar schrieb:
> Wie steht ihr dazu?
> Setzt ihr den ATXMEGA überhaupt ein?
> Oder gehört er bald ganz unverhofft zu einem längst vergessenen Flop?

Wir setzen ihn ein und profitieren von den Features. Nix Flop.

Autor: Kaspar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Dennis!

Welche Cortex-M3er verwendest du? - Das sind doch die ARM7-Nachfolger. 
Habe ich recht?

Schöne Grüße, Kaspar

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Wenn man nicht
> vollends Atmel-blind ist, tut man sich gut daran sich von den ATXMEGAS
> fern zu halten. (Meine Meinung)

Genau. Deine Meinung. Aber die Diskussion hatten wir hier schon ein paar 
Male.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaspar schrieb:
> Hi Dennis!
>
> Welche Cortex-M3er verwendest du? - Das sind doch die ARM7-Nachfolger.
> Habe ich recht?
>
> Schöne Grüße, Kaspar

NEIN der Cortex M3 ist ehr ne Mischung aus µC und ARM7 also ehr nen 
Lowcost ARM auf alle fälle kein Nachfolger

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> kein second-source-Problem

Ach, erzähl mal?  Du tauschst einfach so die Controller zwischen
den Herstellern aus?

ARM ist doch nur ein CPU-Core, aber für den fertigen Controller
braucht's noch die Peripherie, und die bastelt wieder jeder Hersteller
für sich drumrum.  Ab da war's das mit gegenseitiger Austauschbarkeit,
dann musst du dich doch wieder auf einen Hersteller festlegen.

Das ist doch genauso 'ne Mär wie die, dass man beim 8051 davon
profitieren würde, dass der von x verschiedenen Herstellern gefertigt
wird.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du kannst ja nicht erwarten, daß alle sofort ihre alten Schaltungen 
wegschmeißen, nur weil es nen neuen Chip gibt.

Nen neuen Chip nimmt man erst dann, wenn man wirklich dessen Features 
braucht und die Kosten für das Redesign, CE-Zertifizierung und die 
Einarbeitung in den Hintergrund treten.

Mich interessiert nicht, was ein MC kann, sondern was ich brauche.
Wenn ich z.B. etwas Logik + Ablaufsteuerung brauche, pappe ich eben 
schnell mal nen ATtiny84 im DIP auf ne Uniplatine.
Da wäre es Unsinn, für nen Xmega mit Spannungsregler und Pegelwandler 
erstmal ein Layout machen zu müsen.


Da Du Dich ja mit dem Xmega auskennst, habe ich eine Frage.
Das SPI der Mega ist ja als Slave völlig unbrauchbar.
Ist das SPI der Xmega besser?
D.h. kann er als Slave per FIFO oder DMA Datenpakete am Stück 
empfangen/senden, ohne das der Master nach jedem Byte erstmal Däumchen 
drehen muß?


Peter

Autor: Ronny T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
K. J. schrieb:
> NEIN der Cortex M3 ist ehr ne Mischung aus µC und ARM7 also ehr nen
>
> Lowcost ARM auf alle fälle kein Nachfolger

Na, ARM selbst sieht den M3 schon als Nachfolger des ARM7TDMI. Und NXP 
bietet beispielsweise auch für den LPC236x (ARM7) nun die Pinkompatiblen 
LPC176x (Cortex-M3) an.

Nebenbei: Der Cortex Core ist nun etwas standardisierter als früher der 
ARM7TDMI. So sind nun zumindest Interuptcontroller und der System-Timer 
bei allen Herstellern gleich. Insofern gibt es zwar keine 1:1 
Replacement von verschiedenen Herstellern, aber wenn man von z.B. stattt 
STM32 nun auf LPC17xx umsteigt, dann kommt einem alles schon sehr 
bekannt vor...

Autor: Hmmmm? (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nur habe ich so das Gefühl, als würde dieser Prozessor bei der
> Allgemeinheit nicht ganz so gut ankommen. Woran mag das liegen?

Die diversen Fehler können einem schon gewaltig die Laune verderben, 
wenn man gerade eines der betroffenen Feature braucht. Für meinen 
persönlichen Geschmack sind bei den Xmegas zu viele Dinge kaputt, als 
dass ich einen mal eben sorglos und ohne groß drüber nachzudenken für 
ein Projekt nehme. Besonders, da ich den Eindruck habe, das bei der 
Errata noch nicht das letzte Wort gesprochen ist.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaspar schrieb:

> Es ist einfach unglaublich, was dieser neue Prozessor alles kann.
> Zwischen ATMEGA und ATXMEGA ist tatsächlich ein Quantensprung.

Finde ich auch, denn ein Quantensprung ist eigentlich der kleinste 
überhaupt wahrnehmbare Sprung. ;-)

> Nur habe ich so das Gefühl, als würde dieser Prozessor bei der
> Allgemeinheit nicht ganz so gut ankommen. Woran mag das liegen?

Für mich verknüpfen die XMegas die Nachteile der 8-Bitter mit den 
Nachteilen der 32-Bitter. Ein paar nette Seiten mögen sie haben, aber 
nachdem ich sah, dass Atmel hartnäckig jeden Support für Flash im 
Dataspace verweigerte, war der Fall geklärt. Dieser Teil der 
AVR-Programmierung hat mich jenseits der Zwergenklasse stets genervt.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daß Atmel neue ATmega8A, 16A, 128A entwickelt hat, zeigt auch daß die 
immer noch in großen Stückzahlen verwendet werden, obwohl die Nachfolger 
(ATmega88, 164, 1281) schon viele Jahre lang verfügbar sind.

Wenn es einen Chip gibt, dessen Leistung dem Großteil der Anwender 
völlig ausreicht, dann kannst Du warten, bis Du schwarz wirst, Du wirst 
keinen neueren Chip in den Markt pressen können.

Ich tendiere auch dazu, falls ich mal mehr Leistung benötigen sollte, 
einen Cortex M3 zu nehmen, statt einen Xmega.

Der Xmega setzt ja auf dem AVR-GCC auf und hat damit das Problem der 
64k-Grenze für Flash und Daten. Und int auf nem 8Bitter als 32Bit zu 
definieren, dürfte die Performance wieder drastisch ausbremsen.


Peter

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Setzt ihr den ATXMEGA überhaupt ein?

Noe, ich setze R8C/M16C und R32 ein weil ich da verschiedene 
Leistungsklassen bekommen kann die sehr aehnlich sind.

> Daß Atmel neue ATmega8A, 16A, 128A entwickelt hat, zeigt auch daß die
> immer noch in großen Stückzahlen verwendet werden, obwohl die Nachfolger
> (ATmega88, 164, 1281) schon viele Jahre lang verfügbar sind.

Klar, das ist einfach der Bestand. Ich hab auch noch den Mega8 laufen 
und werde erst dann etwas dran aendern wenn es den nicht mehr geben 
sollte.

> Wenn es einen Chip gibt, dessen Leistung dem Großteil der Anwender
> völlig ausreicht, dann kannst Du warten, bis Du schwarz wirst,

Yep. Ich denke nicht das sich in naechster Zeit viel bei den Prozessoren 
tun wird. Nicht weil es nicht moeglich waer, aber weil kaum noch Bedarf 
an Verbesserungen besteht.
Den MCS48 fand ich schon krank als ich ihn programmiert habe, der ST6 
war nicht viel besser. Ein Mega8 war toll als er aufkam ist aber 
mittlerweile Durchschnitt mit dem man leben koennte. Einen M16C/29 fand 
ich vor zwei Jahren total super und ich wuesste nicht warum sich daran 
sobald etwas aendern sollte. So langsam wissen die Hersteller nicht mehr 
was sie noch einbauen koennen. :-)


Olaf

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Da Du Dich ja mit dem Xmega auskennst, habe ich eine Frage.
> Das SPI der Mega ist ja als Slave völlig unbrauchbar.
> Ist das SPI der Xmega besser?
> D.h. kann er als Slave per FIFO oder DMA Datenpakete am Stück
> empfangen/senden, ohne das der Master nach jedem Byte erstmal Däumchen
> drehen muß?

Er kann per DMA Daten aus dem RAM oder von anderer Peripherie in das 
Datenregister des / der SPIs laden. Das DMA läuft mit fCPU und braucht 4 
Zyklen, um ein Byte zu transferieren. Wenn der betreffende DMA-Kanal 
durch den RAM-Puffer durch ist, kann er automatisch auf die 
Anfangsadresse geladen werden, der Controller füllt den Puffer wieder 
oder ein anderer DMA-Kanal übernimmt dies und dann geht´s weiter.

Autor: stromflo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Travel Rec,

hast du da zufällig ein Beispiel dafür?

Das würde mir bei meinem Vorhaben im moment richtig helfen :)

Wäre super.

Gruß Flo

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATXMEGA    '251
------- = ------
ATMEGA     8051

Autor: Armin K. (-donald-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaspar schrieb:
> Nur habe ich so das Gefühl, als würde dieser Prozessor bei der
> Allgemeinheit nicht ganz so gut ankommen. Woran mag das liegen?


Meiner Meinung nach kann der XMEGA zu viel und ist wesentlich 
komplizierter zu programmieren. Habt ihr euch mal ein Beispielprogramm 
angeschaut? Ich habe mal im Codevision ein neues Projekt gestartet, da 
ist die Initialisierung, ohne eine Zeile eigenen Code geschrieben zu 
haben, schon ein mehrseitiges Dokument.

Und das macht das für uns "Bastler" uninteressant.

Meine Meinung.

Autor: Andreas K. (derandi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für das, was ich mit µC anstelle, ist nicht selten schon ein ATMega ein 
Overkill.
Ausserdem laufen die alten Megas noch mit 5V und die gibts auch in 
DIL-Package.

Autor: narf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für kleinere sachen  tiny  oder mega .. für größere nen Cortex

wer mal PRogrammierung der Cortex und der Xmega vergleicht wird 
feststellen das es nicht viel unterschiede gibt ...

die cortex sind aber nunmal deutlich  fixer
bzw bieten hier schon mehr reserven

Autor: Sebastian S. (sebastian-s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Moin

> Ist ATXMEGA etwa out?

Also was mich betrifft sind die noch nicht ganz in.

Die neuen Spielereien, wie z.B. DMA sind schon cool und sicher auch 
praktisch, nur hatte ich noch kein Projekt wo sich das gelohnt hätte.
Mir reicht meistens ein ATmega.

Dazu kommt bei mir persönlich noch zwei Dinge :
1) Meine Megas programmiere ich mit dem STK500, also bräuchte ich 
zumindest einen neuen Programmieradapter oder gleich das XPLAIN-Board 
für den ganz noblen Start.
Das geht ins Geld und da ich gerade zwischen Schule und Studium hänge 
ist davon nicht allzu viel da.

2) Man bekommt die Chips immer noch nicht an jeder Ecke wie z.B. bei dem 
Online-Laden mit R.

Was dann denke ich bei vielen Leute noch dazu kommt (nicht hauen, 
Meinung von jemand mit wenig Erfahrung in der Richtung), ist dass die 
Megas/Tinys fast schon eine Art Standardlösung in ihrer Leistungsklasse 
sind.
Zumindest bei Hobbyisten wie mir, werden meist kleine AVRs oder Pics 
benutzt.
Die XMegas sind ein (oder ein paar) Leistungsklassen darüber.
Und da gibt es halt schon ein paar (viele) andere Lösungen, wie z.B.
oben schon genannte Cortex M3. (Ob man die zwei so direkt vergleichen 
kann weiß ich nicht, ich kenn nur grobe Eckdaten)
Jedenfalls würde ich, falls ich ein einmal richtig Rechenpower benötige 
nicht auf den allerneusten Chip setzen mit dem erst wenige Leute 
Erfahrungen gemacht und veröffentlicht haben.
Sondern nach irgendetwas suchen wo man viele Projekte, Codeschnipsel und 
Anleitungen schon online findet (und natürlich was vor allem von der 
Leistung und den 'features' auf meinen Anwendungsfall passt).
Einfach weil das dass Einarbeiten erleichtert und man auch Leute hat die 
man Fragen kann, wenn betriebsblind irgendwo feststeckt.

So das war mal mein Standpunkt als kleiner Hobbybastler.
Ich denke Leute die beruflich mit solchen Sachen zu tun haben werden da 
manches auch wieder anders sehen.


Gruß
Sebastian

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also was ich sehr gut am ATxmega finde: Er kann viel. Manch mal braucht 
man bei exotischen Projekten schon mal mehrere UARTS, viele Timer usw.

Was ich aber schlecht finde: Er kann viel. ;-)
Selbst bei einem exotischen Projekt, verwendet man höchstens "gefühlte" 
10% der gesamten Transistoren im AVR. Es gibt quasi kein Projekt, wo man 
viele Timer, viele UARTS, viele I2C Schnittstellen, 2 DAC und 2ADCs (von 
der Crypto-Unit mal ganz zu schweigen) verwenden kann. Man bezahlt also 
irgendwie viel mehr, als man überhaupt nutzen kann.
Ganz klare Sache von Overkill.

PS: Trotzdem macht der ATxmega Spass. Mit dem Event System zum Beispiel 
kann man tolle Sachen anstellen.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> Ach, erzähl mal?  Du tauschst einfach so die Controller zwischen
> den Herstellern aus?

Das natürlich nicht so einfach.

> ARM ist doch nur ein CPU-Core, aber für den fertigen Controller
> braucht's noch die Peripherie, und die bastelt wieder jeder Hersteller
> für sich drumrum.  Ab da war's das mit gegenseitiger Austauschbarkeit,
> dann musst du dich doch wieder auf einen Hersteller festlegen.

ARM ja, bei Cortex ist schon deutlich mehr als nur der CPU-Core 
standardisiert, und wenn Du Dir CMSIS anschaust, dann weißt Du, wohin 
die Reise geht.

> Das ist doch genauso 'ne Mär wie die, dass man beim 8051 davon
> profitieren würde, dass der von x verschiedenen Herstellern gefertigt
> wird.

Nun ja, bei Cortex hat man immerhin schon die Toolchain, den JTAG, 
Trace-HW (soweit implementiert), und das ist auch schon viel wert.

fchk

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank K. schrieb:
> ARM ja, bei Cortex ist schon deutlich mehr als nur der CPU-Core
> standardisiert, und wenn Du Dir CMSIS anschaust, dann weißt Du, wohin
> die Reise geht.

Ob da "die Reise hingeht" hilft dir eben nur im Falle des Falles
jetzt und heute nichts: das viel beschworene "second source" ist
bestenfalls ein Abhake-Punkt für den Chef.  In der Praxis müsste
man beim Umstieg auf den Controller eines anderen Herstellers nach
wie vor massig ändern.  Wenn man das Projekt von vornherein flexibel
ausgelegt hat und den Aufwand dafür spendiert (hardware abstraction
layer und solche Dinge), dann isses am Ende auch egal, ob du vom
Xmega auf einen Cortex M3 umsteigst oder vom Cortex M3 des Herstellers
X auf den des Herstellers Y.

Autor: narf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein wechsel von mega zu Xmega ist auch hier niczht wirklich möglich und 
ebenso kompliziert wie von mega zu M3 ...

da die lieferbaren Xmega  und selbst > mega64
teurer sind wie vergleichbare STM32 oder LPC13xx oder LPC17xx
ist für mich das nicht eine frage des aufwandes ....

TQFP löten und bis runter zu 0603 ist alles kein thema
auch nicht für einen hobbybastler

und gerade für STM32 gibt richtig schicke bibliotheken die quasi das 
wichtigste fertig liefern

wer portieren will sollte seinen Code entsprechend gestalten...
den mal abgesehen von I/Os und einigen registern ist bei normalem C- 
standard kein großer portierungsaufwnad nötig

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> dann isses am Ende auch egal, ob du vom
> Xmega auf einen Cortex M3 umsteigst oder vom Cortex M3 des Herstellers
> X auf den des Herstellers Y.

Das meinst du nicht im Ernst, oder?

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also was ich sehr gut am ATxmega finde: Er kann viel.
> Was ich aber schlecht finde: Er kann viel. ;-)

Das ist bei den fetten Brummern nunmal so. Man stoesst zwar nie an 
Grenzen, aber verbringt manchmal ein Stuendchen FEhlersuche bloss weil 
man uebersehen hat das es noch irgendwo ein Bit fuer eine Sonderfunktion 
gab.

> Es gibt quasi kein Projekt, wo man viele Timer, viele UARTS, viele I2C
> Schnittstellen, 2 DAC und 2ADCs

Ich habe gerade ein Project wo ich acht UARTs in einem R32C verwende. 
:-)

Ich habe mich auch schonmal gefragt wofuer man 10Timer oder so braucht, 
aber es bildet sich nach einer Weile bestimmte Lieblingstimer fuer 
bestimmte Funktionen raus und dann kann man bei einem neuen Project 
einfach alles aus alten Projecten zusammenkopieren und muss nicht viel 
aendern.

> In der Praxis müsste man beim Umstieg auf den Controller eines anderen
> Herstellers nach wie vor massig ändern.

Ich verschiebe oft Sachen zwischen Prozessoren die nun ueberhaubt nichts 
miteinander zutun haben. In diesen Minuten z.B von SH2A nach M16C. Mein 
Eindruck ist das man oft grosse sehr komplexe Dinge vollkommen 
problemlos verschieben kann. (z.B FAT-Filesystem) und man vor allem an 
kleinen Nebensaechlichkeiten rumbasteln muss. Ich bewerte secondsource 
bei Prozessoren nicht mehr sehr hoch. Da kann ein Peripheriebaustein 
viel schlimmer reinhauen. (z.B MAX6675)

Olaf

Autor: narf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dennis schrieb:
> Jörg Wunsch schrieb:
>> dann isses am Ende auch egal, ob du vom
>> Xmega auf einen Cortex M3 umsteigst oder vom Cortex M3 des Herstellers
>> X auf den des Herstellers Y.
>
> Das meinst du nicht im Ernst, oder?

warum nicht ???
wenn man die applikation streng trennt .. ist das kein thema
copy& paste und es läuft

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für mich ist der Xmega ein Anachronismus. Ich kann nicht 24Bit Adreßraum 
versprechen und dann keine Befehle zur linearen Adressierung geben.

Der Xmega läßt sich nicht mehr linear adressieren!
Man muß erst die entsprechenden Page-Register laden (RAMPX,Y,Z,D, EIND) 
und die werden nichtmal bei den Autoincrement/-Decrementbefehlen mit 
berechnet.


Peter

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Man muß erst die entsprechenden Page-Register laden (RAMPX,Y,Z,D, EIND)
> und die werden nichtmal bei den Autoincrement/-Decrementbefehlen mit
> berechnet.

Werden sie doch. Die den X...Z-Pointern zugeordneten RAMPn Register 
werden beim Over-/Underflow des Pointer-Highbytes mit erhöht oder 
erniedrigt.

Peter Dannegger schrieb:
> Ich kann nicht 24Bit Adreßraum
> versprechen und dann keine Befehle zur linearen Adressierung geben.

Nicht vergessen: Im XMEGA verrichtet eine AVR-CPU ihren Dienst. 
Lediglich die Peripherie ist aufgebohrt und der Speicher / I/O-Breich 
aufgeräumt. Bitte nicht immer auf dem Teil herumhacken. Ich denke nach 3 
Jahren XMEGA-Programmierung und -Anwendung, dass das Teil ganz gut die 
Lücke zwischen Mega-AVRs und 32-Bit Controllern füllt und 
praktischerweise mit (einigen) Programmiergeräten und der IDE der 
AVR-Serie programmiert werden kann. Die Leistung des XMEGA stellt die 
normalen AVRs weit in den Schatten. Will man noch mehr, greift man 
ohnehin zu anderen Controllern.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. schrieb:
> Peter Dannegger schrieb:
>> Man muß erst die entsprechenden Page-Register laden (RAMPX,Y,Z,D, EIND)
>> und die werden nichtmal bei den Autoincrement/-Decrementbefehlen mit
>> berechnet.
>
> Werden sie doch. Die den X...Z-Pointern zugeordneten RAMPn Register
> werden beim Over-/Underflow des Pointer-Highbytes mit erhöht oder
> erniedrigt.

Ja, daran haben sie schon gedacht. Leider lässt (wie oben schon erwähnt) 
die AVR-GCC Unterstützung an dieser Stelle klaffende Löcher.
So kann man nicht mehr als 64kB vom Speicher per C verwalten lassen.
Was aber geht ist, den Speicher selbst zu verwalten. Ich brauche bei 
einem aktuellen Projekt viel Speicher und habe ein SDRAM angeflanscht, 
dass in 2 große 2Megabyte Blöcke zerlegt ist. Lesen und Schreiben 
erfolgt dann über selbstgeschriebe (eigentlich eher von Atmel kopierte) 
Funktionen, die uint32_t als Adresse benutzen. Das Lesen erfolgt 
außerdem bei mir noch mittels DMA (die den vielen Speicher ja ohne 
Probleme unterstützt).

> Peter Dannegger schrieb:
>> Ich kann nicht 24Bit Adreßraum
>> versprechen und dann keine Befehle zur linearen Adressierung geben.
>
> Nicht vergessen: Im XMEGA verrichtet eine AVR-CPU ihren Dienst.
> Lediglich die Peripherie ist aufgebohrt und der Speicher / I/O-Breich
> aufgeräumt. Bitte nicht immer auf dem Teil herumhacken. Ich denke nach 3
> Jahren XMEGA-Programmierung und -Anwendung, dass das Teil ganz gut die
> Lücke zwischen Mega-AVRs und 32-Bit Controllern füllt und
> praktischerweise mit (einigen) Programmiergeräten und der IDE der
> AVR-Serie programmiert werden kann.

Ich habe wegen einem anderen Projekt vorhin mal bei NXP rumgeschaut. Da 
kriegt man einen LPC1752, der ungefähr in der selben Kategorie liegt 
(Ok, hat 100MHz Core Takt, dafür nicht ganz so viel Peripherie). Der 
kostet dann bei digikey etwa 7 Dollar pro Stück.
Ein ATxmega64A3 8,1 Dollar.

Fragt sich, warum man jetzt noch zu dem ATxmega greifen sollte. Man 
bekommt für quasi das gleiche Geld schon einen Cortex M3 Prozessor. Die 
Leistung von diesem 32 Bitter sollte schon viel größer sein.
Bei den Programmiergeräten hast du schon Recht. Genau da setzt ja auch 
Atmel an, wenn ich das richtig sehe. Außerdem vermute ich mal, dass sie 
auf das Event System setzen, dass ich so noch nirgendwo gesehen habe.
Weitere Gründe sehe ich aber dennoch nicht.
---- CUT!
Ok, das artet schon wieder in die Diskussionen aus, die wir schon länger 
und öfter haben/hatten.

> Die Leistung des XMEGA stellt die
> normalen AVRs weit in den Schatten.

Wohl wahr!


Mein Fazit jedenfalls ist: Der ATxmega ist nett, aber ich habe noch so 
meine Zweifel ob der sich kommerziell durchsetzen kann.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. schrieb:
> Werden sie doch. Die den X...Z-Pointern zugeordneten RAMPn Register
> werden beim Over-/Underflow des Pointer-Highbytes mit erhöht oder
> erniedrigt.

Kannst Du bitte mal die Stelle (PDF, Seite) nennen, wo das steht.

Die Atmel Datasheets machen es einem manchmal doch recht schwer, die 
nötigen Informationen zu finden.

Ich denken aber doch, daß ich besser gleich nen 32Bitter nehme, wenn ich 
nen 24bit Adreßraum brauchen sollte.
Ein Register zu laden, anstatt 3 Register, das hat was.


Peter

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Kannst Du bitte mal die Stelle (PDF, Seite) nennen, wo das steht.

Steht eigentlich nicht wirklich da (Wortlaut im DB: Das RAMPn-Register 
ist mit dem Pointer n verknüpft...), aber ich habe es ausprobiert und es 
geht.

Peter Dannegger schrieb:
> Die Atmel Datasheets machen es einem manchmal doch recht schwer, die
> nötigen Informationen zu finden.

Das ist in letzterer Zeit verstärkt der Fall, ja.

Peter Dannegger schrieb:
> Ich denken aber doch, daß ich besser gleich nen 32Bitter nehme, wenn ich
> nen 24bit Adreßraum brauchen sollte.
> Ein Register zu laden, anstatt 3 Register, das hat was.

Jaa, aber das sind Äpfel und Birnen. Wenn man nicht wirklich Lust und 
Zeit und auch nicht das Geld hat, um noch neue Entwicklungstools 
anzuschaffen und sich neue Controllerfamilien anzueignen, nimmt man halt 
den XMEGA...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Außerdem vermute ich mal, dass sie
> auf das Event System setzen, dass ich so noch nirgendwo gesehen habe.

Ich habe jetzt ehrlich gesagt, null Vorstellung, was das ist und wozu 
man es brauchen könnte. Gibts dazu irgendwo ne verständliche Erklärung?

Ich fand es bei den AVRs sehr angenehm, daß alle Details in den 
Datasheets zu finden waren. Das scheinen sie aber leider bei den Xmega 
durchbrochen zu haben.

In heutigen Zeiten spielt doch Dateigröße keine Rolle mehr. Da muß man 
es dem Nutzer doch nicht mehr zumuten, Informationen in vielen 
Dokumenten verstreut mühsam zusammen zu klauben.


Peter

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaspar schrieb:

> Nur habe ich so das Gefühl, als würde dieser Prozessor bei der
> Allgemeinheit nicht ganz so gut ankommen. Woran mag das liegen?

Keine DIP-Versionen und nur eingeschränkter Betriebsspannungsbereich. Da 
kann man dann auch gleich einen 32-Bitter nehmen, zumal der Preisabstand 
zu denen nicht besonders groß ist.

> Wie steht ihr dazu?
> Setzt ihr den ATXMEGA überhaupt ein?
> Oder gehört er bald ganz unverhofft zu einem längst vergessenen Flop?

Für mich persönlich ist er einer. Prinzipiell recht interessant, aber 
die obigen Nachteile machen ihn für mich zum Flop.

Oder wie "A. K." so treffend bemerkte: Die XMegas verknüpfen die 
Nachteile der 8-Bitter mit den Nachteilen der 32-Bitter.

Eigentlich sehr schade, denn gerade die Schnittstellen der ATmegas (SPI 
und I2C) hatten durchaus eine Renovierung notwendig...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Simon K. schrieb:
>> Außerdem vermute ich mal, dass sie
>> auf das Event System setzen, dass ich so noch nirgendwo gesehen habe.
>
> Ich habe jetzt ehrlich gesagt, null Vorstellung, was das ist und wozu
> man es brauchen könnte. Gibts dazu irgendwo ne verständliche Erklärung?

Es gibt die Application Note von Atmel zum Event System. Leider ist die 
Atmel Website im Moment down.
Das ist im wesentlichen genau das, wonach es sich anhört.
Es gibt 8 Event-System Kanäle, die man zwischen die unterschiedlichen 
Peripherien schalten kann. Zum Beispiel das Input Capturing geht beim 
ATxmega darüber. Dadurch lässt sich (fast) jeder Pin für das Input 
Capturing benutzen.
Im Moment benutzen ich das Event System dazu, um zwei Timer zum exakt 
gleichen Zeitpunkt zu starten.

> Ich fand es bei den AVRs sehr angenehm, daß alle Details in den
> Datasheets zu finden waren. Das scheinen sie aber leider bei den Xmega
> durchbrochen zu haben.
Ja, finde ich aber auch gut. Denn es gibt jetzt das große Manual, wo 
alle Peripherien im Detail drinstehen und dann noch ein Datenblatt zu 
jedem xmega Typ (A1 bis A4). In letzterem stehen dann elektrische 
Details drin und die Pinbelegung der einzelnen Peripherien.

Macht NXP bei den ARMs ja auch so.

> In heutigen Zeiten spielt doch Dateigröße keine Rolle mehr. Da muß man
> es dem Nutzer doch nicht mehr zumuten, Informationen in vielen
> Dokumenten verstreut mühsam zusammen zu klauben.

Allerdings muss man dann in jedem Dokument für jeden xmega-Typ ständig 
die gleichen Informationen mitschleppen (Zum Beispiel die zum Timer).
Eine andere Erklärung habe ich dafür jedenfalls nicht.

So schlimm ist es aber nicht.

Autor: Gastino G. (gastino)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Allerdings muss man dann in jedem Dokument für jeden xmega-Typ ständig
> die gleichen Informationen mitschleppen (Zum Beispiel die zum Timer).
> Eine andere Erklärung habe ich dafür jedenfalls nicht.

Die verteilte Dokumentation hat mich schon bei einem Infineon-Controller 
(C166) zur Weißglut getrieben - mal abgesehen davon, dass die Doku im 
Vergleich zur ATMEL-Doku sowohl inhaltlich als auch sprachlich miserabel 
und unvollständig ist.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn man ganz klar weiß, was wo steht, dann ist das kein Problem. Genaue 
Details zu den Peripherien stehen im Manual. Alles Typ-spezifische im 
Datenblatt.

Es gibt natürlich auch beim ATxmega noch Sachen, die nirgendwo stehen. 
Aber das ist denke ich üblich bei neuen Mikrocontrollern.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Simon K. schrieb:
>> Außerdem vermute ich mal, dass sie
>> auf das Event System setzen, dass ich so noch nirgendwo gesehen habe.
>
> Ich habe jetzt ehrlich gesagt, null Vorstellung, was das ist und wozu
> man es brauchen könnte. Gibts dazu irgendwo ne verständliche Erklärung?

Im Grunde ist das ein Schaltschrank. Du hat verschiedene Hut-Schienen 
und darauf die verschiendenen Eingangs- und Ausgangsmodule verschiedener 
Peripheriebausteine. Mittels Kabeln (hier: Steuerbits in Multiplexern) 
kannst Du jedes Modul mit jedem Modul verbinden und durch das Klappern 
eines Ausgangs eines Moduls den Eingangszustand eines anderen Moduls 
ändern. Du kannst also andere Module starten oder stoppen, 
DMA-Transaktionen auslösen, mit Pins wackeln und viele Dinge mehr. Du 
hast 8 "Kabel" zu einer Zeit zum Verbinden verschiedener Module zur 
Verfügung, also 8 Event-Kanäle, die einmal pro Aufgabenstellung 
konfiguriert werden und dann bis zur Umkonfigurierung so geschaltet 
bleiben und ohne CPU-Interaktion funktionieren. Somit kannst Du völlig 
autonome, modulare Automaten im XMEGA aufbauen, die neben der CPU ihre 
Arbeit verrichten. Fast alle Interruptflags können Events auslösen.

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum hat hier eigentlich noch niemand die MSP430 erwähnt?
Die sind eigentlich auch ganz nette µCs, leider sehr komplex (ich hab' 
das Powermangament und das Taktverteilungsystem von denen bis heute noch 
nicht verstanden). Dazu sind die MSP430 sehr stromsparend.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Luk4s K. schrieb:

> Warum hat hier eigentlich noch niemand die MSP430 erwähnt?

Vielleicht weil das Thema die XMegas sind?

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Luk4s K. schrieb:
>
>> Warum hat hier eigentlich noch niemand die MSP430 erwähnt?
>
> Vielleicht weil das Thema die XMegas sind?

Dann hätten hier auch Cortex M3 u.ä. nichts verloren.

Autor: Kaspar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Danke für eure vielen Beiträge. Die ganzen Vor- und Nachteile fand ich 
ungeheuer interessant und lesenswert.

Wenn man selbst beginnt, sich mit einer Controllerfamilie zu 
beschäftigen,
hat man zu Beginn nicht immer den Überblick. Aus diesem Grund helfen 
einem
die Meinungen und Erfahrungen anderer oft sehr weiter.

Und was den MSP430 angeht, ich kenne ihn zwar nicht, aber ich freue mich 
natürlich, wenn auch andere Beiträge reinkommen, die andere geniale 
Technologien beschreiben.
Wenn jemand noch etwas über den MSP430 zu berichten weiß, ich würde mich 
sehr freuden.

Schönen Tag, Kaspar

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Leute!


Ich dachte ich muss auch meinen Senf dazugeben.

Viele sagen, dass der ATXMEGA einen Overkill darstellt, weil zu viele 
Funktionen aufweist, die man eh nicht braucht. Ich glaube aber, wenn man 
z.B. einen Prototypen baut, ist es völlig egal, wenn man gleich den noch 
leistungsfähigeren Prozessor nimmt oder jenen der mehr drauf hat. Auf 
die paar Cents kommt's ja dann wohl doch nicht an.

Früher haben immer alle gemeckert, dass der kleine AVR keine 
Interrupt-Prioritäten oder ähnliche tolle Funktionien (.z.B. DMA) 
hat....
Jetzt hat Atmel Abhilfe geschaffen und jetzt passt es auch wieder nicht.

Wenn ich mit einer Funktion nicht vertraut bin, muss ich sie ja nicht 
benutzen, dadurch wird für mich ein Prozessor doch nicht komplizierter, 
nur weil er mehr Funktionen aufweist, sondern höchstens vielseitiger. 
Aber ich hab im Hinterkopf was er noch könnte und dies kann dann 
angewendet werden, wenn es dann soweit ist und man sich damit vertraut 
macht.

Ich kann jetzt mal nur vom Prototypen-Bau sprechen, aber meine Erfahrung 
hat in diesem Bereicht gezeigt, dass eine gute Reserve viel Wert ist. 
Wenn ich sowieso eine SMD-Platine fertige, dann knall ich gleich den 
ATXMEGA drauf, statt einen ATMEGA.

Auch wenn er angeblich einen Overkill darstellt und ich z.B. mit einem 
ATMEGA128 auch auskommen würde, benutze ich eine neuere Technologie. 
Zudem sind die ATMega bei manchen Anbietern teuerer als die ATXmega und 
das Gehäuse ist gleich groß oder kleiner, wenn man den entsprechenden 
Typen verwendet. Das ist doch toll, wenn man mehr unter der Haube hat, 
im Notfall.

Manche gehen anscheinend nach dem Motto vor: "Das sind zuviele 
Funktionen
für meine Anwendung, also nehme ich jenen Prozessor, der älter ist,
mehr kostet und dieselbe Gehäusegröße besitzt. Wäre ja eine 
Verschwendung
einen zu nehmen, der günstiger ist, aber die vielen Funktionen, die ich
nicht benötige dann brach im Prozessor liegen."
Oder nach dem Motto: "Der hat soviele Funktionen. Ich fürchte mich."

Ich gebe zu, die Datenblätter waren bei den Atmegas doch etwas besser 
strukturiert, aber das ist kein Vergleich zu C167 Datenblättern, die 
schlagen alles an Unübersichtlichkeit.

Was mir gefällt ist diese großartige einheitliche Struktur, die sich 
durch die ganze ATXMEGA-Prozessorarchitektur zieht. Gleichartige 
Hardware-Einheiten sind gleich aufgebaut, sodass man für eine Struktur 
nur den Pointer ändern muss, wenn man zwischen diesen Einheiten hin- und 
herswitchen will. Z.B. zwischen UARTS.
Oder aber auch die Einteilung der Ports für die Zusatzfunktionen ist 
nach einem einheitlichen Schema aufgebaut und sehr gut dokumentiert.

Es sind auch keine so dummen Ausnahmen vorhanden, die dem 
Programmierer/Entwickler das Leben schwer machen, jeder Port verhält 
sich gleich, nicht so wie es z.B. beim LPC2138 (ARM7) der Fall ist.
Wenn man sich die Pin-Configuration ansieht.
P0.2 und P0.3 haben laut Datenblatt als Zusatzfunktion die 
I2C-Schnittstelle und man kann diese Pins angeblich auch als normalen 
I/O-Port verwenden. Das stimmt aber nicht. Diese Pins haben kein 0V oder 
3,3V, sondern nur 0V und Open-Drain, weil sie an die I2C-Schnittstelle 
angepasst sind. Manche Ports haben einen integrierten Pull-Up-Widerstand 
und manche wieder sind nach der Initialisierung einfach nur hochohmige 
Eingänge.
Um solche Dummheiten herauszufinden verplempert man zu Beginn viel Zeit.

Was die Komplexität der Programmierbarkeit angeht, kann ich mich nicht 
ganz euren Meinungen anschließen. Ich arbeite mit dem Codevision-AVR. 
Wichtig ist, dass man sich mal in die einzelnen 
Prozessorstruktureinheiten (UART, Ports, Timer usw.) einarbeitet, aber 
dann geht es viel schneller weil alles nach demselben Schema aufgebaut 
ist und ich glaube, dass man ebenso eine bessere lesbarkeit erzielt.
Es gibt dann nicht eben einfach nur ein ORS2 Register, wie es z.B. beim 
ATMEGA128 für das Timer 2-Output-Compare Register der Fall ist oder ein 
OCR0 Register für Timer 0-Output-Compare Register,
sondern für Timer-TCC0: TCC0.CCA und für Timer TCD0 sieht das so aus: 
TCD0.CCA usw.
Was denkt ihr, was ist übersichtlicher bzw. einfacher nachvollziehbar? 
(ORS2 und OCR0) oder (TCC0.CCA und TCD0.CCA)

Es wurde endlich richtig aufgeräumt. Was die vielen 
Initialisierungs-Kommandos angeht, sind die beim Codevision-Wizard 
tatsächlich etwas lange und umständlich. Sie verschlingen an die 
1000-Zeilen Code.
Wenn ich jedoch eine entsprechende Peripherie-Einheit eh nicht benötige, 
muss ich sie ja gar nicht initialisieren und kann den Code verkürzen, 
weil diese Einheiten sowieso standardmäßig (nach Reset) abgeschaltet 
sind.
Zudem nimmt einem der Code-Wizard ungeheuer viel Arbeit ab, weil er dem 
Programmierer zeigt, wie die einzelnen Einheiten initalisiert werden 
müssen.
Dieser Umstand ist bei einem ARM-Prozessor ungleich komplizierter, weil 
z.B. ein Keil-Compiler keinen Code-Wizard benutzt und man alles selbst 
initialisiern muss. Na gut, es gibt Beispiele, aber diese muss man erst 
verstehen und dann für das Problem abändern. Zudem gibt es für manche 
ARM-Prozessoren tatsächlich Wizards, aber die sind meist etwas ärmlich.

Was die Errata-Datenblätter angeht: Solche Kinderkrankheiten treten bei 
jedem neuen Prozessor auf. Besonders dumm ist es, wenn man ein Feature 
benötigt, dieses aber gar nicht funktioniert oder wahrscheinlich gar 
nicht implementiert ist, so wie es beim LPC2138 der Fall war.
Für meine Anwendung hätte ich eine Brown-Out-Detektion im Prozessor 
benötigt. Im Errata-Datenblatt steht dazu, dass die Brown-Out-Detektion 
nicht funktionert, genauer Text:
Problem: BOD reset does not get triggered when the voltage of Vdd falls 
below 2.6V.
Work-around: None

Toll was? Im Fall Errata geraten leider die ATXMega stärker in Kritik, 
weil sich viel mehr Menschen damit beschäftigen, was gut ist, weil es 
dazu verhilft, solche Fehler und Schwächen bei der nächsten 
Prozessor-Revisionen auszumerzen.
Als damals meine Brown-Out-Detection beim LPC2138 nicht funktionierte 
hat das keiner gemerkt.

Okay, wenn man ein bestehendes Design hat oder nicht umsteigen möchte 
von ATMEGA auf ATXMEGA, dann bleibt das jedem selbst überlassen, aber 
eine neue Technologie deshalb in den Schmutz zu ziehen, finde ich nicht 
korrekt.

Natürlich ist es schade, dass die Prozessoren nur noch in SMD erhältlich 
sind oder nur bis 3,3V gehen, aber das ist bei den ARMs auch der Fall.

So gesehen finde ich, dass die ATXMEGA-Serie ein würdiger Nachfolger der 
ATMEGA-Serie ist.



Schönen Tag noch.

LG, Martin

Autor: Lukas K. (carrotindustries)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaspar schrieb:
> Wenn jemand noch etwas über den MSP430 zu berichten weiß, ich würde mich
> sehr freuden.

Ich bin auf die MSP430 durch die ez430 Chronos gekommen ('hab mit den 
AVRs angefangen). Als Compiler verwende ich GCC. Die MSP430 sind 
deutlich komplexer als die AVRs, so haben die MSP430 z.B. relativ 
ausgefeilte Schlafmechanismen und Taktverteilungsmöglichkeiten. Wenn man 
diese Hürden überwunden hat, programmierte es sich nicht wirklich anders 
als auf den AVRs. GCC macht's möglich :) Sehr nett ist das Portmapping, 
man kann die Ausgänge von Peripherieeinheiten auf beliebige Pins 
weiterleiten was einem vermutlich viel Kopfzerbrechen beim Layouten 
ersparen kann.

Autor: Jonny Obivan (-geo-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
besteht eigentlich ein preisliches Argument für/gegen CortexM3 und 
Atxmega?
Manchmal habe ich das Gefühl, dass selbst ein Atmega preismäßig fast bei 
den Cortex-Teilen angesiedelt ist. So ein Atmega kostet schonmal fast 10 
Euro (die größeren Atmega). Für den selben Preis gibt es 32 bit Chips 
auch schon, wobei deren Leistung natürlich kaum zu vergleichen ist.

Autor: DDT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauptgegenargument:

Overskilled, komplizierter zu programmieren, und: KEIN DIP/DIL!!!

Da kaufe ich mir lieber noch mal ne 100er Packung AtMega(8)er bevor die 
vom Markt verschwinden...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DDT schrieb:
> Overskilled, komplizierter zu programmieren, und: KEIN DIP/DIL!!!

Also bei allem Fuer und Wider, das ist kein Argument. Schon eher, dass 
er trotz des AVR-Kerns keine 5V mehr verkraftet. Alles andere ist im 
Prinzip Ansichtssache. Eine komplett neue Familie bedeutet 
Programmierhardware, Entwicklungsumgebung, alles neu und anders und $$. 
Womoeglich auch noch Windows-Only. Als Hobbyist leiste ich mir so einen 
Aufwand eher nicht, wozu auch, da darf man ignorant sein.

Der GCC-Support sollte halt mal offiziell werden (nicht nur 3rd-party 
patches) und dann auch nach Moeglichkeit vollstaendig, dann haette man 
sicherlich auch mehr davon. Aber immerhin funktioniert es :D Ich 
erinnere mich gut daran, dass selbst AVR-Studio massive Probleme 
bereitet hat, als ich damals mein Projekt durchgezogen habe. Sehr 
unausgereift und nervraubend gewesen. Aber auch jetzt ist es nicht ganz 
ohne, mal einen entsprechenden GCC zu bekommen, den muss man selber 
bauen.

Joa aber was die Verfuegbarkeit angeht: Immernoch schlecht, wobei er in 
Zwischenzeit auch beim R zu haben ist -- nur der 128A1. Ein neues 
Silizium waere in Anbetracht der vorhandenen Fehler auch mal angebracht. 
Anscheinend ist es auch Seitens von Atmel recht ruhig darum geworden.

Ich hab in Zwischenzeit ca. 160 meiner Entwicklungsboards verteilt, aber 
viel kommt da leider auch nicht zurueck. Is wohl in erster Linie der 
"haben will"-Effekt am Tragen. Schade eigentlich. Aber so ganz 
aufgegeben hab ich die Sache deswegen nicht. Waere cool wenn "wir" da in 
Zukunft noch mehr nach vorne preschen koennten und auch Code 
bereitgestellt wird.

Greets,
Michael

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mich am Xmega hauptsächlich stört, ist die fehlende Kompabilität.

Wenn ich mir einen besseren AVR wünschen könnte, dann müßte er folgendes 
haben:
- Pin- und Spannungskompatibel zu den ATtiny/mega
- Behebung des I2C-Multimasterbug
- SPI mit Sendepuffer
- Taktquelle auch in SW änderbar, damit kein Verfusen mehr nötig
- zusätzliche IO-Register für 2..4 Interruptprioritäten.

Dann könnte man ihn schrittweise einführen und ausprobieren.
Und Atmel könnte die alten ATtiny/mega aus dem Programm nehmen.

Was noch nett wäre, wäre eine Routingmatrix, um IO-Funktionen wenigstens 
auf einen Alternativpin legen zu können.
Beim ATtiny261 wurde das ja schon mal mit dem USI angefangen (wahlweise 
auf PORTA oder PORTB).


Peter

Autor: Carsten Wille (eagle38106)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Was mich am Xmega hauptsächlich stört, ist die fehlende Kompabilität.

Um es drastisch zu sagen: Scheiß auf die Kompatibilität. Irgendwann muß 
man alte Zöpfe radikal abschneiden.

> - Taktquelle auch in SW änderbar, damit kein Verfusen mehr nötig

Ja wie stellst Du denn den Xmega vom RC-Osc. auf Xtal um? Das geht im 
Xmega nur noch per Software!

Carsten

Autor: Name (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

aus Bastlersicht:

>Wenn ich mit einer Funktion nicht vertraut bin, muss ich sie ja nicht
>benutzen, dadurch wird für mich ein Prozessor doch nicht komplizierter,
>nur weil er mehr Funktionen aufweist, sondern höchstens vielseitiger.

Einspruch....

>Man stoesst zwar nie an Grenzen, aber verbringt manchmal ein Stuendchen 
>FEhlersuche bloss weil man uebersehen hat das es noch irgendwo ein Bit fuer
>eine Sonderfunktion gab.

Je mehr Funktionen desto länger das Datenblatt, desto mehr potentielle 
Fehler bzw. Problemquellen (Von wegen dieses und jenes Modul muss 
abgeschaltet oder so und so konfiguriert werden um ein anderes Modul 
bzw. einen Pin nutzen zu können) und desto größer der Frust. Ich 
(Gelegenheitsbastler) krieg immer die Krise wenn ich für irgendeine 
banale Kleinigkeit stundenlang suchen muss weil ich irgendeine Falle 
nach längerer Bastelinaktivität wieder vergessen hab. Da ist es gut wenn 
der Käfer einfach und das Datenblatt kurz ist, desto weniger muss man 
sich merken bzw. desto schneller ist man beim Nachschlagen.

Und von wegen Gehäuseformen: Ein SMD-Käfer kann man nicht so einfach auf 
Lochraster braten...

Wer beruflich oder privat ständlich mit µPs und komplexen Projekten zu 
tun hat hat sicherlich andere Prioritäten.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Taktquelle auch in SW änderbar, damit kein Verfusen mehr nötig

Hat der XMega, alle Clocks werden zur Laufzeit umgeschaltet und 
konfiguriert. Verfusen IST nicht möglich.

Peter Dannegger schrieb:
> - zusätzliche IO-Register für 2..4 Interruptprioritäten.

Interruptprios sind beim XMega in 3 verschiedene Stufen unterteilt. Jede 
Peripherie kann jede dieser 3 Stufen zu jeder Zeit nutzen.

Peter Dannegger schrieb:
> - SPI mit Sendepuffer

Ist über DMA reibungslos möglich. Gaps im SPI-Timing sind nicht mehr 
existent.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Und Atmel könnte die alten ATtiny/mega aus dem Programm nehmen.

Das würde wohl nicht passieren. Atmel wird schon wissen, was sie in 
ihrem Portfolio brauchen. So gibt es ja z.B. auch ATTinys die - 
zumindest für uns Bastler - nicht weniger kosten als vergleichbare 
ATMegas. (z.B. ATTiny44 vs. ATMega48) Schon da kann man sich fragen, ob 
sich das lohnt.

Geguckt habe ich auch schon nach den ATXMegas. Bei Peripherie-ICs 
bekommt man ohnehin zunehmend Probleme, wenn man bei 5V arbeiten will. 
Volle Rechenleistung bei 3,3V halte ich da eher für eine Vor- als einen 
Nachteil. Die Gehäuseform (SMD) ist auch nicht unbedingt ein Argument 
für jemanden, der schon an einen ATMEGA128 gedacht hatte, den es ja auch 
nicht in DIP gibt.

Auf der anderen Seite macht ein XMega wohl nur Sinn, wenn man die 
zusätzliche Hardware auch nutzt. Und dann ist das am Ende nicht mehr 
viel anders als sich in irgendeinen anderen Controllertyp einzuarbeiten.

Solange ich mit den old-fashioned AVR8 meine Projekte umsetzen kann, 
werde ich daher die XMegas nicht einsetzen. Und falls die nicht mehr 
reichen sollten, sind AVR32 und ARM sicher auch mit auf der Liste der 
Alternativen. Für mich sitzt der XMega irgendwie zwischen den Stühlen.

Autor: DDT (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja auch noch:

Auch wenn die die normalen vom Markt nehmen, würde ich ehr erst zu den 
8tern umsteigen:
Statt Mega8 -> Mega88
...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carsten Wille schrieb:
> Um es drastisch zu sagen: Scheiß auf die Kompatibilität. Irgendwann muß
> man alte Zöpfe radikal abschneiden.

Dann arbeitest Du wohl nicht in der Industrie.
Man kann nicht ständig alle Produktlinien neu entwickeln, das kann 
keiner bezahlen. Man kann immer nur kleine Schritte machen.
Es müssen uralte und neueste Geräte zusammen arbeiten können, sonst 
kauft der Kunde woanders.
Industriekunden wollen lange Laufzeiten, die kaufen nicht alle 6 Monate 
ne neue Steuerung und schmeißen die alte weg, wie Du Dein Handy.


> Ja wie stellst Du denn den Xmega vom RC-Osc. auf Xtal um? Das geht im
> Xmega nur noch per Software!

Aber der ist doch nicht kompatibel!

Um einen 3,3V IC in ein 5V-System zu integrieren, reicht eine 
Layoutänderung nicht aus.
Deshalb eben voll kompatibel und die Zusatzfunktionen in ungenutzte 
IO-Register gelegt.
D.h. 1:1 austauschbar mit jetzigen ATtiny/mega, die dann eingestellt 
werden könnten.


Peter

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstaunlich, daß hier eines der Hauptprobleme noch nicht angesprochen 
wurde: Der Flaschenhals "externer RAM". Schön, daß man billigen SDRAM 
benutzen kann (wenn auch nur exotische Typen). Weniger schön, daß die 
Leistung so darunter leidet. Und selbst wenn man sich guten, teuren SRAM 
gönnt - ich wage zu behaupten, daß der Speicherdurchsatz eines Mega128 
mit externem SRAM besser ist. Vielleicht kann ja jamand das mit Fakten 
stützen oder widerlegen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian schrieb:
> Und selbst wenn man sich guten, teuren SRAM
> gönnt - ich wage zu behaupten, daß der Speicherdurchsatz eines Mega128
> mit externem SRAM besser ist. Vielleicht kann ja jamand das mit Fakten
> stützen oder widerlegen.

Das SRAM-Interface des XMega ist mit Fcpu *2 taktbar, also mit 64Mhz. 
Noch dazu arbeitet das DMA direkt mit allen Speicherbereichen und aller 
Peripherie zusammen, so dass die CPU nur noch bei Block-Operationen 
kurzzeitig einschreiten muß. Bei einem direkt und ohne Latches 
angeschlossenen RAM sind Zugriffszeiten um 30ns realistisch. Bei meinen 
Versuchen mit dem SD-Karten-Wave-Recorder bin ich mit 45ns-SRAM an 
Grenzen gestoßen. Mit 12ns-SRAM konnte ich bei 64Mhz ohne Waitstates 
arbeiten. Somit braucht ein externer RAM-Zugriff lediglich 3 
CPU-Clockzyklen.

Autor: tut nix zur Sache (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein AVR8 mit 64 kB RAM satt wäre schon was Feines.
Da bräuchte ich mich nicht bei STM32 umzusehen...
So gesehen, tue ich mir den Xmega für neue Projekte
gar nicht erst an.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:

> Was noch nett wäre, wäre eine Routingmatrix, um IO-Funktionen wenigstens
> auf einen Alternativpin legen zu können.
> Beim ATtiny261 wurde das ja schon mal mit dem USI angefangen (wahlweise
> auf PORTA oder PORTB).

Das bekommt man ja faktisch durch die ganze Redundanz, wenn ich auf 
jedem Port eine UART habe kann ich es mir aussuchen, wo sie liegen soll, 
wenn auch nicht gerade auf Pin-Ebene... aber wenn man alles frei waehlen 
koennte waer's natuerlich schon gigantisch, aber auch realistisch? :P

Autor: Jan K. (pit1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der XMega ist ganz sicher nicht out, sondern eine absolut sinnvolle 
Fortführung der alten Mega-Linie hin zu einer neuen Leistungsklasse. Wen 
da fehlende Kompatibilität zu den alten Typen stört der wird sie bei 
Cortex-M3 und Konsorten gewiss nicht eher finden. Den Vorwurf 
komplizierterer Programmierung kann man nicht stehen lassen- das ist nun 
mal stets die Währung mit der mehr Features und mehr Flexibilität 
bezahlt werden müssen. Lineare 16M Adressierbarkeit ist durchaus 
gegeben- sowohl über die schon erwähnten Pointer mit automatischer RAMPx 
Anpassung als auch direkt über die DMA-Kanäle. Zumindest als 
ASM-Programmierer hat man da kein Problem :-)
Für meine UART-bedürftigen Hobbyanwendungen kam der XMega wie gerufen- 
und meine Lieblingsbauteile RFM12, XPort und BTM222 harmonieren perfekt 
mit der neuen 3V Stromsparversorgung. Das leidige Fuse-Setzen gehört nun 
endlich auch der Vergangenheit an.
Man hat sich zwar fast dran gewöhnt, ich hätte mir aber weitergehende 
Änderungen am AVR-Kern gewünscht:  Endlich mal durchgängig einheitliche 
Verwendbarkeit aller Befehle für alle Universalregister, kräftigere 
bedingte Sprünge und ein vollständig erreichbarer I/O Raum mit den dafür 
zuständigen Instruktionen würden das ASM-Programmieren schon um einiges 
erleichtern und konsistenter machen. Schöpfungen wie die virtuellen 
Register sind doch da nur Krücken und bleiben auf halbem Weg dazu 
stehen. Ein wenig Sorgen darf auch die zunehmende Zersplitterung der 
Doku machen. Aber was solls- einen besseren AVR gabs jedenfalls noch 
nicht!

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan K. schrieb:
> Endlich mal durchgängig einheitliche
> Verwendbarkeit aller Befehle für alle Universalregister, kräftigere
> bedingte Sprünge und ein vollständig erreichbarer I/O Raum mit den dafür
> zuständigen Instruktionen

Reichen da die Bits im Befehlswort? Ich vermute hier das Problem, den so 
blöd sind die Ingeniusse von Atmel nun auch nicht, dass sie auf solche 
Ideen nicht allein kommen könnten. Das ganze Konzept umschmeißen und die 
Befehlsworte z.B. auf 18 Bit erweitern, würde mir gar nicht gefallen. 
Mir gefällt die konservative Linie von Atmel da eigentlich sehr gut.

Ich gebe dir aber soweit recht, als dass man bei den ATMEGAs neue 
Register (z.B. 2. UART) adressmäßig so hätte platzieren sollen, dass man 
mit IN/OUT da noch heran kommt. Voll ist der Bereich ja nicht.

Autor: Jan K. (pit1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja sicher, die Bits reichen nicht. Deshalb eben weitergehende Änderungen 
am Kern. Mehr Befehlsbreite schafft auch Luft für die Zukunft- so noch 
was nach dem XMega kommen sollte :-) Aber zugegeben- ist alles erstmal 
nur Wunschdenken rein aus Anwendersicht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.