Ich habe bzgl der AtXmegas recherchiert, und da wurde in diversen Foren durchgehend die Meinung vertreten, daß der Xmega nett aber ziemlich buggy ist. Diese Forenbeiträge sind alle aus dem Jahr 2010. Ist das noch immer so oder hat sich da was gebessert? Mario
Hi
>Ist das noch immer so oder hat sich da was gebessert?
Kannst du selbst nachlesen: In jedem ATXMega-Datenblatt gibt es einen
Abschnitt 'Errata'.
MfG Spess
> da wurde in diversen Foren durchgehend die Meinung vertreten, > daß der Xmega nett aber ziemlich buggy ist. keine Ahnung, was die meinen. Ich habe einen embedded Webserver vom Atmega644 auf Xmega128D3 portiert. Dabei bin ich auf keinerlei probleme gestoßen. Bei Xmega schätze ich diese Verbesserungen gegenüber Atmega: - Volle Taktrate bei 3,3V - R/C Oszillator ist für serielle kommunikation ausreichend stabil - I/O Ports haben neben Pull-up's auch Pull-Down's - Die I/O Ports werden über Strukturen angesprochen, und zwar alle gleich. Somit kann man ohne großartige Klimmzüge den namen eines Port bei Funktionsaufrufen übergeben, die sämtliche Register des Portes nutzt. Dem Gegenüber stehen für mich zwei Nachteile: - Der Preis (da kann ich gleich einen ARM nehmen) - Nicht im PDIP Gehäuse verfügbar (ich löte fast ausschließlich auf Lochraster). Aber Bugs habe ich noch keine gesehen. Die sind sicher irgendwo zusammenhängend dokumentiert, schätze ich.
So buggy ist der garnicht. Nur war man von Atmel nicht gewohnt das die Teile genauso schlecht funktionierten wie bei anderen Herstellern durchgehend üblich. Ich habe mit einem sehr frühen D3 gearbeitet und der ADC war ein wenig 'merkwürdig' aber trotzdem benutzbar. Bei den aktuellen Typen stehen an genau der Stelle die damals nicht funktioniert hat die Einschränkungen die man in Kauf nehmen muss. Hätte ich das vorher gewusst wäre das auch kein Probem gewesen. (Unterschiedliche Möglichkeiten bei single ended / differential Messungen) Manchmal war es nur die schechte Doku die Problem gemacht hat. Mit den 'bugs' ist der noch flexibler einsetzbar als manch alt gedienter Chip ohne bugs. Die 'verwaltung' der chip hardware ist unglaublich übersichtlich und folgt einem immer wiederkehrenden Muster durch die gesammte Xmega Familie was Typenwechsel sehr einfach macht. Problematisch ist manchmal das was Atmel an Tools und Software abliefert. Das Studio 6 ist so *rschlahm mit seinem Visual Studio Unterbau das es schmerzt. Programmer / Debugger die diesen und jenen Chip nicht mögen, oder Breakpoints die unzuverlässig getriggert werden, sowas eben. Wenn ich sehe was mir andere Hersteller zumuten ist das nicht schlechter, aber eben nicht so gut wie es bei Atmel mal war. Die AVR Freaks wollen überwiegend erst wechseln wenn der letzte AVR vom Band läuft. Die PIC Fans können mit der 'jeder Chip ist anders' Doktrin von Mikrochip gut leben und die STM32 Groupies findes sowieso alles andere blöd. Die Xmegas kamen erst so spät und mit anfänglichen Problemen das sie nun einen schweren Stand haben neue Freunde zu finden. Die Xmegas gehören zu dem besten was der 8bit Markt zu bieten hat. Sie sind schnell und übersichtlich und bieten eine sehr flexible Hardware mit vielen Schnittstellen. Es sind nicht die billigsten und haben nicht die höchste Rechenpower, bieten aber einen ausgewogenen Mix aus beidem. Die Hardware + Event System erledigt vieles autonom und Speicherschonend was man bei anderen zu Fuß erledigen muß. Ich setzte trotzdem oft was anderes ein was kleiner oder billiger ist, aber wenn es um die Leistungsklasse 'großer AVR' geht ziehe ich die Xmegas dem AVR oder diesen verwurstelten 'von hinten durch die Brust ins Auge' ARM Typen vor.
Fehlerbehaftet waren vor allem die Xmega###A#. Die solltest Du nicht verwenden, sondern auf die bereinigten Xmega###A#U zurückgreifen, auch wenn Du USB nicht brauchst. fchk
Frank K. schrieb: > Fehlerbehaftet waren vor allem die Xmega###A#. Die solltest Du nicht > verwenden, sondern auf die bereinigten Xmega###A#U zurückgreifen, auch > wenn Du USB nicht brauchst. Die U-Varianten sind vor allem deutlich günstiger als die älteren Controller (trotz Zusatz-Peripherie wie USB und manchen kleinenen Ergänzungen).
Bei den Xmega-Verbesserungen hast du die mächtigsten / leistungsfähigsten vergessen: - 4 DMA-Einheiten (mit Eventansteuerung) - Das Eventsystem. - Timer haben 2 / 4 mächtige Capture-/Compareeinheiten - AWEX: Halbbrücken-Ansteuerung mit einstellbarer Totzeit - und etliches mehr Z.B. kann man unabhängig vom sonstigen Programm: - mit einem Timer eine DMA anstoßen, die aus einer Sinustabelle die Werte auf den DAC rausschreibt => Sinusgenerator - mit einem Timer 3 unabhängige PWM-Ausgänge / betreiben => 3-Phasen-Halbbrücken!
Michel schrieb: > Z.B. kann man unabhängig vom sonstigen Programm: > - mit einem Timer eine DMA anstoßen, die aus einer Sinustabelle > die Werte auf den DAC rausschreibt => Sinusgenerator Wie hier beschrieben, kann das aber recht lange dauern und ist auch nicht Jitter frei: Beitrag "Re: Xmega Pin Zustand effizient spiegeln" 2,6µs bei 32MHz ist ziemlich langsam.
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.