...oder sind da noch diverse Bugs enthalten? Speziell bei den seriellen Schnittstellen.
Rainer S. schrieb: > ...oder sind da noch diverse Bugs enthalten? > > Speziell bei den seriellen Schnittstellen. Wir setzen (unter anderem) die XMegas in größeren Stückzahlen in kommerziellen Projekten ein. Bei den seriellen Schnittstellen (USART, SPI, TWI) kenne ich bis jetzt keine Probleme, aber ansonsten solltest du einfach einen Blick ins Errata Sheet werfen.
Ich seh keinen einziges Einsatzgebiet für die XMegas. Vielleicht kann es mir ja jemand erklären. Braucht man mehr als Standard-AVR, ist man eigentlich immer mit dem STM32 besser bedient. Insbesondere beim RAM ist Atmel wiedermal verdammt knausrig gewesen. Bei in der Peripherie-Ausstattung vergleichbaren Controllern ist eigentlich immer (hab noch nicht bis ins letzte verglichen) der STM die preiswertere Alternative. Verfügbarkeit ebenfalls besser, mehr Rechenpower/Flash/RAN gibts als Zugabe auch noch. Also wofür?
Naja, ich hätte da schon ein Einsatzbereich. Die XMEGAs gibt es z.B. mit 8 (ACHT) UARTs !!!
>Bei in der Peripherie-Ausstattung vergleichbaren Controllern ist >eigentlich immer (hab noch nicht bis ins letzte verglichen) der STM die >preiswertere Alternative. Verfügbarkeit ebenfalls besser, mehr >Rechenpower/Flash/RAN gibts als Zugabe auch noch. >Also wofür? Seh ich genauso. Man muss sich sowieso komplett umstellen um sich mit den ATXMEGA vertraut zu machen. Die Zeit investiert man besser in einen ARM.
Man darf aber nicht vergessen, dass die Xmegas 8-bitter sind! Sicherlich nicht ganz billig, zugegeben. Aber kennt ihr einen anderen µC der PWM mit 128MHz kann (die neuen USB-Typen sogar 256MHz!!) ? H.joachim Seifert schrieb: > ... Insbesondere beim RAM ist Atmel wiedermal verdammt > knausrig gewesen. Für sehr speicherintensive Anwendungen würde ich auch einen 32-bitter nehmen, da braucht man eh meistens mehr Datendurchsatz...
Heiko vG schrieb: > Aber kennt ihr einen anderen µC der PWM mit 128MHz kann (die neuen > USB-Typen sogar 256MHz!!) ? könntest Du das belegen ?
Der Hauptnachteil der Xmega ist, daß es keinen freien C-Compiler gibt, der ihn adressieren kann. Der AVR-GCC kann nur 64kB von den möglichen 128MB RAM adressieren! Das sind gerade mal 0,05%. Und die 256kB Flash lassen sich auch nur mit Klimmzügen (Trampolin) nutzen. Ob kommerzielle Compiler 24- und 32-Bit Adressierung unterstützen, weiß ich nicht. Peter
@crazyhorse/holger/Peter Die Frage war aber doch, ob der XMEGA einsetzbar ist - und nicht, ob es vielleicht etwas "besseres" gibt. (Darunter versteht sowieso jeder etwas anderes)
Ja, ist bei uns hier im Einsatz. Verwendet wird der ADC um mehrere Messwerte auszulesen die danach verarbeitet werden. Die Messwerte gehen dann über den DAC wieder raus und werden analog in 4-20mA gewandelt. UART als Debug. Sehr schönes Teil. Mit AVRStudio5 und dessen Module einfach herrlich zu programmieren.
Detlev T. schrieb: > Die Frage war aber doch, ob der XMEGA einsetzbar ist - und nicht, ob es > vielleicht etwas "besseres" gibt. Doch das ist auch berechtigt zu diskutieren ob es was besseres gibt, finde ich. Ich bin da noch am zweifeln. Auf der einen Seite kann das vorhandene Wissen und die bereits erstellte Software weitestgehend weiterbenutzt werden. Auf der anderen Seite die Nachteile und die Grenzen des 8 Bit Controllers. Habe auch schon überlegt einen ARM einzusetzen. Da ist aber dann erst mal wieder mehrwöchiges einarbeiten angesagt.
>Aber kennt ihr einen anderen µC der PWM mit 128MHz kann ?
Sicher. Schau dir mal den DSPic30F2023-30I an. Der kann mit einer 32fach
PLL bis 480MHz gehen. Verbraet dafuer aber rabiat was an Strom ...
220mA@5V
Rainer S. schrieb: > Doch das ist auch berechtigt zu diskutieren ob es was besseres gibt Dafür gibt es erstens andere Threads und zweitens gibt es ein absolutes "besser" ohnehin nie. Es kommt immer auf die Nebenbedingungen an. Die XMegas sind recht brauchbar für Leute mit AVR-Hintergrund, wo der Handlungsdruck noch nicht so groß ist, dass man sich eine grundsätzlich andere Architektur antun will/muss. Ich bin jedenfalls bislang recht zufrieden damit. Jemand mit ARM- oder PIC-Erfahrung kann man hingegen nur von den XMEGAs abraten, das bringt denen nix. Gruß, DetlevT
>Aber kennt ihr einen anderen µC der PWM mit 128MHz kann...
Die Frage ist, ob man das wirklich braucht. Ich kann auch 16 bit PWM
erzielen mit nur 16MHz Clock und trotzdem mit einer Frequenz von 60kHz
arbeiten. Das Zauberwort ist "Fraktionale Frequenz". Dabei laesst man
sich 256 Perioden Zeit zum Umschalten.
Wenn hier jemand die Frage stellt, ob man XMEGA nehmen sollte, eindeutig Nein. Ich nutze seit Jahren nur noch den STM32 und bin damit mehr als zufrieden. Ich habe damit endlich einen Prozi gefunden, der (mir) keine Wünsche offen lässt. Als ich den in der Firma einführte war erst mal das große "das ist doch neu und braucht viel Zeit, kenn ich nicht und so". Schlussendlich hat sich das aber wieder durch die vielen Projekte und die besseren Möglichkeiten Amortisiert und niemand möchte mehr zurück zum 8-Bitter (ATMega), selbst der Einkauf ist mit dem Preis zufrieden denn die 8-Bitter sind auch nicht günstiger. Eingesetzt werden z.B. STM32F103RC..STM32F103ZE. Einmal musste ich sogar aus einem Projekt den dsPIC raus schmeißen und durch einen STM32 ersetzen weil der PWM zu schlecht war (geforderte Auflösung vom Kunde). PS: Mit der Entwicklungsumgebung für den STM32 kann man in der Regel auch alle Prozessoren verwenden die einen ARM Cortex-M3 drin haben und ist somit nicht Herstellergebunden. Die GCC Compiler können zudem auch ARM7 und ARM9 und andere ARM's. Somit ist die Investition in die Entwicklungswerkzeuge garantiert keine Einbahnstraße.
Markus Müller schrieb: > Wenn hier jemand die Frage stellt, ob man XMEGA nehmen sollte, eindeutig > Nein. Quatsch mit Soße. Engstirnig noch dazu. Die Entscheidung musst Du schon den Anderen überlassen. Produktionsgeeignet sind sie allemal und das war die Frage. Selbst die verbuggten PICs werden seit Jahren, wenn nicht seit Jahrzehnten verbaut. Wenn es einen Workaround gibt, der ein nichtfunktionierendes Modul zur Zufriedenheit des Kunden behandelt, wo ist dann das Problem?
seppl schrieb: > Verwendet wird der ADC um mehrere Messwerte auszulesen die danach > verarbeitet werden. Und hast Du mal den ADC ausgemessen? Ist er wirklich so schlecht, wie es in den Errata steht? Welchen konkreten Xmega nimmst Du? Und welchen ADC-Modus und Gain? Wie weit zappelt der ADC von einer Messung zur nächsten? Ich hatte mal für ein Projekt den XMega überlegt, weil ich 12 Bit brauchte. Habs dann doch aber wegen der Errata mit nem ATtiny84 + externen echten 12Bit-ADC gemacht. Peter
Peter Dannegger schrieb: > Ist er wirklich so schlecht, wie es in den Errata steht? Bei den "alten" XMEGAs ja. Bei den neuen mit USB ist das komplette analoge Frontend überarbeitet und funktioniert den Spezifikationen entsprechend.
Der XMega hat durchaus seine Berechtigungen, auch wenn natürlich der Sprung zum 32bitter immer kleiner wird, aber mal der Reihe nach: Wir haben sehr viel Erfahrung sowohl mit den AVR-Controllern als auch den STM32, so dass ich vielen Punkten von Markus durchaus zustimmen kann, immerhin hat er auch STM32-Boards von uns höchstwahrscheinlich auf dem Tisch... ;-) Dennoch gibt es Bereiche, wo mir die XMega eher zusagen: Wir haben zum Beispiel viele Projekte, wo wir mindestens vier oder fünf serielle Schnittstellen benötigen. Die hat der XMega im kleinsten Gehäuse mit drin, bei den STM32 muss man hingegen schon einen deutlich größeren Controller einsetzen. Der ist dann aber auch wieder deutlich teurer und die ungenutzte Peripherie zahlt mir nun mal niemand. Daneben brauchen wir die Hardware-AES-Einheit des XMega, auch das ist bei den 32bittern alles andere als weit verbreitet. Die Einarbeitungszeit spricht natürlich ebenso für den XMega und damit meine ich gar nicht unbedingt meine Einarbeitungszeit - ich kann inzwischen genauso gut mit XMega wie STM32 umgehen. Für neue Mitarbeiter oder Werksstudenten gilt das aber nicht unbedingt. Die XMega haben ihre Berechtigung und ihre Einsatzgebiete, auch wenn ARM ihnen in letzter Zeit viele Gebiete abgeknöpft hat. Aber zurück zur Ursprungsfrage: Ja, der XMega ist bedingungslos auch für größere kommerzielle Projekte geeignet. Die Errata halten sich in Grenzen bzw. wie Knut schon schrieb, sind sie bei den neueren Revisionen ausgebügelt wurden.
Knut Ballhause schrieb: > Bei den neuen mit USB ist das komplette > analoge Frontend überarbeitet und funktioniert den Spezifikationen > entsprechend. Dann müßten sie ja nur noch beschaffbar sein. Da wir keine millionen Stück abnehmen, können wir nur MCs nehmen, die auch Lagerware sind, möglichst bei mindestens 2 Distributoren. Das scheint aber nicht der Fall zu sein. Ich bin da bei Atmel lieber etwas vorsichtig. Ich nehme möglichst nur MCs, die bei Farnell Lagerware sind. Farnell ist ein guter Indikator für leichte Beschaffbarkeit. Daher sind die USB-Xmega für mich derzeit keine Option. Und die alten sind mir zu buggy. Peter
Peter Dannegger schrieb: > Dann müßten sie ja nur noch beschaffbar sein. http://www.ineltek.com/de/news/Atmel_AVR_XMEGA_USB.php
Hagen Re schrieb: > Heiko vG schrieb: >> Aber kennt ihr einen anderen µC der PWM mit 128MHz kann (die neuen >> USB-Typen sogar 256MHz!!) ? > > könntest Du das belegen ? Hallo Hagen, der XMega hat für jeden(!) Timer eine HIRES-Extension. Mit der ist es möglich den vierfachen Prozessortakt als Counter-Clock zu nutzen. Beim USB-Xmega kommt dogar noch ein Faktor 2 hinzu, da hier mit BEIDEN Flanken gezählt werden kann -> 32Mhz*4*2=256MHz. Habe ich auch schon erfolgreich ausprobiert. Es gibt einen m. E. in der Praxis nicht relevanten Nachteil: Die kleinste erzeugbare Puls-Breite für PWM beträgt nur 1/(32MHz).
oha schrieb: >>Aber kennt ihr einen anderen µC der PWM mit 128MHz kann ? > > Sicher. Schau dir mal den DSPic30F2023-30I an. Der kann mit einer 32fach > PLL bis 480MHz gehen. Verbraet dafuer aber rabiat was an Strom ... > 220mA@5V Die ds-PICs haben wirklich gute PWM-Einheiten, aber man will doch keinen Heizofen bauen ... ;-)
Knut Ballhause schrieb: > http://www.ineltek.com/de/news/Atmel_AVR_XMEGA_USB.php Papier ist geduldig! Selbst dickie-key hat sie nicht.
Glaubenskrieg, juhu! Das Wochenende ist gerettet ;)
Ich sehe grade mit Entsetzten, die Xmega haben ja gar keinen CAN. Dann sind sie für mich völlig unbrauchbar. Peter
Michael G. schrieb: > Glaubenskrieg, juhu! Das Wochenende ist gerettet ;) Nee, garnicht. Ich würde die gerne verwenden. Wenn aber meine Lieferanten nur abgemagerte Stückzahlen (wenn überhaupt) anbieten und der Preis noch recht hoch ist, warte ich lieber ab. Gerne auch 10 Jahre :-)
Heiko vG schrieb: > Hagen Re schrieb: >> Heiko vG schrieb: >>> Aber kennt ihr einen anderen µC der PWM mit 128MHz kann (die neuen >>> USB-Typen sogar 256MHz!!) ? >> >> könntest Du das belegen ? > > Hallo Hagen, > > der XMega hat für jeden(!) Timer eine HIRES-Extension. Mit der ist es > möglich den vierfachen Prozessortakt als Counter-Clock zu nutzen. Beim > USB-Xmega kommt dogar noch ein Faktor 2 hinzu, da hier mit BEIDEN > Flanken gezählt werden kann -> 32Mhz*4*2=256MHz. > > Habe ich auch schon erfolgreich ausprobiert. > Es gibt einen m. E. in der Praxis nicht relevanten Nachteil: Die > kleinste erzeugbare Puls-Breite für PWM beträgt nur 1/(32MHz). Der maximale PWM Takt der Counter ist und bleibt 32MHz = Clk_CPU. Nur die untersten 2 Bits diesere Counter werden durch den HiRes mit x4 Takt bedient. Damit ist die Frequenzauflösung dieser Counter immer noch nur 32MHz. Die Genauigkeit der Flanken, sprich die Pulsbreite der PWM kann mit 4-facher Genauigkeit eingestellt werden, = 7.8ns. Es sind nur 32MHz PWM Zähler und keine 128MHz ! Gruß Hagen PS: einfacher Versuch: zeige mir die Einstellung der Zähler m it der ich an einem Pin eine 64MHz PWM ausgebe mit 50% DutyCycle = 128MHz Taktbasis des Timers.
Ok, Formulierungsfehler meinerseits! Ich wollte damit eigentlich auch nur ausdrücken, dass man sehr hohe Auflösungen (wäre das richtige Stichwort gewesen) erreichen kann, z.B. 32kHz mit ca. 12Bit Auflösung. So besser ? Gruß Xmegaman
Auf der Electronica 2010 am Atmel Stand: Frage: Wann gibt es XMega mut CAN? Antwort: Nie. Ausserdem sind die XMega Pins nicht 5 Volt tolerant.
Ohne auf technische Details zu schauen, seit dem Debakel zur Nichtlieferbarkeit von AVR32 und der damit nicht vorhandenen Informationspolitik: Nie wieder Atmel, einmal Geld und Kunden verlieren ist genug.
Uwe Bonnes schrieb: > Frage: Wann gibt es XMega mut CAN? > Antwort: Nie. Pluspunkt für ARM Cortex M3. Uwe Bonnes schrieb: > Ausserdem sind die XMega Pins nicht 5 Volt tolerant. Nochn Pluspunkt für ARM Cortex M3. Xmega kann man also getrost vergessen. Peter
Peter schrieb: > Nie wieder Atmel, einmal Geld und Kunden verlieren ist genug. Wer Produkte mit Evaluation-Samples entwickelt, ist aber selber dran schuld. Da dürften andere Hersteller kaum besser sein. Ich wollte kürzlich für ein Projekt die neuen CAN-AVRs einsetzen. Ich hab dann aber wegen der Verfügbarkeit doch den Oldie AT90CAN128 genommen. Ich hätte schon gerne die UARTs als gepuffertes SPI genommen (je 16Bit in einem Rutsch senden). Peter
Nix Evaluation Samples, die waren bei Digikey und Mouser verfügbar. Irgenwann waren sie weg, und es gab monatelang ohne Updates keine neuen mehr, dazu gibts auch etliche Threats in diversen Foren. Das gleiche Problem mit den FLASHs, die bis jetzt noch nicht alle wieder verfügbar sind. Wir haben auf NXP LPC23xx bzw. LPC24xx umgestellt, für unsere Produkte sind die hervorragend geeignet.
Ich hatte ähnliche Probleme mit NXP. Bei der Umbenennung von Philips in NXP gab es einen riesen Kahlschlag und Durcheinander im 8051-er Sortiment. Wir haben dann vieles auf Atmel AVR umgestellt (neue Layouts, Firmware). Die Produktion kam glücklicher Weise nicht ins stocken. Der P89C668 war auch zeitweise abgekündigt und dann doch wieder im Programm und jetzt ist er wohl entgültig abgekündigt. Glücklicher Weise gibt es von Atmel den AT89C51RE2, der ist fast kompatibel. Wenn unser Produzent seinen Bestand aufgebraucht hat, muß ich noch die Firmware anpassen, hoffe mal, das ist nicht zu aufwendig. Peter
Vor 1..2 Jahren war hier ein Thread "Übernimmt Microchip Atmel?" Nun ja, derzeit ist das ja wohl vom Tisch. Dennoch hinterlässt das immer noch so ein dumpfes Bauchgefühl. Daher NEIN zu Atmel, zumindest wenn man Produkte mit 10 Jahren Laufzeit machen möchte.
Die Mentalitäten sind halt unterschiedlich. Silicon Laboratories hat vor ein paar Monaten nagelneue µCs mit USB-Schnittstelle vorgestellt - und 8051 Core. :-) Ich bin gerade von MEGA auf XMEGA umgestiegen, weil mir deren Leistungsfähigkeit zur Zeit noch ausreicht, der passende Stein bei mehreren Distributoren verfügbar ist und der Aufwand zur Umgewöhnung doch deutlich geringer war als bei einer ganz anderen Architektur. Schuster, bleib bei deinen Leisten, war da Devise. Ja, so viel anders als die MEGAs ist der XMEGA nicht. Die einen sehen das als Nachteil, die anderen als Vorteil Ich freue mich, dass ich in diesem Thread die Bestätigung erhalten habe, da keinen grundsätzlichen Fehler gemacht zu haben. Gruß, DetlevT
Peter Dannegger schrieb: > Xmega kann man also getrost vergessen. Seit wann ist der Peter denn so pauschal & populistisch :( Ist doch albern das anhand einiger Pluspunkte für Controller XY zu behaupten. Auch für mich ist der XMega erste Wahl. Die Gründe wurden hier alle schon genannt.
Moby schrieb: > Peter Dannegger schrieb: >> Xmega kann man also getrost vergessen. > > Seit wann ist der Peter denn so pauschal & populistisch :( > Ist doch albern das anhand einiger Pluspunkte für Controller XY zu > behaupten. Das sind aber noch weitere Punkte, die wegfallen, um einen Umstieg zu rechtfertigen. Schlechte Beschaffbarkeit oder buggy ADC reißen mich, wie gesagt, nicht vom Hocker. Mehr als 4 UARTs habe ich auch noch nie gebraucht. Und die Instructionset-Kompatibilität zählt für mich nicht, da ich eh in C programmiere. Damit bleiben 0 Punkte übrig. Ich hab noch nicht nachgeschaut, aber ich nehme mal stark an, daß es für den Cortex M3 eine ähnlich einfach zu installierende und zu benutzende Toolchain gibt, wie den WINAVR für den AVR. Ich bleibe bei den standard AVRs, solange sie meine Aufgaben leicht bewältigen. Aber darüber gehts dann gleich zu 32Bit. Ob ich dann den Cortex M3 von Atmel, NXP, ST oder TI nehme weiß ich noch nicht, ST scheint ja der Platzhirsch zu sein. Peter
Tendiere eher zu ARM, weil die einfach besser zu programmieren sind. 32 Bit ist schon was feines. 5V Toleranz ist auch ganz gut. Wenn mehr oder weniger exakt das gleiche Programm auf einen XMega umgesetzt werden soll ist XMega wohl die bessere Alternative, aber für aufwändigere Programme ist ARM einfach besser. Gelötet habe ich die Dinger noch nicht ... Wollte in der Sprache Pascal programmieren. Das hat schon einer geschafft dort. http://www.freepascal.org
Peter Dannegger schrieb: > Ich hab noch nicht nachgeschaut, aber ich nehme mal stark an, daß es für > den Cortex M3 eine ähnlich einfach zu installierende und zu benutzende > Toolchain gibt, wie den WINAVR für den AVR. Wenn du kein Geld dafür ausgeben willst: Nein. Zumindest runterladen, installieren, läuft gibt es bei den Cortex M3 nicht direkt. Ein wenig Gefrickel ist mitunter von nöten. > Ich bleibe bei den standard AVRs, solange sie meine Aufgaben leicht > bewältigen. > Aber darüber gehts dann gleich zu 32Bit. Ob ich dann den Cortex M3 von > Atmel, NXP, ST oder TI nehme weiß ich noch nicht, ST scheint ja der > Platzhirsch zu sein. Zumindest hier im Forum. In der Industrie ist NXP mindestens ebenso weit verbreitet, TI hat die Cortex-Geschichte ja etwas verschlafen und dann Lumiary Micro gekauft. Aber was die ATMEL-Verfügbarkeit angeht: Probleme in der Beschaffung hatten wir inzwischen fast bei jedem Hersteller einmal. Was stimmt, ist die lange Zeit zwischen den ATMEL-Ankündigungen und der Serienverfügbarkeit, aber da kann man sich drauf einstellen. Mit den XMega hatte ich noch keine Probleme in der Beschaffung. Man muss nur ein wenig schauen: Ineltek bietet sie zum günstigeren Preis bei mehreren Wochen Lieferzeit in der Regel an, Farnell hat sie zum höheren Preis auf Lager. Da wir für die Fertigung aber meistens ein paar Wochen Vorlauf haben, ist das eigentlich nur ein organisatorisches Problem.
Rainer S. schrieb: > Wollte in der Sprache Pascal programmieren. Das hat schon einer > geschafft dort. > http://www.freepascal.org Ganz ehrlich? Lerne C! Ist nicht böse gemeint, aber mit Pascal für den ARM tust du dir keinen Gefallen. Es gibt kaum Beispiele, von keiner mir bekannten Firma Support dafür und in Foren wirst du auch kaum Antworten finden.
Mich würde es auch reizen das ganze mit dem FPC zu proggen. Wenn ich erst mal die 620KB STM32 Header-Datei in Pascal umschreiben muss, damit ich mit den STM32 mal schnell mal testen könnte, ist irgendwie nicht motivierend. Also lasse ich das.
Christoph Budelmann schrieb: > Ganz ehrlich? Lerne C! Woher willst Du wissen, dass ich das nicht schon kann? > Ist nicht böse gemeint, aber mit Pascal für den ARM tust du dir keinen > Gefallen. Es gibt kaum Beispiele, von keiner mir bekannten Firma Support > dafür und in Foren wirst du auch kaum Antworten finden. Der Compiler läuft bei mir auf Linux und Windows. Support gibt es in der Mailingliste aus erster Hand. Die sind da sehr aktiv. Markus Müller schrieb: > Mich würde es auch reizen das ganze mit dem FPC zu proggen. Wenn ich > erst mal die 620KB STM32 Header-Datei in Pascal umschreiben muss, damit > ich mit den STM32 mal schnell mal testen könnte, ist irgendwie nicht > motivierend. > Also lasse ich das. Ich habe auch gehadert ob ich den Compiler einsetzen soll oder nicht. Aber ich habe es bis jetzt nicht bereut, im Gegenteil. Die STM32 Headerdatei hat schon jemand übersetzt. http://j-software.dk/stm32f103.php
Rainer S. schrieb: > Christoph Budelmann schrieb: >> Ganz ehrlich? Lerne C! > > Woher willst Du wissen, dass ich das nicht schon kann? Wie gesagt, ist nicht böse gemeint. Nur in 99% der Fälle wenn jemand nicht C oder Assembler einsetzen möchte hat derjenige kaum Ahnung und meint Visual Basic wäre wunderbar für aktuelle Mikroprozessoren einzusetzen. > Der Compiler läuft bei mir auf Linux und Windows. Support gibt es in der > Mailingliste aus erster Hand. Die sind da sehr aktiv. Es bleibt aber definitiv eine sehr kleine Gruppe, da es wirklich ein Nischen-Compiler ist für ARM. Zumindest Neulingen würde ich nicht dazu raten, wenn du aber Erfahrungen hast sieht das natürlich anders aus.
Welche Software ist erforderlich, wenn der STM32 in Assembler programmiert werden soll? Geht das mit dem Atmel Studio?
Wieso sollte man mit einer Atmel-Software einen ST Prozessor programmieren wollen? Dazu noch in Assembler?
Peter Dannegger schrieb: > Ich sehe grade mit Entsetzten, die Xmega haben ja gar keinen CAN. > Dann sind sie für mich völlig unbrauchbar. Peter Dannegger schrieb: > Xmega kann man also getrost vergessen. Das hätte ich Dir nicht zugetraut, Peter. Das ist weder konstruktiv, noch objektiv. Besonders für jemanden, der die Steine nicht kennt.
Ein Prozi ohne CAN ist auch für mich unbrauchbar. Und extra mal für ein Projekt einen XMega zu nehmen wenn ich mal zufällig kein CAN brauche ist auch quatsch. Alleine die Einarbeitungszeit in den XMega, das rechnet sich nie.
Geht mir in meinem hauptsächlichen Aufgabenfeld auch so. CAN kommt sehr häufig vor. Ich verstehe nicht, wie man heutzutage eine ganze neue Familie auf den Markt bringen will und meint, darauf verzichten zu können.
H.joachim Seifert schrieb: > Ich verstehe nicht, wie man heutzutage eine ganze neue > Familie auf den Markt bringen will und meint, darauf verzichten zu > können. Frage: Würdest du von deiner jetzt benutzten Architektur wechseln, wenn es XMEGAs mit CAN geben.? Ich vermute: Nein. Warum sollte Atmel die Wünsche derjenigen erfüllen, die auch dann nie auf diese Plattform wechseln würden? Das wäre doch ziemlich unsinnig. Atmel muss selbst wissen, wo seine Marktchancen sind.
Knut Ballhause schrieb: > Das hätte ich Dir nicht zugetraut, Peter. Das ist weder konstruktiv, > noch objektiv. Besonders für jemanden, der die Steine nicht kennt. Ich hatte doch explizit geschrieben: für mich. Ich muß ja von meinen Anforderungen ausgehen, und da ist CAN unverzichtbar. Wo wir schon CAN einsetzen, haben wir sehr gute Erfahrungen gemacht (einfach zu programmieren, robust, störsicher). Es ist aber schön, daß Atmel festlegt, daß kein CAN und keine 5V-Toleranz geplant ist. Somit brauche ich den Einsatz des Xmega garnicht erst zu überlegen. Peter
Nein, ohne Grund würde ich (und wohl auch niemand anders) wechseln. Wechselt man aber sowieso (durch irgendwas erzwungen), dann nicht dahin, wo man beim übernächsten Projekt wieder mit der langen Nase dasteht. Klar muss Atmel das selbst wissen. Ich verbaue/verkaufe ca. 20.000 Stk aller möglichen AVR im Jahr. Immer noch viel zu wenig, um befragt zu werden, was mir wichtig ist oder wäre. Ich weiss auch nicht, ob sowas überhaupt stattfindet. Dennoch ist CAN ein unverzichtbarer Teil der heutigen vernetzten Welt. Atmel hätte die Ressourcen gehabt, das kleine Teil dazuzubauen. Ich verstehe nicht, warum sie es nicht gemacht haben (und wie oben gehört, nicht mal drüber nachdenken). Der Schluss für mich: nicht benutzen, fertig. Man müsste sich diesen trööt mal auf Termin legen und in 5 Jahren noch mal schauen, ob es die XMegas dann noch gibt.
Detlev T. schrieb: > H.joachim Seifert schrieb: >> Ich verstehe nicht, wie man heutzutage eine ganze neue >> Familie auf den Markt bringen will und meint, darauf verzichten zu >> können. > > Frage: Würdest du von deiner jetzt benutzten Architektur wechseln, wenn > es XMEGAs mit CAN geben.? Ich vermute: Nein. > > Warum sollte Atmel die Wünsche derjenigen erfüllen, die auch dann nie > auf diese Plattform wechseln würden? Das wäre doch ziemlich unsinnig. > Atmel muss selbst wissen, wo seine Marktchancen sind. Das heißt ganz einfach das ATMEL hiermit auf einen großen Markt mit garantierten Langfristigen Absatzzahlen verzichtet ( Automobilbranche). Wahrscheinlich weil sie die langfristige Verfügbarkeit nicht garantieren können oder wollen. Wer langfristig lieferbare IC sucht, sollte darauf achten das die Teile eine AUTOMOTIVE Freigabe besitzen. Die sind zwar etwas teurer dafür lange lieferbar. Ein Automobil Hersteller und/oder Zulieferer muss bis 10 Jahre nach Produktionsende des Autos die Lieferung von Ersatzteilen garantieren. Das geht nur wenn auch die Einzelteile entsprechend lange Verfügbar sind. Macht das ganze etwas teurer pro Teil, aber eine Neuentwicklung mit Freigaben,.... nach einigen Jahren kostet garantiert deutlich mehr.
H.joachim Seifert schrieb: > Man müsste sich diesen trööt mal auf Termin legen und in 5 Jahren noch > mal schauen, ob es die XMegas dann noch gibt. Stimmt, das könnte interessant werden. Und auch, wie weit deren Preise über den jetzigen Einführungspreisen liegen werden. Meine Prognose wäre, die standard AVRs halten länger durch, als die Xmega. Atmel hatte ja sogar mal nen 8051 für MP3-Player entwickelt, der ist auch schon in der Versenkung verschwunden: http://www.atmel.com/dyn/products/product_docs.asp?category_id=163&family_id=604&subfamily_id=2389&part_id=3907 Peter
Der AP7000 AVR32 ist doch auch quasi schon wieder abgekündigt oder hab ich das falsch in Erinnerung?
Ich glaube, dass die Frage des Threaderöffners hinreichend geklärt ist.
Peter Dannegger schrieb: > Meine Prognose wäre, die standard AVRs halten länger durch, als die > Xmega. > Peter Seh ich auch so, die sind inzwischen ganz gut aufgestellt. Allerdings haben die Preise z.T. deutlich angezogen. Ein (für mich in hohen Stückzahlen , ca. 8.000-10.000 Stk/Jahr) laufendes Projekt mit Mega168 wurde auf PIC umgestellt, im Zuge einer sowieso erforderlichen Platinenrevision. Ca. 80Ct pro Stück gespart.
Ein sehr großer Vorteil ist der Codevision Compiler http://www.hpinfotech.ro/html/cvavr.htm Hier gibt es einen Wizard. Dort stellt man den verwendeten XMEGA ein und kann sofort die Interrupts, Timer, ADCs, SPI usw. mit wenigen Klicks konfigurieren. Wer Wizard erstellt ein Configurations-Code und man kann sofort loslegen und sein Code umsetzen. Dies ist meist bei ARM-Porzessoren deutlich schwerer. Ein Fehler ist mir beim XMEGA aufgefallen. Es gibt leider Probleme mit dem interen EEPROM. Da hilf nur ein aufwendiges Workaround, anstonsten wird immer der XMEGA zurückgesetzt.
Den hab ich sogar, kann aber auch nicht mehr als 64kB RAM direkt adressieren.
Johann schrieb: > Ein Fehler ist mir beim XMEGA aufgefallen. Es gibt leider Probleme mit > dem interen EEPROM. Nur bei einigen Typen (A3/D3 und frühe A1) gibt es diesen Fehler, für den aber auch ein Workaround existiert. Bei den anderen Ausführungen und den neuen mit USB funktioniert das EEPROM einwandfrei.
Knut Ballhause schrieb: > Nur bei einigen Typen (A3/D3 und frühe A1) gibt es diesen Fehler Stimmt das noch? Das Datenblatt http://www.atmel.com/dyn/resources/prod_documents/doc8134.pdf meldet nur Errata bis Rev. E, das Datenblatt ist aber schon bei der Rev. I angekommen. Oder verstehe ich da etwas nicht?
Na umso besser ;-). Ein Page-Buffer Erratum ist noch drin, ist aber weniger kritisch.
Markus Müller schrieb: > Wieso sollte man mit einer Atmel-Software einen ST Prozessor > programmieren wollen? Dazu noch in Assembler? Ich habe gelesen, dass mit der neuesten Atmel Software auch ARM Code erzeugt werden kann. Oder doch nur der AVR32? Das wäre praktisch, da damit auch die AVR Prozessoren programmiert werden können. Mit Assembler ist man einfach schneller unterwegs. Für einfache Aufgabenstellungen geht das. Natürlich wäre Pascal mit integriertem Assembler für mich die beste Lösung.
Gerade frisch entdeckt: Im Voltcraft Charge Manager 410 werkelt ein XMEGA16D4 als Ladecontroller. Der in Kürze erscheinende Charge Manager 420 dürfte einen -AU XMEGA mit USB benutzen. Die Pins auf der Platine des 410 sind jedenfalls dafür vorbereitet ;-).
Meinen Beobachtungen nach kann ich folgendes zusammenfassen: FETTE Minuspunkte für den XMEGA =================================== -die ATmega A1 und A4 (andere Datenblätter habe ich nicht untersucht) sind extrem verbuggt, insbesondere der vermeintliche Hauptvorteil des XMEGA: der ADC ist schlechter denn je -dass es im Datenblatt für die A1 und A4 eine Errata-Liste nur für die 32 und 64 kb-Version gibt, scheint nur daran zu liegen, dass eine 128- und 256kb-Version bisher noch nie hergestellt wurden (das Datenblatt behinhaltet die zwar, aber die Übersicht auf der Website noch nicht) LÖSUNG : nur die U (= USB )- Versionen verwenden ========================================================= -Einzig die um USB erweiterten XMega-Versionen (Hab' mir die Errata im Datenblatt für den A4U angesehen) scheinen keine relevanten Bugs mehr zu haben und ENDLICH scheint der ADC das großspurig angekündigte auch wirklich drauf zu haben. FETTE Pluspunkte für den XMEGA ================================== -Der xmega32A4U kostet selbst bei farnell 3,60€ ab 1 Stück und 2,30€ ab 25 Stück, d.h. in 1000er-Stückzahlen dürfte der Preis bei 1,10€ [mit viel Glück] bis max. 2,20€ [mit viel Pech] liegen) Das ist IMHO extrem günstig. Allerdings scheint der A4U derzeit nur mit max. 128 kB, also xmega128A4U hergestellt zu werden. Dass es allerdings keine xmegas mit CAN geben soll ist in der Tat sehr seltsam, das hätte IMHO in ALLE xmegas standardmäßig reingehört und in die größeren außerdem noch Ethernet, das evtl. optional. Es sieht auch nicht danach aus, als hätte Atmel jemals vor, die verbugten xmegas ohne USB in fehlerfrei neu aufzulegen, denn z.B. die Fehlerliste des xmegaA1 ist schon 2009 so lang gewesen und gilt noch heute (Silicon revision H, die einzige, die vom A1 bisher produziert wurde) Leider ist aber gerade das IMHO interessanteste Feature bei den xmegas OHNE USB, nämlich der neue ADC, so dermaßen fehlerhaft, dass er eher schlechter ist, als der bisherige ADC, maximal gleichwertig. Wenn man das weiß, dann weiß man, dass man ausschließlich die xmegas mit USB nehmen will/sollte. Atmel sollte die alten Varianten ohne USB IMHO schnellstmöglich als "not recommended for new designs" markieren oder wenigstens Prominent auf die lange errata-Liste hinweisen oder aber die Hardware-Bugs beheben. (Da sie das in den letzten 4 Jahren aber nicht getan haben, dürfte das nicht geplant sein.) Zusätzliche Stichworte für bots, um dieses Posting besser einzuordnen: xmega buggy, full of hardware bugs, extremely buggy, ADC analog frontend broken, large extensive errata list
Daniel schrieb: > Dass es allerdings keine xmegas mit CAN geben soll ist in der Tat sehr > seltsam, das hätte IMHO in ALLE xmegas standardmäßig reingehört Naja, rein kommt, was die Kunden bereit sind zu bezahlen. Wenn die Masse der Kunden keine Vernetzung braucht, warum sollten sie dann die Chipfläche für den CAN-PHY bezahlen? > (Silicon revision H, die einzige, die vom A1 bisher produziert > wurde) Wenn's eine Revision H gibt, dann kannst du dir sicher sein, dass auch die Revisions A bis G produziert worden sind. Kann halt nur sein, dass sie nie verkauft worden sind, weil man nach internen Tests und vielleicht ein paar Alpha-Kunden der Meinung war, doch noch was ändern zu müssen.
Daniel schrieb: > -dass es im Datenblatt für die A1 und A4 eine Errata-Liste nur für die > 32 und 64 kb-Version gibt, scheint nur daran zu liegen, dass eine 128- > und 256kb-Version bisher noch nie hergestellt wurden (das Datenblatt > behinhaltet die zwar, aber die Übersicht auf der Website noch nicht) ATxmega128A1, 192A1, 256A1 - alle zu bekommen. Im kleineren TQFP44-Gehäuse geht es derzeit bis 128kB (Digikey, EBV, MSC, etc.), die größere Varianten sind meines Wissens noch nicht raus, da ATMEL die A4 immer als letzte herausgebracht hat.
Bin mit den XMega USB-Teilen absolut eins geworden ;) Bin zwar "nur" ein Hobbyentwickler, aber da USB Stand der Dinge ist und der FTDI232R schon mehr kostet als der XMega32A4U, ist der nun mal erste Wahl... Vom Preis her laufen die auch jedem annähernd ähnlichem ATMega davon... jedenfalls was ich so beobachten konnte... Programmieren mit der ASF ist bei USB-Verwendung schon sehr bequem, für den Rest des Sources muss man die ASF ja nicht benutzen... Ich verwende die Funktionen trotzdem gern, obwohl sie oft nur bessere defines sind um Register zu setzen... Wo bekommt man sonst als Hobbyist nen 2,50 € Controller mit USB, 5xUARTs, 7xSPI, 2xTWI, DMA und dem schon besprochenen 12 BIT ADC... Nicht zu vergessen die kostenlose Entwicklungsumgebung die sich seit der Visual Studio Kooperation echt sehen lassen kann (mal abgesehen von kleineren Bugs :-/) Bei meinem Discovery F4 Board habe ich erst mal mehrer Stunden versucht eine brauchbare kostenlose Entwicklungsumgebung zum laufen zu bekommen... (okay, muss sich ja nicht jeder so blöd anstellen ;) ) So, da wollte ich mal noch die Lanze zum Hobbyeinsatz brechen ;) Grüße Bassti
Daniel schrieb: > -dass es im Datenblatt für die A1 und A4 eine Errata-Liste nur für die > 32 und 64 kb-Version gibt, scheint nur daran zu liegen, dass eine 128- > und 256kb-Version bisher noch nie hergestellt wurden (das Datenblatt > behinhaltet die zwar, aber die Übersicht auf der Website noch nicht) Atmel hatte ursprünglich eine sehr lange Liste von Versionen, die sie angeblich herstellen wollten. Echte Produkte wurden daraus nicht, und nach und nach verschwanden die von der Webseite. Die typischen Papierform-Entwickler "wenn das auf der Webseite steht wird es schon stimmen ...", sahen dabei ziemlich blass aus. > LÖSUNG : nur die U (= USB )- Versionen verwenden ... > ENDLICH scheint der ADC das großspurig angekündigte auch > wirklich drauf zu haben. Der in den USB-Versionen ist ein anderer ADC Typ, der die ursprünglichen Versprechungen nicht erfüllt, aber soweit man heute absehen kann, das kann, was im USB-Datenblatt steht. Was Atmel immer noch nicht drauf hat ist die Calibration Row mal mit echten Kalibrierungswerten auszuliefern, so wie versprochen. > Es sieht auch nicht danach aus, als hätte Atmel jemals vor, die > verbugten xmegas ohne USB in fehlerfrei neu aufzulegen, denn z.B. die > Fehlerliste des xmegaA1 ist schon 2009 so lang gewesen und gilt noch > heute (Silicon revision H, die einzige, die vom A1 bisher produziert > wurde) ... > Atmel sollte die alten Varianten ohne USB IMHO schnellstmöglich als "not > recommended for new designs" markieren oder wenigstens Prominent auf die > lange errata-Liste hinweisen oder aber die Hardware-Bugs beheben. (Da > sie das in den letzten 4 Jahren aber nicht getan haben, dürfte das nicht > geplant sein.) Angeblich hatte Atmel am Anfang des XMEGA-Trauerspiels einen Design Win bei einem Großkunden, der die Dinger seither so kauft, wie sie nun mal sind. Vielleicht wollen die den Kunden nicht mit einer "not recommended"-Ansage nervös machen. Noch ein paar FETTE Nachteile: * Das Trauerspiel mit der Entwicklungsumgebung, dem Compiler und ASF. * Atmels wenig hilfreicher Support wie ich ihn erfahren habe. * Bei der Menge an gebrochenen Versprechungen bez. XMEGAs in der Vergangenheit nehme ich von Atmel kein Stück Brot mehr. * ARM MCUs aller Art drücken von Oben die Luft ab.
Bassti schrieb: > Wo bekommt man sonst als Hobbyist nen 2,50 € Controller mit USB, > 5xUARTs, 7xSPI, 2xTWI, DMA und dem schon besprochenen 12 BIT ADC... > > Nicht zu vergessen die kostenlose Entwicklungsumgebung die sich seit der > Visual Studio Kooperation echt sehen lassen kann (mal abgesehen von > kleineren Bugs :-/) Nicht neu schrieb: > * ARM MCUs aller Art drücken von Oben die Luft ab. Bin jetzt beim STM32F103 gelandet. Nicht dass ich jetzt die XMega unbeding schlecht finde (reden) will. Aber die STM32 Dinger sind einfach besser. Dort sind auch bis zu 5xUARTs, bis zu 3xSPI, 2xI2C(TWI), DMA, usw. möglich. Seit neuestem ist sogar ein 16bit sigma delta A/D Converter integriert was den Controller sehr interessant für Messaufgaben macht. http://www.st.com/internet/mcu/subclass/1605.jsp Atmel würde ich sowas aktuell nicht zutrauen. Die Preise liegen teilweise unter 2 Euro. http://www.schukat.com/schukat/schukat_cms_de.nsf/index/CMSDF15D356B046D53BC1256D550038A9E0?OpenDocument&wg=Y4773&refDoc=CMS4973C58BAA4AC604C12570DE0037E4FA Die Geschwindigkeit ist mit 78MHz mehr als doppelt so hoch wie ein XMega. 32 bit Code dürfte nochmal um ca. mindestens Faktor 2 schneller sein. Viel wichtiger aber ist für mich, dass ich jetzt eine passende Entwicklungsumgebung gefunden habe. http://www.freepascal.org Ich sehe keinen Grund mehr AVR einzusetzen. Hatte noch gedacht, dass die STM32 nicht so einfach zu löten sind, aber auch dass lässt sich mit etwas Übung bewerkstelligen.
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.