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
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.
Natürliches Wachstum folgt immer einer e-Funktion. Noch sind wir bei t=0 ;-)
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
Angehängte Dateien:
-
xmega_tme.png
78 KB
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.
Hi Dennis! Welche Cortex-M3er verwendest du? - Das sind doch die ARM7-Nachfolger. Habe ich recht? Schöne Grüße, Kaspar
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.
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
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.
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
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...
> 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.
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.
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
> 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
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.
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
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.
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.
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
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
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.
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
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.
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
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?
> 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
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
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
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.
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.
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
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...
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
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...
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.
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.
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.
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.
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.
Luk4s K. schrieb: > Warum hat hier eigentlich noch niemand die MSP430 erwähnt? Vielleicht weil das Thema die XMegas sind?
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.
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
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
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.
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.
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...
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
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
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
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.
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.
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.
Ach ja auch noch: Auch wenn die die normalen vom Markt nehmen, würde ich ehr erst zu den 8tern umsteigen: Statt Mega8 -> Mega88 ...
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
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.
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.
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.
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
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!
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.
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.
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.
Meinst Du, daß das nach über sieben Jahren noch irgendwen interessiert?
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.
Beitrag #5264216 wurde vom Autor gelöscht.
Es sind nur noch zwei ATXMega gelistet. Schade eigentlich, sieht aber so aus, als wären sie definitiv am Ende.
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...
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.aspx?branchID=30047
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.
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.
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.aspx?branchID=30047 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...
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?
@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.
Die xmegas wird es ganz einfach noch so lange geben wie sie a) Gewinn einbringen und b) eine Verjährung von Nachlieferung eintritt.
Norbert T. schrieb: >> Hier erscheinen nur noch zwei Typen: >> >> https://www.microchip.com/paramChartSearch/chart.aspx?branchID=30047 > > > 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!
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.
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.
@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 . . .
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.
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.
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.
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.
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!
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
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.
@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.
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...
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.
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.
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.
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.
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äß.
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.
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.
gh schrieb: > Unter einem Mannjahr ist (ohne > Vorkenntnisse) kein Projekt fertig. Was macht ihr in der Arbeit? Nasenbohren?
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...
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.
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.
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.
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.
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.
Beitrag #5413885 wurde von einem Moderator gelöscht.
> 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.
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.
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?
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
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.
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 :)
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
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.
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
Angehängte Dateien:
-
xmega_board.jpg
190 KB
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
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.
Leute: der Thread ist von 2010! Es hat bloß einer die Leiche ausgebuddelt …
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
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?
> 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.
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
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.
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 :)
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.