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
1 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
1 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 B. (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 B. (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 W. (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 D. (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
-1 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 D. (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 B. (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
1 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
1 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 W. (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 D. (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 B. (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 D. (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 B. (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 D. (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 B. (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 O. (-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 D. (peda)
Datum:

Bewertung
1 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 W. (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 B. (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 D. (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 B. (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
1 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.

Autor: Gottfried (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Die Registerbänke sind bei allen XMega gleich, so kann man das 
kompilierte Endprodukt beispielsweise von einem XMega128 auf einen 
XMega64 laden, ohne neu kompilieren zu müssen.
Was mir am besten gefällt ist, dass er nicht verfust werden kann und 
eine einheitliche PDI schnittstelle hat, mit der man programmieren und 
debugen kann.
Dann kann er mit nur einem standard Uhrenquarz (32,768 kHz) betrieben 
werden und den internen RC Oscilator mit diesem synchronisieren.
Für extrem Low-Power kann auf den internen Oscilator mit 2MHz 
umgeschaltet werden (für Batterie Anwendungen).
Man kann mit dem bisherigen Tools weiterarbeiten (Compiler, Debuger und 
Programmer)

Ob die Cortex-M0 weniger Strom brauchen, kann ich nicht sagen, aber man 
muss sich neu in die Dokumente einlesen, andere Hardware, andere Tools, 
andere Probleme.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Meinst Du, daß das nach über sieben Jahren noch irgendwen interessiert?

Autor: Curby23523 N. (nils_h494)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leichenflederer...

Gottfried schrieb:
> Die Registerbänke sind bei allen XMega gleich, so kann man das
> kompilierte Endprodukt beispielsweise von einem XMega128 auf einen
> XMega64 laden, ohne neu kompilieren zu müssen.

Z.B. ist bei den STM32s auch vieles gleich oder ähmlich.

Gottfried schrieb:
> Was mir am besten gefällt ist, dass er nicht verfust werden kann und
> eine einheitliche PDI schnittstelle hat, mit der man programmieren und
> debugen kann.

Ist bei vielen Controllern heutzutage üblich, z.B. STM32.

Gottfried schrieb:
> Dann kann er mit nur einem standard Uhrenquarz (32,768 kHz) betrieben
> werden und den internen RC Oscilator mit diesem synchronisieren.

Ist trotzdem noch ungenau. Wenn es genau werden soll, muss ein richtiger 
Quarz angeschlossen werden.

Gottfried schrieb:
> Ob die Cortex-M0 weniger Strom brauchen, kann ich nicht sagen, aber man
> muss sich neu in die Dokumente einlesen, andere Hardware, andere Tools,
> andere Probleme.

Muss man immer bei neuen Prozessoren.

In der Summe sind moderne 32 bitter günstiger und leistungsfähiger. Ich 
würde einen Xmega nur noch einsetzen, wenn der Kunde das z.B. explizit 
wünscht.

: Bearbeitet durch User
Beitrag #5264216 wurde vom Autor gelöscht.
Autor: Randy B. (rbrecker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sind nur noch zwei ATXMega gelistet. Schade eigentlich, sieht aber so 
aus, als wären sie definitiv am Ende.

Autor: Ralf Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Randy B. schrieb:
> Es sind nur noch zwei ATXMega gelistet. Schade eigentlich, sieht
> aber so aus, als wären sie definitiv am Ende.

Das ist doch Unsinn.
Gib bei Microchip dazu mal den gesuchten Typ ein und recherchiere den 
Production-Status...

Autor: Randy B. (rbrecker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf Z. schrieb:
> Randy B. schrieb:
>> Es sind nur noch zwei ATXMega gelistet. Schade eigentlich, sieht
>> aber so aus, als wären sie definitiv am Ende.
>
> Das ist doch Unsinn.

Hier erscheinen nur noch zwei Typen:

https://www.microchip.com/paramChartSearch/chart.a...

Autor: Ralf Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils N. schrieb:
> Ist trotzdem noch ungenau. Wenn es genau werden soll, muss ein richtiger
> Quarz angeschlossen werden

Fürs meiste (z.B. auch UART-Kommunikation) langts locker. XMegas wie 
auch die noch aktuelleren XTinys verwende ich schon seit vielen Jahren 
ohne Quarz.

> In der Summe sind moderne 32 bitter günstiger und leistungsfähiger.

Das Bessere ist der Feind des Guten, die Entwicklung geht weiter. 
Dummerweise bringt jede Umstellung Aufwand, den man nicht zwangsweise 
eingeht wenn das gutbekannte Gute weiterhin locker ausreicht und 
bezahlbar bleibt.

Autor: M. K. (sylaina)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Randy B. schrieb:
> Es sind nur noch zwei ATXMega gelistet. Schade eigentlich, sieht aber so
> aus, als wären sie definitiv am Ende.

Sehe ich genauso. Spätestens bei der Übernahme von Atmel durch Microchip 
ist das praktisch das Todesurteil der Atxmegas gewesen. Ich denke auch, 
dass es bei den Atxmegas keine weitere Entwicklung geben wird und sie 
irgendwann komplett verschwinden werden.

Autor: Norbert T. (atos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Randy B. schrieb:
> Ralf Z. schrieb:
>> Randy B. schrieb:
>>> Es sind nur noch zwei ATXMega gelistet. Schade eigentlich, sieht
>>> aber so aus, als wären sie definitiv am Ende.
>>
>> Das ist doch Unsinn.
>
> Hier erscheinen nur noch zwei Typen:
>
> https://www.microchip.com/paramChartSearch/chart.a...


Man muss lediglich auf "Show ALL Products" drücken, dann erscheinen alle 
XMEGAS, ansonsten werden nur ausgewählte MCUs in dieser Tabelle 
angezeigt - "Show New/Popular Products". Ein Ende der XMEGAs ist also 
noch nicht in Sicht...

Autor: Ralf Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Ich denke auch,
> dass es bei den Atxmegas keine weitere Entwicklung geben wird

Denken ist zwar nicht Wissen.
Nachdem man nur noch von den XTinys hört wird das aber zunehmend 
wahrscheinlicher, seh ich auch so. Das muß nun aber nichts für die 
existierenden Typen bedeuten, nachdem meines Wissens alle fröhlich 
weiter produziert werden.

> und sie
> irgendwann komplett verschwinden werden

Ist das nicht Schicksal fast jedes IC?
Die ganze AVR Serie ist aber schon verdächtig lang am Markt, warum nicht 
noch länger?

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralf Z. (Gast)

>> und sie
>> irgendwann komplett verschwinden werden

>Ist das nicht Schicksal fast jedes IC?

Nicht nur jedes ICs, jedes Dinges auf Erden!

>Die ganze AVR Serie ist aber schon verdächtig lang am Markt, warum nicht
>noch länger?

Siehe 8051!

Glaubt ihr, Microchip legt ein paar Milliarden auf den Tisch um dann 
SÄMTLICHE Produkte des gekauften Unternehmens einzustampfen? Die werden 
verkaufen was geht! Und das ist auch sinnvoll, denn das Zeug ist gut am 
Markt positioniert und funktioniert!

Klar wird es ohne Weiterentwicklung irgendwann mal dem Ende zugehen, 
aber technologisch und strukturell sind die AVRs halt irgendwie auch 
ausgereizt, erst recht mit den "Lückenfüllern" ATXmega. Für die kleinen 
und mittleren Aufgaben sind sie voll OK, wer mehr braucht nimmt heute 32 
Bit.

Autor: Curby23523 N. (nils_h494)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Die xmegas wird es ganz einfach noch so lange geben wie sie a) Gewinn 
einbringen und b) eine Verjährung von Nachlieferung eintritt.

Autor: Randy B. (rbrecker)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Norbert T. schrieb:

>> Hier erscheinen nur noch zwei Typen:
>>
>> https://www.microchip.com/paramChartSearch/chart.a...
>
>
> Man muss lediglich auf "Show ALL Products" drücken, dann erscheinen alle
> XMEGAS, ansonsten werden nur ausgewählte MCUs in dieser Tabelle
> angezeigt - "Show New/Popular Products". Ein Ende der XMEGAs ist also
> noch nicht in Sicht...

OMG ... vielen Dank!

Autor: c-hater (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Falk B. schrieb:

> Klar wird es ohne Weiterentwicklung irgendwann mal dem Ende zugehen,
> aber technologisch und strukturell sind die AVRs halt irgendwie auch
> ausgereizt

Das sehe ich nicht so. MC hat viel Peripherie in den PICs, die auch sehr 
gut zu den AVR passen würde, weil sie deren Pendants mehr oder weniger 
stark überlegen ist. MC wäre gut beraten, diese Peripherie (nach 
Beseitigung der Errata) in die AVRs zu bringen, dann bleiben diese noch 
sehr lange konkurrenzfähig.

Bezüglich des MCU-Core haben sie ja mit den "ATXTinys" schon den 
richtigen Weg eingeschlagen (endlich Hardware-Multiplikation in den 
ATtiny, das war schon lange überfällig!), wobei dieser Weg sehr 
wahrscheinlich noch zu Atmel-Zeiten vorbereitet wurde, also nicht auf 
MC-Mist gewachsen ist.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> MC wäre gut beraten, diese Peripherie (nach Beseitigung der Errata) in
> die AVRs zu bringen, dann bleiben diese noch sehr lange konkurrenzfähig.

Ich glaube, das wird Wunschdenken bleiben.  Die entsprechenden
Entwicklerteams sitzen an so völlig verschiedenen Stellen auf der
Welt, dass die Tatsache, dass sie nun offiziell in der gleichen Firma
sind, da überhaupt nichts hilft.  Solche Dinge bekommt man nicht (oder
nur sehr schwer) per Order de Mufti miteinander integriert.

Ich denke, dass sie einfach eine geraume Zeit 8-bit PICs und AVRs
nebeneinander fahren werden, mit Weiterentwicklung im Bereich kleinerer
MCUs (AVR8X).  Bei den größeren braucht man gegen ARM einfach nicht
weiter anstinken: allein Dinge wie ein 32-bit-Adressraum machen diese
so viel angenehmer als das Segmentierungs-Gewurschtel beim AVR (mit
mehr als 128 KiB Flash), dass sich das als künftige Entwicklung nicht
lohnt weiterzuverfolgen.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@c-hater (Gast)

>> Klar wird es ohne Weiterentwicklung irgendwann mal dem Ende zugehen,
>> aber technologisch und strukturell sind die AVRs halt irgendwie auch
>> ausgereizt

>Das sehe ich nicht so. MC hat viel Peripherie in den PICs, die auch sehr
>gut zu den AVR passen würde, weil sie deren Pendants mehr oder weniger
>stark überlegen ist.

Welche denn?

> MC wäre gut beraten, diese Peripherie (nach
>Beseitigung der Errata) in die AVRs zu bringen, dann bleiben diese noch
>sehr lange konkurrenzfähig.

Sind sie auch so.

>Bezüglich des MCU-Core haben sie ja mit den "ATXTinys" schon den
>richtigen Weg eingeschlagen (endlich Hardware-Multiplikation in den
>ATtiny, das war schon lange überfällig!),

Was für eine Innovation . . .

Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Bezüglich des MCU-Core haben sie ja mit den "ATXTinys" schon den
> richtigen Weg eingeschlagen (endlich Hardware-Multiplikation in den
> ATtiny, das war schon lange überfällig!)

Das war bei meinen ATtinys noch nie der Flaschenhals gewesen. 
Berechnungen sind oft für den langsamen Menschen, d.h. sie dürfen lange 
dauern.
Dagegen sind mir die fehlenden Interruptlevel schon öfter auf die Füße 
gefallen, da ich sehr viel Zeitkritisches mit Interrupts mache.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Dagegen sind mir die fehlenden Interruptlevel schon öfter auf die Füße
> gefallen, da ich sehr viel Zeitkritisches mit Interrupts mache.

Das seh ich eher als Vorteil.
Die AVRs macht doch gerade aus daß sie einfach gestrickt sind. Wer mehr 
Features und Power braucht findet nun wirklich in anderen MC Familien 
was er sucht. Wobei man sagen muß, daß Atmel beim XMega mit der 
Komplexität ganz schön aufgedreht hat. Leider sind die großen Pluspunkte 
wie mehr Speed, mehr ADC Auflösung, Flash, SRam usw. nicht anders zu 
bekommen.

Autor: Helmut Fischer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:
> die großen Pluspunkte
> wie mehr Speed, mehr ADC Auflösung,
> Flash, SRam usw.

... runden das Leistungsspektrum auch nach Erscheinen der neuen 
Tiny-Generation nach oben ab. Inkl. neuer Interrupt-Level.

Autor: Peter D. (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fred schrieb:
> Das seh ich eher als Vorteil.

Was soll daran ein Vorteil sein, daß lange dauernde unkritische 
Interrupts alle zeitkritischen um ihre maximale eigene Laufzeit 
verzögern können?
Im Gegenteil, daß kann sehr häßliche Seiteneffekte haben, die nur selten 
auftreten und daher sehr schwer zu debuggen sind.

Beim AT89C51 habe ich fast immer 2 Level benötigt und manchmal sogar 
alle 4. Und das war auch nicht sonderlich komplex, jede Interruptquelle 
hat ein oder 2 Prioritätsbits, die man einfach nach dem Reset 
entsprechend gesetzt hat. Man konnte so z.B. ganz schnell auf eine 
Flanke reagieren, während der UART-Interrupt im Hintergrund ganz 
gemächlich Kommandos geparst hat.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Was soll daran ein Vorteil sein, daß lange dauernde unkritische
> Interrupts alle zeitkritischen um ihre maximale eigene Laufzeit
> verzögern

Interrupts sollten generell nicht lange dauern, es sei denn das ganze 
Programm besteht nur daraus.
Interrupt-Priorisierung bringen erst die Xmegas mit.
Irgend jemand wird im Einzelfall immer ein Feature finden was fehlt und 
wünschenswert wäre. In Summe realisiert wären das dann aber nicht mehr 
die einfachen AVRs wie wir sie kennen. Manches Feature lässt sich auch 
durch besseres/anderes Programmdesign ersetzen!

Autor: Flo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> während der UART-Interrupt im Hintergrund ganz gemächlich Kommandos
> geparst hat.

Du parst doch nicht etwa im Interrupt?
Da wird normal nur ein Buffer gefüllt und irgendwann im Hauptprogramm 
geparst.

Gerade weil du oben was von kurzen interrupten geschrieben hast...

Gruß
Flo

Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Flo schrieb:
> Du parst doch nicht etwa im Interrupt?

Das sollte doch nur ein Beispiel sein.
Es gibt in der Praxis immer mal Interrupts die länger dauern und welche, 
die nicht verzögert werden dürfen. Interruptlevel sind dann eine bequeme 
Methode, daß sich beide nicht in die Quere kommen.

Meistens kann man das auch durch höheren Programmieraufwand erreichen, 
aber schön ist was anderes.
Z.B. habe ich mal die langsamen Interrupts im Timerinterrupt pollen 
müssen. Der Timerinterrupt setzt ja sein Flag automatisch zurück, d.h. 
darf als ISR_NOBLOCK definiert werden und kann dann von den eiligen 
Interrupts unterbrochen werden. Direkt darf man die SPI-, I2C-, 
UART-Interrupts usw. nicht als ISR_NOBLOCK ausführen, sonst schießt man 
sich ins Knie.

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter Dannegger (peda)

>Das sollte doch nur ein Beispiel sein.
>Es gibt in der Praxis immer mal Interrupts die länger dauern und welche,
>die nicht verzögert werden dürfen. Interruptlevel sind dann eine bequeme
>Methode, daß sich beide nicht in die Quere kommen.

Stimmt schon, die Priorisierung von Interrupts ist ja nicht umsonst 
erfunden worden. Aber auch "große" CPUs wie die C2000 / PICCOLO 
Serie von TI haben KEINE Interruptpriorisierung in Hardware!
Vielleicht nur ein kleiner Trost, ist aber so 8-0.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:

> Welche denn?

Vor allem natürlich: SPI (besonders bezüglich des slave mode). Der 
master mode wurde ja immerhin durch die SPI-master-fähigen UARTs schon 
vor einiger Zeit sehr brauchbar abgebildet.

Aber auch ADC.

Und natürlich: USB. Warum, zum Teufel, gibt es z.B. keinen 1284P mit 
USB?

> Sind sie auch so.

Mit einem kleinen Facelifting bezüglich o.g. Peripherie wären sie es 
noch sehr viel länger...

> Was für eine Innovation . . .

Auch wenn du das vermutlich ironisch gemeint hast: na klar ist ein 
Hardware-Multiplier für viele Aufgaben, in denen Signalverarbeitung eine 
Rolle spielt zumindest eine erhebliche Erleichterung, in vielen Fällen 
macht sie die Sache sogar überhaupt erst möglich.

Klar, bei deiner hochinnovativen (Achtung: auch das war pure Ironie) 
Heizungssteuerung brauchst du sie nicht unbedingt. Das ist nämlich 
lächerlicher Kinderkram, da hat man alle Zeit der Welt...

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die XMega haben schon viele feine Dinge, die man gut gebrauchen kann. 
Für BLDC z.B. fand ich AWEX sehr gut, Timerverkettung mit Eventsystem 
muss man erstmal kapieren, ist dann aber ein 'Fire-and-Forget' und die 
DMA ist auch recht praktisch und ist erst beim STM32 wieder brauchbar 
erschienen.

Die Chipkosten fand ich halt immer etwas hoch, was fürs Hobby wurscht 
ist, aber nicht für die kommerziellen Anwender.

Autor: Telefonsprengung (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Warum einen XMEGA einsetzen?

ATXMEGA32D4-MHR : Digikey 2,48€
ATSAM3S1AB-AU : Digikey 2,46€

Ich als Atmel-Kunde, der mehr Leistung benötigt, würde mir natürlich 
auch den SAM3 ansehen.

Der Atmel-Verkäufer wird sich dann nicht die Mühe machen, und versuchen, 
mir den ATXMEGA aufzuschwatzen.

Will heißen:
Der Verdacht liegt nahe, dass der ATXMAGA ist an der hausinternen 
Konkurrenz gescheitert ist.

Autor: c-hater (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Peter D. schrieb:

> Was soll daran ein Vorteil sein, daß lange dauernde unkritische
> Interrupts alle zeitkritischen um ihre maximale eigene Laufzeit
> verzögern können?

Das tuen sie doch garnicht. Wenn man nur die ISR sinnvoll implementiert. 
Ein kleines sei() an der richtigen Stelle "löst" das Problem (reduziert 
es zumindest auf die Häfte des Interrupt-Frame und die wirklich 
unumgänglich unter Interruptsperre auszuführenden Aufgaben der ISR)...

Wenn das nicht reicht (das kommt schonmal vor) hat man immer noch die 
Möglichkeit, ein priorisierbares Interruptsystem per Software zu 
schaffen. Das ist garnicht so schwer, wenn man weiss, was man tut. 
Leider aber relativ teuer. Deswegen eher selten wirklich eine Lösung, 
ich habe in meiner ganzen Sammlung nur eine Sache gefunden, wo dieser 
Ansatz die Lösung war, um das scheinbar Unmögliche möglich zu machen...

> Im Gegenteil, daß kann sehr häßliche Seiteneffekte haben, die nur selten
> auftreten und daher sehr schwer zu debuggen sind.

Nö. Schwer zu debuggen sind nur Sachen, bei denen der User nicht weiss, 
was er tut. Wenn man erstmal ein ein "inneres Modell" von 
"Nebenläufigkeit" hat, fällt es einem nicht schwer, sowas zu debuggen.

Nur leider ist die Konzentration auf den ganzen Syntax-Wahnsinn von C in 
keinster Weise dazu geeignet, ein Denkmodell für Nebenläufigkeit zu 
bilden, es hält einen im Gegenteil davon ab, weil der Focus auf den 
völlig unwichtigen Blähungen der Programmiersprache und seiner 
Kontrollstrukturen liegt, statt auf den faktischen Problemen der echten 
oder Quasi-Nebenläufigkeit.

Asm rules.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Telefonsprengung schrieb:

> Ich als Atmel-Kunde, der mehr Leistung benötigt, würde mir natürlich
> auch den SAM3 ansehen.

Ich nicht.  Spätestens beim Pinout verzweifelst du … da scheint
jemand einen sehr guten Würfel gehabt zu haben. :-o  (Sowas findet
man aber auch bei STM, das scheint keine Atmel-Eigenheit zu sein.)

Ich würde mir, wenn ich das brauche, für den unteren 32-Bit-Bereich
eher die diversen Cortex-M0+ ansehen (SAMD21 & Co.), für den oberen
Cortex-M4 (SAM4) oder M7 (SAM7).

> Der Verdacht liegt nahe, dass der ATXMAGA ist an der hausinternen
> Konkurrenz gescheitert ist.

Nö.

Die ARM-Konkurrenz war sicher ein Grund, aber die hauseigene nicht
so sehr.  Die hatte Atmel jahrelang arg vernachlässigt, bis sie
dann mit dem SAMD21 eine ziemliche Aufholjagd gestartet haben.

Der Xmega ist deshalb nicht so groß rausgekommen, wie man sich das
gedacht hatte, weil zwischen dem Zeitpunkt seiner Konstruktion (da
war er noch ganz modern) und dem der tatsächlichen Marktreife eine
so lange Zeit lag, dass dann tatsächlich kaum noch jemand große
Controller mit nur 8 Bit (und vor allem mit nur 16 Bit Adressraum)
haben wollte.

Autor: m.n. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Wenn das nicht reicht (das kommt schonmal vor) hat man immer noch die
> Möglichkeit, ein priorisierbares Interruptsystem per Software zu
> schaffen. Das ist garnicht so schwer,

Es ist sogar ganz einfach, aber nur eine Notlösung mit ein paar 
Kompromissen und in C nicht sonderlich schnell.
Selbst der uralte 8051 war da deutlich eleganter. In dieser Beziehung 
waren die AVRs schon bei der ersten Ausführung (AT90S1200 mal außen vor 
gelassen) nicht mehr zeitgemäß.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
m.n. schrieb:
> Selbst der uralte 8051 war da deutlich eleganter.

Er war ja auch viel langsamer, weshalb man das Problem deutlich
häufiger hatte.

Ich kann mich jedenfalls gerade an keine Situation erinnern, bei der
ich auf dem AVR priorisierbare Interrupts schmerzlich vermisst hätte.
Mittlerweile benutze ich beruflich vorrangig ARMs, die haben sowas:
wirklich benutzen müssen haben wir das aber auch noch nicht.

Autor: gh (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Früher gab es einen Begriff für Alleskönner: Eierlegende Wollmilchsau. 
Der Nachteil von zehn mal so vielen Registern im Vergleich zum ATmega 
ist eine um den Faktor hundert geringere Design- Effizienz.
Komplexität eines Prozessors ist selten ein Vorteil.

Will (muß) man also schnell entwickeln, liegt der Xmega auf dem 
vorletzten Platz, gefolgt nur noch von den ARM (CM3/CM4). Ganz vorn aber 
stehen für den Mann mit Hummeln im Hintern der ATmega328 und der 
ATmega32U4 - wenn man diese als Mini  bzw. Micro auf der Arduino-IDE 
schnitzt. Oder die CM3/CM4, die sich auf vergleichbar einfachen IDEs 
entwickeln lassen (mbed, Embitz...).

Mich überzeugten am Xmega vor Jahren die saubere Pinsortierung, der 
schnelle 12-Bit ADC (2MHz) und der CPU-Takt von 32 MHz. Noch heute aber 
graut mir vor dessen Komplexität. Unter einem Mannjahr ist (ohne 
Vorkenntnisse) kein Projekt fertig.

Gleich welcher Prozessor, der Flash läßt sich maximal mit 40 MHz lesen 
(meist nur mit 20 MHz). Was nutzt mir also ein ARM, der mit 180 MHz 
läuft? Nichts. Falls er nicht mit sich selbst beschäftigt ist, zieht er 
NOPs. Er könnte nur dann schneller als ein Xmega sein, wenn das ganze 
Programm im Cache-RAM liefe. Oder wenn ich Bild- oder Audio-Daten im RAM 
verarbeite. Dafür aber sind auch CM3/CM4 etwas schwach.

Atmel könnte bei mir punkten, wenn man einen schnellen 24-Bit ADC 
(>192kHz) in einem ATmega32U4 anbieten würde. Wenn man in der Sensorik 
arbeitet, ist es nervig, immer wieder regelbare Vorverstärker oder 
externe ADC-Baugruppen entwerfen zu müssen.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
gh schrieb:
> Unter einem Mannjahr ist (ohne
> Vorkenntnisse) kein Projekt fertig.

Was macht ihr in der Arbeit? Nasenbohren?

Autor: Toni Tester (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
gh schrieb:
> Der Nachteil von zehn mal so vielen Registern im Vergleich zum ATmega
> ist eine um den Faktor hundert geringere Design- Effizienz.

Noch nicht ganz Bingo bei mir, aber nahe dran: Ich schließe aus dem 
Kontext, "Design-Effizienz" ist das Maß für die benötigte Zeit eines 
Programmierers, um mit einem bis dato unbekannten Prozessor eine 
Anwendung zu realisieren?

gh schrieb:
> Will (muß) man also schnell entwickeln, [...]
> Ganz vorn aber stehen für den Mann mit Hummeln im Hintern [...]

Wenn es schnell gehen muss, nehmen Profis das, was sie bereits kennen, 
und lassen sich nicht auf Experimente mit neuen Architekturen ein - zu 
groß das Risiko durch "Höhere Gewalt" (eine Funktion lässt sich doch 
nicht wie geplant realisieren, Bugs im Silizium, dadurch eventuell 
erforderlicher erneuter Plattformwechsel kurz vor Serienanlauf o. ä.). 
Davon ab hängt bei Profis die Entwicklungszeit beileibe nicht primär von 
der "Design-Effizienz" ab; hier spielen ganz andere Faktoren, von der 
Projektleitung über die Systemarchitekturerstellung und das 
Anforderungsmanagement bis hin zu Test und Validierung, eine weitaus 
größere Rolle.

gh schrieb:
> Gleich welcher Prozessor, der Flash läßt sich maximal mit 40 MHz lesen
> (meist nur mit 20 MHz). Was nutzt mir also ein ARM, der mit 180 MHz
> läuft? Nichts. Falls er nicht mit sich selbst beschäftigt ist, zieht er
> NOPs.

Aha... Gut zu wissen - das werde ich meinen ARMs mal sagen, mit denen 
ich bis dato so herum spielte - offenbar wissen die das nämlich nicht 
und laufen deswegen schneller...

gh schrieb:
> Atmel könnte bei mir punkten, wenn man einen schnellen 24-Bit ADC
> (>192kHz) in einem ATmega32U4 anbieten würde. Wenn man in der Sensorik
> arbeitet, ist es nervig, immer wieder regelbare Vorverstärker oder
> externe ADC-Baugruppen entwerfen zu müssen.

Jupp, absolut sinnvoll und die mit Abstand beste Idee seit langem: Einer 
8-Bit-Architektur drei Byte (wahrscheinlich wegen Aligning eher zwei 
Worte) breite Daten aufzuzwängen, für die die Architektur im besten Fall 
max. 80 Takte Zeit zur Weiterverarbeitung hat.
Und kennt man ja aus der Praxis: Mit 80 Takten Zeit lassen sich 
umfangreiche digitale Filterarchitekturen mit drei Byte breiten Daten 
aufbauen, denn der integrierte Multiplizierer beispielsweise braucht ja 
nur zwei Takte je Operation.
Keine Ahnung, warum da noch niemand drauf gekommen ist...

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
gh, du laberst Sch...

> Der Nachteil von zehn mal so vielen Registern im Vergleich zum
> ATmega ist eine um den Faktor hundert geringere Design- Effizienz.

Welche Mikrocontroller hat mehrere hundert Register?

> Unter einem Mannjahr ist (ohne
> Vorkenntnisse) kein Projekt fertig.

Sorry, das kann ich so nicht stehen lassen. Ich (Hobbyelektroniker) habe 
meinen Mini Webserver vom ATmega644 an drei Wochenenden auf einen Xmega 
portiert. Und danach wurde das Ergebnis (von jemand anders) kommerziell 
vermarktet - für mehrere Jahre.

Wenn ich das schaffe, dann auch jeder andere, der sich ernsthaft bemüht.

> Der Flash läßt sich maximal mit 40 MHz lesen (meist nur mit 20 MHz).
> Was nutzt mir also ein ARM, der mit 180 MHz läuft? Nichts.

Du hast nicht gerade viel Ahnung von der Realität.

Die meisten ARM Controller können die nächsten Instruktionen schon 
laden, während sie mit anderen Speichern oder Berechnungen beschäftigt 
sind. Beim Cortex M3 sind damit effektiv rund 60Mio Instruktionen pro 
Sekunde drin (bei einem Flash, der nicht einmal halb so schnell ist). 
Außerdem kann man zeitkritische Programmteile ganz ohne Wait States aus 
dem RAM ausführen.

> Er könnte nur dann schneller als ein Xmega sein, wenn das
> ganze Programm im Cache-RAM liefe

Nicht könnte, sondern tun sie. Und zwar ohne großartige Klimmzüge.

> Atmel könnte bei mir punkten, wenn man einen schnellen 24-Bit
> ADC (>192kHz) in einem ATmega32U4 anbieten würde.

Das wird in Absehbarer Zeit von keinem Hersteller angeboten, weil es 
einfach unmöglich ist. Der digitale Teil würde den analogen so sehr 
stören, dass effektiv höchsten 12 Bit übrig bleiben.

Aber wenn du so schlau bist, dann bewerbe Dich doch mit Deinen Ideen bei 
einem Chiphersteller. Wenn sie gut sind, wirst du damit Reich.

Autor: John Doe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gh schrieb:
> Gleich welcher Prozessor, der Flash läßt sich maximal mit 40 MHz lesen
> (meist nur mit 20 MHz). Was nutzt mir also ein ARM, der mit 180 MHz
> läuft? Nichts. Falls er nicht mit sich selbst beschäftigt ist, zieht er
> NOPs. Er könnte nur dann schneller als ein Xmega sein, wenn das ganze
> Programm im Cache-RAM liefe. Oder wenn ich Bild- oder Audio-Daten im RAM
> verarbeite. Dafür aber sind auch CM3/CM4 etwas schwach.


So ein Unsinn. Renesas hat zum Beispiel Controller, die nativ mit 100MHz 
Flash-Zugriff arbeiten.
Aber ST&Co haben halt für sich entschieden, dass das bei den meisten 
Kunden sich nicht lohnt und daher eben entsprechende 
Prefetch-Mechanismen gebaut, die zumindest in vielen Anwendungen recht 
nah da rankommen.

Autor: mmhm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gh schrieb:
> Gleich welcher Prozessor, der Flash läßt sich maximal mit 40 MHz lesen
> (meist nur mit 20 MHz). Was nutzt mir also ein ARM, der mit 180 MHz
> läuft? Nichts. Falls er nicht mit sich selbst beschäftigt ist, zieht er
> NOPs. Er könnte nur dann schneller als ein Xmega sein, wenn das ganze
> Programm im Cache-RAM liefe. Oder wenn ich Bild- oder Audio-Daten im RAM
> verarbeite. Dafür aber sind auch CM3/CM4 etwas schwach.


Uuuuuuuaaaaaah :-(

Das ist ja eine seltsame Theorie.

Ich kenne das genauer von PIC32MX. Dort wächst die Geschwindigkeit auch 
bei >40MHz fast linear weiter, obwohl das laut deiner Theorie nicht so 
sein dürfte - das Flash verlangt über 40MHz waitstates.
Ich bin mir da ziemlich sicherm ich habs fleißig ausprobiert.

Der Grund:
PIC32 haben einen Pefetch-Cashe und lädt Code "vor" (Predictive 
instruction prefetch). Das macht die waitsatetes so gut wie wett.

Dazu kommt:
Der PC vor dem du sitzt, hat das Problem in noch viel massiverer Art. 
Das arme Ding muss vom DRAM ausführen. Hast du dir schon mal angekuckt, 
wieviele Taktzyklen so ein DDR3-Ram braucht, bis es ein Byte bei 
wahlfreiem Zugriff ausspuckt?
Genau, der würde mit ein paar hunder MHz laufen, wenn überhaupt.

Beitrag #5389376 wurde von einem Moderator gelöscht.
Autor: Josch (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
John Doe schrieb:
> gh schrieb:
>> Gleich welcher Prozessor, der Flash läßt sich maximal mit 40 MHz lesen
>> (meist nur mit 20 MHz). Was nutzt mir also ein ARM, der mit 180 MHz
>> läuft? Nichts. Falls er nicht mit sich selbst beschäftigt ist, zieht er
>> NOPs. Er könnte nur dann schneller als ein Xmega sein, wenn das ganze
>> Programm im Cache-RAM liefe. Oder wenn ich Bild- oder Audio-Daten im RAM
>> verarbeite. Dafür aber sind auch CM3/CM4 etwas schwach.
>
> So ein Unsinn. Renesas hat zum Beispiel Controller, die nativ mit 100MHz
> Flash-Zugriff arbeiten.
> Aber ST&Co haben halt für sich entschieden, dass das bei den meisten
> Kunden sich nicht lohnt und daher eben entsprechende
> Prefetch-Mechanismen gebaut, die zumindest in vielen Anwendungen recht
> nah da rankommen.

Den 100MHz Flash mit 0 wait states gibt es schon seit 2010 in Renesas 
Controllern mit eigenem Kern, 2012 folgte dann 120MHz. Keine Ahnung ob 
sich da zwischenzeitlich noch was getan hat. Aber in 8 Jahren sollte man 
schon davon gehört haben ;-)
Die neueren µC von Renesas mit Arm Kern scheinen das gar nicht zu 
brauchen, z.B. hat der S7 mit 240MHz Takt nur max. 80MHz Flashzugriff 
mit 0 Waits.
Beim S5 ist beides genau die Hälfte. Spricht dafür dass der Flash-Cache 
und sonstige Features der ARM Kerne diesen Vorsprung im Flashzugriff so 
gut kompensieren dass es sich gar nicht lohnt den schnellen Flash da 
rein zu packen.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt. Ich hatte mal einen Performance-Test mit dem ESP8266 gemacht. 
Die Taktfrequenz der CPU (80 und 160 MHz) wirkte sich direkt praktisch 
1:1 auf die Rechenleistung aus. Die Taktfrequenz des seriellen (!) 
Programmspeichers (40 und 80 MHz) sowie die Anzahl der Datenleitungen 
(1, 2, oder 4) spielte jedoch fast keine Rolle (<30% Einfluss).

Falls es jemand wissen will: Ich hatte Integer Rechenoperationen 
durchgeführt und gleichzeitig relativ wenige Daten über WLAN übertragen. 
Sicher kann man den Effekt mit einem anderen Programm vergrößern, dass 
wäre aber nicht das Szenario gewesen, für das ich mich beim Test 
interessierte.

: Bearbeitet durch User
Beitrag #5413885 wurde von einem Moderator gelöscht.
Autor: J Zimmermann (Gast)
Datum:

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

ja, wenn 8bit, dann nur XMEGA:

- die zahlreichen USARTs, TCs, u.a. braucht man zwar nicht unbedingt, 
erleichtern aber das PCB-Routen sehr
- 3 QDECs (Modellbau)
- max. 24 PWM-Kanäle, mit 8-fach Extension (256MHz)
- leistungsfähiger DMAC + ADC-Sequencer
- Waveform gen., interner Inverter und Dead-Time-Generation 
(Brücken-Ansteuerung)
- Power Reduction Register (Ähnlich Clock-Distribution beim ARM)
- INT-Prios & RoundRobin
- USART-Takt mit fract. clock gen., Quarz muss nicht mehr 2^n f haben, 
um genaue Bit-Rate zu erzeugen
- Event machine, nice: man kann rotary encoder auslesen, ohne das das 
Programm dazu etwas beitragen muss.
- Die innere Strukturierung des xmega macht m.M.n. das Programmieren 
eher einfacher, legt einem quasi gute eigene Strukturierung nahe.
Sicher 'ne ganze Menge vergessen.
Zumindest ist der xmega dem mega weit überlegen, da kommt's mir beim 
meinem "Hobby-Verbrauch" auch nicht auf ein paar Cent an.

Beitrag #5413892 wurde von einem Moderator gelöscht.
Autor: Mitlesa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
J Zimmermann schrieb:
> ja, wenn 8bit, dann nur XMEGA:

Ich gebe dir Recht, wenn alle die neuen Features der XMega-
Generation gegenüber den älteren Controllern wirklich zählen,
doch so weitreichend blickt, denkt und verwendet die Masse
der Leute offensichtlich nicht. Alles "unnötiges Zeugs".

Und Arduino für den XMega gibts auch nicht (oder doch?)  ;-)

Oh Gott, fällt mir gerade ein: man muss die Dinger ja mit
3.3V betreiben statt mit 5V. Fast ein Weltuntergang.

Beitrag #5413907 wurde von einem Moderator gelöscht.
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wenn die Xmega Controller ein Einzelstücken nicht so viel teurer als 
ATmega und STM32 wären und wenn es sie passend für Lochraster gäbe (oder 
zumindest ohne großartigen Aufpreis als Modul), dann würde ich ich sie 
auch gerne verwenden.

Aber ich sehe hier nur die umfangreiche Peripherie eines 32 bitters 
kombiniert mit einer schon fast veralteten 8bit CPU zu einem 
Schweinepreis.

CAN, Ethernet und USB Host fehlen immer noch, oder?

: Bearbeitet durch User
Autor: Bernd S. (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Hobbybereich sehe ich gar keinen Grund von 8-Bit abzuweichen.

Klar, um zum Mond zu fliegen brauchte man zwar einen 16-Bit Prozessor
( 14-Bit rein für Daten ) mit 1024kHz, aber dies ist heute sicherlich 
auch mit einem ATxmega zu bewerkstelligen der " nur " ein 8-Bitter ist.

Was ein µC vermag, liegt sowieso zum größten Teil am Programmierer.
Ich bin auf jedenfall begeistert was da drin steckt. Besser sein Wissen 
hier auszubauen ( Vom Tiny, zum Mega bis zum Xmega ), als fast ganz von 
vorn anzufangen.

Zugegeben der ATxmega ist wohl in den Foren nicht sehr verbreitet, aber 
ich denke das liegt daran, das die meisten Hobbyisten schon mit dem 
ATmega vollauf zufrieden sind ;-)

https://de.wikipedia.org/wiki/Apollo_Guidance_Computer


Bernd_Stein

Autor: Carl D. (jcw2)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Wenn die Xmega Controller ein Einzelstücken nicht so viel teurer als
> ATmega und STM32 wären und wenn es sie passend für Lochraster gäbe (oder
> zumindest ohne großartigen Aufpreis als Modul), dann würde ich ich sie
> auch gerne verwenden.
>
> Aber ich sehe hier nur die umfangreiche Peripherie eines 32 bitters
> kombiniert mit einer schon fast veralteten 8bit CPU zu einem
> Schweinepreis.
>
> CAN, Ethernet und USB Host fehlen immer noch, oder?

Die Peripherie als MemoryMapoed-Struktur ist zwar schön, braucht aber 
Unterstützung durch eine CPU, die genügend Pointer-Register hat.
Da gibt es dann welche, die 14(15/16) 32-Bit-Pointer mitbringen, mal von 
dem Adressierungsarten gar nicht geredet, wärend AVR8(X) gerade mal 
3(2,5) hat.
Ein ARM zeigt auf eine Adresse und kann damit via immediate offset 
+-4096 Bytes ansprechen. Ein AVR "Pointer-arithmetisiert" sich dabei zu 
Tode.

Und was auch im Hobbybereich (ich) zählt: die CPU bedient der Compiler, 
die Peripherie muß ich selber verstehen. XMega kann ich auch gleich als 
STM32 lernen, da ist vom Aufwand kein großer Unterschied. Und dann noch 
die 3€-China-Boards. Gibt's für "AVR ohne X" und für STM32F103. Da kann 
man sich je einen 10er Pack zum verbasteln hinlegen.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Welche Mikrocontroller hat mehrere hundert Register?

LEON3 und LEON4 von Gaisler. Haben 'ne SPARC V8 Architektur. 8 
Registersätze a. 32 Register. Und da drauf kommen noch die 
Floatingpoint-Register :)

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
> Stefanus F. schrieb:
>> Welche Mikrocontroller hat mehrere hundert Register?
>
> LEON3 und LEON4 von Gaisler. Haben 'ne SPARC V8 Architektur. 8
> Registersätze a. 32 Register. Und da drauf kommen noch die
> Floatingpoint-Register :)

Von denen aber der Programmierer zu einer Zeit nur 32 sieht. Der Rest 
ist eher eine Art Stack-Cache.
Sozusagen das IT-Equivalent zu deinem Nick. Kompliziert gebaut, aber 
heute nicht mehr wirklich schneller.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob 8, 16, 32 oder 64bit ist mir ziemlich egal, denn der C Compilier 
abstrahiert das sehr gut weg. Ich interessiere mich eher für die 
Peripherie, mit deren Programmierung ich mich auseinander setzen muss.

Die ist beim Xmega zwar deutlich umfangreicher und besser sortiert, als 
bei 8bit AVR, aber der hohe Preis und die schlechte Verfügbarkeit von 
Lochraster-tauglichen Chips/Boards schreckt mich ab.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
Welche Mikrocontroller hat mehrere hundert Register?


Gefragt war nach einem uc mit mehreren hundert Registern.

Carl D. schrieb:
> Von denen aber der Programmierer zu einer Zeit nur 32 sieht. Der Rest
> ist eher eine Art Stack-Cache.

Im Normalfall ja. Aber du könntest ihn anders verwenden, allerdings nur 
in Assembler. Ein Window-Switch ist nicht "teuer" bei den Dingern.

Und in der Raumfahrt sind die Dinger immer noch völlig hip, weil sie 
strahlungsresistent und dreifach redundant hergestellt werden.
So, genug OT. :)

: Bearbeitet durch User
Autor: J Zimmermann (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
stefanus:
>schlechte Verfügbarkeit von
Lochraster-tauglichen Chips/Boards schreckt mich ab.

Lochraster-taugliche Chips gibts m.E. vom XMEGA garnicht. Gute E-Boards 
sind auch rar und nicht billig (~20Eus, mattairtech z.B.) Adapter 
(TQFP100,..64,..44,..32) sind ja mittlerweile erschwinglich (China, 
ANVILEX). Das Löten ist so schwer nicht - man muss es halt mal probieren 
(Lupenleuchte, gute spitze Pinzette, Flussmittel, Entlötlitze, Geduld). 
Hab mir ein eigenes Board designed (XMEGA32A4, opt. 4 Leds, opt. FT230X, 
s. Bild) Der QFN-Chip lötet sich einfacher als befürchtet, mittlerweile 
laufen 4 dieser Boards ohne Ausfall.
mfg

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ja, mit Adapter-Boards könnte ich sie sicher verwenden. Allerdings 
bekomme ich Boards mit STM32 für weniger als 2 Euro bereits fertig 
gelötet. Und die sind ohne weiteren Aufpreis auch noch viel schneller.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute: der Thread ist von 2010!

Es hat bloß einer die Leiche ausgebuddelt …

Autor: J Zimmermann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stefanus:
>bekomme ich Boards mit STM32 für weniger als 2 Euro bereits fertig
gelötet.
Was machst Du dann damit - vielleicht gibt's das ja auch schon fertig 
...
mfg

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Leute: der Thread ist von 2010!
>
> Es hat bloß einer die Leiche ausgebuddelt …

Ist halt ein zeitloser Thread! ;-)

Aber interessanter Hinweis ... Dann gab es also vor 8 Jahren schon das 
Gefühl, die XMegas wären nicht mehr in?

Die aktuelle Einschätzung ist da wohl nicht anders.

Hatte Atmel (bzw jetzt Microchip) das Debugging-Interface für AVR und 
XMEGA öffentlich gemacht?

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Was machst Du dann damit - vielleicht gibt's das ja auch schon fertig

Da hast du wohl Recht, das war kein hartes Argument. Die meisten Sachen, 
die ich im Rahmen meines Hobbies baue, brauche ich nicht wirklich oder 
kann man auch fertig kaufen.

> Aber interessanter Hinweis ... Dann gab es also vor 8 Jahren
> schon das Gefühl, die XMegas wären nicht mehr in?

Ja. Ich hatte schon damals das Gefühl, dass sie eine Marktlücke zu 
füllen versuchen, die niemand benötigt. So ging es mir auch beim 
Raspberry Pi (nix halbes nix ganzes) doch bei dem lag ich gehörig 
daneben. Der verkauft sich ja wie warme Brötchen.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
>> Aber interessanter Hinweis ... Dann gab es also vor 8 Jahren
>> schon das Gefühl, die XMegas wären nicht mehr in?
>
> Ja. Ich hatte schon damals das Gefühl, dass sie eine Marktlücke zu
> füllen versuchen, die niemand benötigt. So ging es mir auch beim
> Raspberry Pi (nix halbes nix ganzes) doch bei dem lag ich gehörig
> daneben. Der verkauft sich ja wie warme Brötchen.

Denk dir nichts ... sowas passiert ... Hatte 2011 keine Bitcoins 
gekauft, weil ich fest der Meinung war, die Skalierungsprobleme sind so 
gewaltig, dass die sehr bald an die Wand fahren ... Doch bei dem lag ich 
gehörig daneben xD

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich hatte schon damals das Gefühl, dass sie eine Marktlücke zu füllen
> versuchen, die niemand benötigt.

Zum Zeitpunkt ihres Designs waren die Dinger nicht schlecht, aber sie
haben viel zu lange bis zur Marktreife gebraucht.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Stefanus F. schrieb:
>> Ich hatte schon damals das Gefühl, dass sie eine Marktlücke zu füllen
>> versuchen, die niemand benötigt.
>
> Zum Zeitpunkt ihres Designs waren die Dinger nicht schlecht, aber sie
> haben viel zu lange bis zur Marktreife gebraucht.

Zu der Zeit hatte Atmel schon lange ARM7-Derivate im Programm ... Erst 
die klassischen ARM7TDMI und dann später die SAM7.

Damals gab es schon keinen Grund, die XMegas zu entwicklen :)

Autor: ohje78 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David .. schrieb:
> http://de.wikipedia.org/wiki/Quantensprung#Umgangssprache

Das verstehen viele einfach nicht. Wenn man einen großen Fortschritt als 
Quantensprung bezeichnet dann bezieht man sich nicht auf die 
physikalische Größe eines echten Quantensprungs sondern auf seine 
elementare Natur.

Wenn etwas grundlegend anders oder besser ist als sein Vorgänger dann 
kann der Ausdruck Quantensprung gebraucht werden um zu beschreiben dass 
sich etwas elementar verändert hat.

Eine elementare Veränderung bezeichnet auch eine große Veränderung, 
obwohl Elemente eigentlich die beliebig kleinen Bestandteile größerer 
Einheiten bezeichnen. Also ist eine elementare Veränderung eine sehr 
kleine Veränderung? Nein, es bezeichnet eine tiefgreifende Veränderung, 
genau wie der Ausdruck Quantensprung.

Autor: Josch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Leute: der Thread ist von 2010!

Mittlerweile ist die Hälfte des Threads von 2018.

> Es hat bloß einer die Leiche ausgebuddelt …

Ja, könnte man auch als späten, verlängerten Nachruf auf einen Untoten 
sehen ;-)

> Zum Zeitpunkt ihres Designs waren die Dinger nicht schlecht, aber sie
haben viel zu lange bis zur Marktreife gebraucht.

Also ich sehe da in der Liste der tollen Features nichts was es nicht 
damals auch schon lange von anderen gegeben hätte, allerdings kaum auf 
einem 8-Bitter.
Obwohl- R8C hatte glaub ich einen 16Bit Kern und eine 8Bit 
Speicheranbindung.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mampf F. schrieb:
> Zu der Zeit hatte Atmel schon lange ARM7-Derivate im Programm

Dinosaurier, verglichen mit Cortex-M.

So richtig Konkurrenz in dieser Richtung ist eigentlich erst mit dem
Schwenk auf die Cortex-M0+ innerhalb von Atmel entstanden.

Josch schrieb:
> Also ich sehe da in der Liste der tollen Features nichts was es nicht
> damals auch schon lange von anderen gegeben hätte

Das Event-System war wohl in der Tat neu.  Man hätte es aber nach
den vielen Verzögerungen bei der Markteinführung wohl besser gleich
auf einen Cortex-M umpflanzen sollen.

Atmel war aber eben auch kein einheitlicher Konzern, sodass da viele
verschiedene Abteilungen jeder für sich die eigenen Zukunftsstrategien
entwickelt hat.

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.

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