Zur Elektronika im November sollen neue XMega Typen vorgestellt werden! Unter anderem wird nach den bisherigen A-D Typen eine neue E-Serie gestartet. Noch bastlerfreundlicher gibt sich dann noch ein neuer Gehäusetyp mit nur 32 Pins...
Gerüchtekoch schrieb: > Zur Elektronika im November sollen neue XMega Typen vorgestellt werden! > Unter anderem wird nach den bisherigen A-D Typen eine neue E-Serie > gestartet. Noch bastlerfreundlicher gibt sich dann noch ein neuer > Gehäusetyp mit nur 32 Pins... Quelle? Link?
Na dann... Ich find die Dinger cool. Auch wenn der ARM natürlich die vernünftigere Alternative ist! Ingo
Zum Spielen finde ich die auch ganz nett. In ein ernsthaftes Projekt kommen sie aber nicht rein, ist mir viel zu unsicher (bezüglich der zukünftigen Verfügbarkeit)
H.joachim Seifert schrieb: > Zum Spielen finde ich die auch ganz nett. > In ein ernsthaftes Projekt kommen sie aber nicht rein, ist mir viel zu > unsicher (bezüglich der zukünftigen Verfügbarkeit) Wieder mal typisch. Bleibt mir bloß weg mit dem neuen Teufelszeug... Die XMEGA Ax / AU-Serie bekommt man inzwischen flächendeckend und preisgünstig. Gerade bei den AU XMEGAs sind die Kennwerte und die Funktionalität den klassischen Megas um Längen voraus. Wir setzen sie auch in großen Projekten ein.
nicht nur den atmegas sind sie von der analogen peripherie voraus, auch den meisten arms, Denn mhz ist nicht alles was zahlt
Knut Ballhause schrieb: > Gerade bei den AU XMEGAs sind die Kennwerte und die > Funktionalität den klassischen Megas um Längen voraus. Aber warum mich von Atmel stärker als vielleich nötig abhängig machen? Wenn ich doch sowieso auf eine 32-Bit Architektur wechseln 'muss', dann kann ich doch auch zu den Atmel SAMs greifen. Das liefert mir zumindest neben dem Produkt selbst ein Know-how, das sich auch auf andere Hersteller übertragen lässt. Die Peripherie der SAM und den XMEGA's ist meist identisch.
>nicht nur den atmegas sind sie von der analogen peripherie voraus, auch >den meisten arms, Beispiele? Eins reicht.
>Gerade bei den AU XMEGAs sind die Kennwerte und die Funktionalität den >klassischen Megas um Längen voraus. Wir setzen sie auch in großen >Projekten ein. Verwendet ihr auch die internen ADCs? Hat ATMEL jetzt die Probleme mit den ADCs in den XMEGAs im Griff?
@Knut: ich sehe mich in der Verantwortung meinen Kunden gegenüber. Und ich bin nicht überzeugt, dass es die XMegas lange geben wird. Zumindest sehe ich es als (unnötigen) Unsicherheitsfaktor, den ich nicht eingehen muss. Du kannst das gerne machen, wie du willst. Und wenn es eine innerbetriebliche Entwicklung ist, ist das auch völlig in Ordnung - die Entscheidung, welcher Prozzi genommen wird, triffst du wahrscheinlich nicht allein. Ich arbeite für externe Auftraggeber. Ziemlich blöd, wenn dann nach 2 Jahren die Telefone klingeln: "Wir können nicht mehr produzieren, xxxx ist nicht mehr lieferbar!" Wenn der Kunde drauf besteht oder selbst vorschlägt - bitte sehr, dann stelle ich mich auch nicht auf die Hinterbeine. Aber eigenmächtig werde ich das nicht tun. Ein Grossteil meiner Kunden hat von Elektronik keine Ahnung. Sie haben nur ein Problem, dass gelöst werden soll.
Kai Klaas schrieb: >>Gerade bei den AU XMEGAs sind die Kennwerte und die Funktionalität den >>klassischen Megas um Längen voraus. Wir setzen sie auch in großen >>Projekten ein. > > Verwendet ihr auch die internen ADCs? Hat ATMEL jetzt die Probleme mit > den ADCs in den XMEGAs im Griff? Yep, 2x 12bit bei je 2msps und gain stage, oversampled auf 16bit Aber nehm die neueste version, zb atxmega128a1u
>oversampled auf 16bit
Nich vorhandene Auflösung in die Tasche lügen: Lächerlich;)
Gerüchtekoch schrieb: > Zur Elektronika im November sollen neue XMega Typen vorgestellt werden! > Unter anderem wird nach den bisherigen A-D Typen eine neue E-Serie > gestartet. Noch bastlerfreundlicher gibt sich dann noch ein neuer > Gehäusetyp mit nur 32 Pins... Ob es diesmal anders laeuft als "announce early, release never" ?
Warum sollte es die XMEGA's nicht lange geben? Die Bausteine sind extrem solide und Atmel hat auch die MEGA/Tiny Reihe schon ewig auf dem Markt, mindestens 10 Jahre. Der AVR Core ist immer noch ein hocheffizienter und moderner Core. Mir ist Atmel als Hersteller bekannt, der Produkte lange auf dem Markt hat. In der Presse kann man lesen, dass die meisten Android Smartphones einen Atmel Micro drin haben (Samsung, HTC), das will was heißen. Die können sich nicht leisten Schrott einzubauen. Die Integration der XMEGA's ist echt Klasse. Hat einer schonmal das interne Event System getestet? Das ist echt der Hammer!
Rughi schrieb: > In der Presse kann man lesen, dass die meisten Android Smartphones einen > Atmel Micro drin haben (Samsung, HTC), das will was heißen. Die können > sich nicht leisten Schrott einzubauen. Gibt es eine Quelle/Link oder nur erfunden?
Rughi schrieb: > In der Presse kann man lesen, dass die meisten Android Smartphones einen > Atmel Micro drin haben (Samsung, HTC), das will was heißen. Die können > sich nicht leisten Schrott einzubauen. Und wie lange wird ein Smartphone gebaut? 1/2 .. 1 Jahr dann gibt es was neues mit einer neuen CPU. Die brauchen da keine langlebige Verfuegbarkeit.
holger schrieb: > Nich vorhandene Auflösung in die Tasche lügen: Lächerlich;) Eine Lüge ist das zwar nicht, aber das kann im Prinzip (fast) jeder ADC.
Es gibt unendlich viele Links: http://ir.atmel.com/releasedetail.cfm?ReleaseID=706152 http://wirelessdesignmag.com/ShowPR.aspx?PUBCODE=055&ACCT=0000100&ISSUE=1108&RELTYPE=IN&PRODCODE=000000&PRODLETT=Z&CommonCount=0 http://finance.yahoo.com/q?s=ATML Samsung Galaxy S, Samsung Galaxy S 2, Samsung Galaxy Tab, Kindly Fire. Stimmt die Smartphone Hersteller brauchen keine langfristige Verfügbarkeit. Wie gesagt, mir ist nicht bekannt, dass Atmel sehr früh abkündigt, ich kenne Sie eher, dass Sie die Produkte sehr lange am Markt haben. Da kann man sogar noch C51 kaufen und welcher andere Hersteller hat die noch im Angebot? Wie gesagt ich kann Atmel besten Gewissens für Ernste und langlebige Industrie-anwendungen empfehlen.
Ich wär jetzt eher mit den '51ern gekommen wegen Langlebigkeit bei den uC ... Die Frage aber ist: Was hat der XMEGA an Vorteil gegenüber z.B. den SAM3 von Atmel, dass man sich im professionellen Umfeld für diese entscheiden sollte?
Rughi schrieb: > Da kann > man sogar noch C51 kaufen und welcher andere Hersteller hat die noch im > Angebot? Über 50 andere Hersteller (z.B. AD, Microchip, Infineon, Silabs, Maxim, NXP, SST, Nuvoton, ...). Und die entwickeln sogar neue 8051-er. http://www.keil.com/download/files/8051_market_in_2008.pdf Peter
Knut Ballhause schrieb: > Gerade bei den AU XMEGAs Ihr meint sicher die U-Typen... AU ist die Gehäuseform. Marc schrieb: > nicht nur den atmegas sind sie von der analogen peripherie voraus, auch > den meisten arms, > Denn mhz ist nicht alles was zahlt Genau! Als ASM-Programmierer bin ich nun auch bei den XMegas angekommen und sehe auch für die weitere Zukunft kein Projekt, wo ich deren Leistungsfähigkeit jemals ausschöpfen könnte. Bei Hochsprachenprogrammierung mag das anders aussehen, da werden die Ressourcen ja teilweise dermaßen verschwendet daß es dann oft schon 32 Bit ARM mit mehr als 100kB Flash+SRAM sein muß :-) Auf das EEPROM mag ich dann auch nicht verzichten. XMegas sind (als U-Typen) inzwischen ein rundes Paket geworden: Alles drin was man braucht, ein einfaches Design, das einfach programmierbar ist ! Gerüchtekoch schrieb: > Noch bastlerfreundlicher gibt sich dann noch ein neuer > Gehäusetyp mit nur 32 Pins... Das vollendete Bastlerglück wären dann natürlich XMegas im kleinen DIL Gehäuse! Moby.
Moby schrieb: > Bei > Hochsprachenprogrammierung mag das anders aussehen, da werden die > Ressourcen ja teilweise dermaßen verschwendet Ah ja. Noch nie einen Compiler benutzt, aber das 1000%ige Wissen darüber ...
Maxx schrieb: > Was hat der XMEGA an Vorteil gegenüber z.B. den SAM3 > von Atmel, dass man sich im professionellen Umfeld für diese entscheiden > sollte? Unter Umständen gar keinen bzw. es ist egal. Viel entscheidender ist doch welches Know How und dazugehörige Programmierumgebung schon vorhanden ist: Das wirft man ohne Zwang nicht einfach über Board! "Never touch a running system"
Jörg Wunsch schrieb: > Noch nie einen Compiler benutzt, aber das 1000%ige Wissen darüber ... Zur Veranschaulichung: Ins Extrem wirds bei der PC-Programmierung getrieben: Maustreiber in Megabytegröße. Bei den kleinen Controllern geht das Elend bereits los!
Moby schrieb: > Ins Extrem wirds bei der PC-Programmierung > getrieben: Maustreiber in Megabytegröße. Soso.
1 | j@uriah 198% size /usr/obj/usr/src/sys/URIAH/*psm* |
2 | text data bss dec hex filename |
3 | 32599 1424 40 34063 850f /usr/obj/usr/src/sys/URIAH/psm.o |
Einen Maustreiber mit vergleichbarer Funktionalität in nur 10 KiB Assembler würde ich gern sehen wollen. Aber das nur am Rande.
Knut Ballhause schrieb: > H.joachim Seifert schrieb: >> Zum Spielen finde ich die auch ganz nett. >> In ein ernsthaftes Projekt kommen sie aber nicht rein, ist mir viel zu >> unsicher (bezüglich der zukünftigen Verfügbarkeit) > > Wieder mal typisch. Bleibt mir bloß weg mit dem neuen Teufelszeug... Die > XMEGA Ax / AU-Serie bekommt man inzwischen flächendeckend und > preisgünstig. Gerade bei den AU XMEGAs sind die Kennwerte und die > Funktionalität den klassischen Megas um Längen voraus. Wir setzen sie > auch in großen Projekten ein. Du bist wohl noch kein gebranntes Kind? Ich erinnere mich noch zu gut an die Abkündigungen, horrenden Lieferzeiten und 50% Preiserhöhungen vor wenigen Jahren. Seitdem ist ATMEL ein absolutes no go!
Moby schrieb: > Unter Umständen gar keinen bzw. es ist egal. Viel entscheidender ist > doch welches Know How und dazugehörige Programmierumgebung schon > vorhanden ist: Das wirft man ohne Zwang nicht einfach über Board! Eben! Deshalb würde ich zurückschrecken davon Geld ins Know-How zu stecken, dass dann nicht transferiert werden kann, wenn Alternativen da sind. Denn AVR und AVR32 sidn ja bereits zwei komplett verscheidene Dinge, Know-How muss also sowieso erstmal wieder beschafft werden beim Wechsel
Kai Klaas schrieb: > Verwendet ihr auch die internen ADCs? Hat ATMEL jetzt die Probleme mit > den ADCs in den XMEGAs im Griff? Ja. Geht super. Hinzugekommen sind auch nützliche Fuktionen, wie softwareseitige Pinauswahl bei allen Interfaces und Timer-OCR-Pins, Analog-Komparatoren mit internem 64-stufigem Teiler. Alle ADC-Pins und Analog-Komparator-Pins sind an den analogen Ports A/B belibig multiplexbar. Das Eingangsverstärker wurde um Gain x 0.5 erweitert, was für manche Anwendungen ganz nützlich ist. Das zur Laufzeit komplett konfigurierbare ClockSystem in Verbindung mit DMA und Eventsystem ist schon ein machvolles Instrumentarium für einen 8-Bitter. Bei einem Mega war, wenn das Layout einmal stand, nur noch recht wenig per Software zu optimieren oder gar zu reparieren, weil der Kunde mal wieder nicht wusste, was er wollte. Beim XMEGA wird an der richtigen Stelle einfach ein Bit gesetzt, und schon sind die Signale invertiert oder an ganz anderen Portpins wiederzufinden. Und das mit voller Hardwareunterstützung. Moby schrieb: > Knut Ballhause schrieb: >> Gerade bei den AU XMEGAs > > Ihr meint sicher die U-Typen... AU ist die Gehäuseform. Ja klar. Ich meinte zum Beispiel den 128A3U. H.joachim Seifert schrieb: > @Knut: ich sehe mich in der Verantwortung meinen Kunden gegenüber. Und > ich bin nicht überzeugt, dass es die XMegas lange geben wird. Ich verstehe Deine Sorge, möchte aber auf die zusätzlichen Features und nicht notwendigerweise neue Entwicklungsumgebung hinweisen. Wenn Du Projekte hast, für die die Megas etwas zu knapp sind und Du keine Möglichkeiten hast, kurzfristig neue Architekturen in´s Team einzuführen, wirst Du den XMega zu schätzen wissen. Moby schrieb: > Als ASM-Programmierer bin ich nun auch bei den XMegas angekommen... Willkommen im Club ;-) Moby schrieb: > XMegas sind (als > U-Typen) inzwischen ein rundes Paket geworden: Alles drin was man > braucht, ein einfaches Design, das einfach programmierbar ist ! So sehe ich das auch. Der angenehm niedrige Stromverbrauch fällt dabei auch positiv in´s Gewicht.
Wenn ich das hier alles so lese, bin ich sehr froh, dass ich vor einigen Jahren mit dem PIC32 gestartet bin. Ich habe aber auch nichts dagegen, dass jeder mit ATMEL so glücklich wird, wie er kann.
OvO schrieb: > Wenn ich das hier alles so lese, bin ich sehr froh, dass ich vor einigen > Jahren mit dem PIC32 gestartet bin. Die bellen hier doch nur - die beißen bestimmt nicht.
OvO schrieb: > bin ich sehr froh Das ist letztendlich der Zustand den man dauerhaft anstreben sollte :-)
Wenn ihr da alle ein Problem mit dem Umstieg von einer zu anderen Architektur habt habt ihr in der Software das eigentliche Problem. Man trennt von Anfang an die eigentliche Software von den IO-Treibern. So braucht man wenn man einen anderen Type nimmt nur diesen Teil anzupassen und nicht die eigentliche Funktionalitaet. Dieses Konzept wird bei Betriebsystemen schon seit Jahrzehnten so gemacht.
Helmut, das erspart dir immer noch nicht die untere HAL Schicht neu zu implementioeren auf die neue Architektur und das ist tbh nicht allzu trivial. Das braucht auch bei bekannten Größen (mit schon recht starker Schichtung) schon mal Jahre bis Jahrzehnte. Siehe der Schritt weg von Wintel.
Der ATXmega ist eine große Enttäuschung. Ich hatte für ein Redesign den ATXmega128A1 ausgewählt. Ein riesen Theater bis alles lief, da hätte ich auch gleich einem ARM-Cortex nehmen sollen. Die sind in jeder Hinsicht besser und vor allem billiger. Bei der Flut von Cortex-uC wird sich der ATXmega preislich nicht halten können. Zumal der Aufwand einer Portierung von den alten ATmegas der gleiche ist. Der ATXmega hat mit den ATMegas nichts mehr zu tun. Hinterher ist man immer schlauer.
Jürgen schrieb: >> Wenn ich das hier alles so lese, bin ich sehr froh, dass ich vor einigen >> Jahren mit dem PIC32 gestartet bin. Have fun with that! PIC32 ist leider nur ein kläglicher Versuch am Markt mit 32 Bit Schritt zu halten. Wenn es eine Gefahr gibt, dass ein Produkt den Bach runter geht dann ist es der PIC32.
Also ich setze den XMega192A3 in einer industriellen Anwendung ein und hatte keinerlei Probleme. Es wird ein Großteil der Peripherie genutzt, unter anderem sammele ich mit 5 USARTS Messdaten von externen Geräten ein, was absolut problemlos funktioniert. Ich glaube nicht, dass ich bei meiner Anwendung mit einem anderem uC genauso gut klargekommen wäre. Also mein Fazit, der uC ist absolut einsetzbar! Gruß Johannes
Rughi schrieb: > Have fun with that! PIC32 ist leider nur ein kläglicher Versuch am Markt > mit 32 Bit Schritt zu halten. > Wenn es eine Gefahr gibt, dass ein Produkt den Bach runter geht dann ist > es der PIC32. Welche Glaskugel benutzt Du?
Peter schrieb: > Der ATXmega hat mit den ATMegas nichts mehr zu tun. Aha... - gleicher Befehlssatz (mit Erweiterungen) - gleiche Grundarchitektur (mit Erweiterungen) - gleiche Entwicklungsumgebung - sehr ähnliche Hardware-Interface Struktur Unterschied: - ATXMEGAs deutlich aufgeräumter als ATMEGAs - linearer Adressbereich für alle im Controller verankerte Hardware und Speicherformen - deutlich besseres Pinout - mehr Peripherie, günstiger Preis
Geht es in jedem Thread jetzt nur noch darum welcher µC besser ist?
Netter Thread, 99,9% substanzloses Geschwafel von Marketinggläubigen. Das wenige was belegbar ist und nachprüfbar ist korrigiert nur die schlimmsten Auswüchse von Ahnungslosigkeit und Markenfetischismus. Für Verfügbarkeit ist übrigens die wirtschaftliche Entwicklung eines Unternehmens das wichtigste Kriterium. Davon steht hier nicht ein einziges Wort. Für den größten Teil der "Fanpost" hier kann man sich nur fremdschämen und ärgern auf einer Seite die mit Anhängern einer Marke überfüllt ist zu versuchen etwas sachliches zu lesen.
Knut Ballhause schrieb: > - gleicher Befehlssatz (mit Erweiterungen) na und? Was nützt mir das in C? Kein Register ist mehr wie es war. > - gleiche Grundarchitektur (mit Erweiterungen) Wen interessiert das? Ob das ein Vorteil ist, ist auch fraglich. > - gleiche Entwicklungsumgebung Welche mit dem AVRStudio 6 eine Katastrophe ist. > - sehr ähnliche Hardware-Interface Struktur aber nur ähnlich. Siehe z.B. Timer. Den darf ich jetzt immer abschalten. Du hast vergessen: - beschissenes Datenblatt. Da fehlt alles. Man kann ich das nötige aus den Application Notes oder aus den C-Libraries zusammen reimen. Nimm das nicht persönlich, aber ich kann das Teil nicht leiden. Ich bin froh, wenn ein Redesign kommt. Dann ziehe ich komplett um.
Peter schrieb: > Du hast vergessen: > > - beschissenes Datenblatt. Da fehlt alles. Kann es sein, dass du vergessen hast, dir das "family datasheet" anzusehen? Also für einen ATxmega256A3 zuallererst das Datenblatt des Xmega A ansehen. Warum sie im "device datasheet" noch solche blöden ein- oder zweiseitigen "Platzhalter-Kapitel" drin haben und nicht einfach nur die (wenigen) tatsächlich device-spezifischen Angaben, erschließt sich mir auch nicht. Die Platzhalter-Kapitel da drin kann man komplett in die Tonne kloppen.
hexe schrieb: > Rughi schrieb: >> Have fun with that! PIC32 ist leider nur ein kläglicher Versuch am Markt >> mit 32 Bit Schritt zu halten. >> Wenn es eine Gefahr gibt, dass ein Produkt den Bach runter geht dann ist >> es der PIC32. > > Welche Glaskugel benutzt Du? Ich denke mal man muss da zwischen Hobby- und Geschäftsbereich unterscheiden. Unter Hobbybastlern in der Tat kaum verbreitet setzt u.A. BMW zur Zeit PIC32 vermehrt ein. Ich glaube kaum, dass da irgendwas ausstirbt.
Hier im Forum gab es ausserdem die Aussage/das Gerücht, das Microchip seit Jahren profitabel wäre, während bei Atmel die Bilanzen ein anderes Bild ergeben.
Frau Holle schrieb: > Du bist wohl noch kein gebranntes Kind? > > Ich erinnere mich noch zu gut an die Abkündigungen, horrenden > > Lieferzeiten und 50% Preiserhöhungen vor wenigen Jahren. Seitdem ist > > ATMEL ein absolutes no go! Das gleiche hier mit den Lieferzeiten bzw. manche Typen gabs einfach nicht mehr für Monate ohne Info wie es weitergeht, das hat richtig Geld und Zeit gekostet. Auch hier ein absolutes no Go.
Peter schrieb: > Du hast vergessen: > > - beschissenes Datenblatt. Da fehlt alles. Man kann ich das nötige aus > den Application Notes oder aus den C-Libraries zusammen reimen. Die Datenblätter, Manuals und Application Notes enthalten alles, was man wissen muss. Bei speziellen Fragen gibt es auch User-Foren oder den ATMEL-Support. Peter schrieb: > Nimm das nicht persönlich, Mach ich nicht, nur dass ich andere Erfahrungen habe als die, die Du beschreibst. Peter schrieb: > aber ich kann das Teil nicht leiden. Das wird es sein. Der Rächer der Transistormorde schrieb: > Netter Thread, 99,9% substanzloses Geschwafel von Marketinggläubigen. Der Rächer der Transistormorde schrieb: > Für Verfügbarkeit ist übrigens die wirtschaftliche Entwicklung eines > Unternehmens das wichtigste Kriterium. Ich gründe meine Ausführungen lediglich auf eigene Erfahrungen. Wie gesagt, wir arbeiten mit den Teilen und es gibt mehr als einen Distributor in Deutschland und dem Rest der Welt. Die von uns benötigten Stückzahlen habe ich immer erhalten. Da gab es eher mal eine problematische Zeit um 2010, was Speicher, insbesondere FLASH anging. Der Rächer der Transistormorde schrieb: > Davon steht hier nicht ein > einziges Wort. Doch, ab hier: Beitrag "Re: News aus der Atmel Gerüchteküche" Bitte lesen, dann posten.
Uwe Bonnes schrieb: > Hier im Forum gab es ausserdem die Aussage/das Gerücht, das Microchip > seit Jahren profitabel wäre, während bei Atmel die Bilanzen ein anderes > Bild ergeben. Das ist auch richtig, nur ist es immer ein Blick in die Vergangenheit. Wahrscheinlich meinst du diesen Beitrag: Beitrag "Markteinschätzung ATMEL" Es ging da um eine Analyse als Antwort auf die BanksterBranche. Microchip habe ich nur als Vergleichswert aus der Branche genommen da sehr ähnlich aufgestellt. Um sich ein Bild zu machen taugt das ganze nur als Baustein. Apple war ewig Pleite, so Pleite das es sogar von Microsoft gestützt wurde und heute .... Das Risiko das Produkte eingestellt werden ist überall vorhanden. Jubelarien von Fans über Marketingaussagen halte ich aber für naiv bis dämlich. Wenn es dann kracht sind Sie meist die größten Hasser und haben es immer schon gewusst. Mein Merksatz, so lange sich eine Firma nicht für mich interessiert ist Sie mir auch egal. Das man zu den blödsinnigsten Sachen Beziehungen entwickeln, das ist menschlich wird aber nicht erwidert. Ich mach das lieber mit natürlichen Personen ;-). Als kleine Übung schlage ich vor das sich jeder der sich über "andere" µCs echauffiert bzw. die "eigenen" lobt erstmal mit beiden arbeitet. Die Unterschiede sind so marginal das die menschliche Mustererkennung "Bilder in den Wolken" sieht.
Knut Ballhause schrieb: > Frau Holle schrieb: >> Seitdem ist >> ATMEL ein absolutes no go! > > Schüttel Du nur Deine Betten... ;-) Ja, mit einem Grinsen im Gesicht. Denn ich habe aus der Geschichte gelernt... :-)
Zu einem guten MC System gehört auch ein guter Programmierer! Wird meistens vergessen :-)
Frau Holle schrieb: > Ja, mit einem Grinsen im Gesicht. Denn ich habe aus der Geschichte > gelernt... Nun ich habe etwas anderes gelernt. Es gab immer mal Probleme mit Herstellern, teilweise richtig linke Dinger. Die haben wir dann rausgeschmissen und andere genommen. Hat aber nichts genutzt, einige sind weg, ob nun gut oder schlecht. Die anderen haben gelernt. Die Branche ist erwachsen, heute sind alle im Schnitt gleich. Das was "damals" war zählt nicht mehr und die Hersteller teilen kleinere Märkte untereinander auf. Der eine macht das, der andere dafür jenes.
Jens Martin schrieb: > Jubelarien von Fans über Marketingaussagen halte ich aber für naiv bis > dämlich. Fan einer Fußballmannschaft zu sein kostet nix, bevor man aber zum Fan einer MC Architektur wird hat man in aller Regel schon recht intensiv und erfolgreich damit gearbeitet und weiß, worüber man spricht.
noname schrieb: > Jens Martin schrieb: >> Jubelarien von Fans über Marketingaussagen halte ich aber für naiv bis >> dämlich. > > Fan einer Fußballmannschaft zu sein kostet nix, bevor man aber zum Fan > einer MC Architektur wird hat man in aller Regel schon recht intensiv > und erfolgreich damit gearbeitet und weiß, worüber man spricht. Das eine schließt das andere ja nicht aus ;-).
Nö. Jubelarien von Fans über Marketingaussagen gibts hier ganz einfach nicht. Höchstens wenn sich die Marketingleute selbst als Anwender ausgeben.
Alles Käse :-) Ich habe für die nächste Zeit die STM32 ausgewählt, weil mir Atmel einfach keinen RAM verkaufen wollte. Zwischenzeitlich habe ich was auf dem ATXmega128A3 zu tun, natürlich mit ADUs und EEPROM ... stöhn... Die Doku und die Appnotes tragen nicht unbedingt zum Erfolg bei. Atmegas/Attinys nehme ich aber nach wie vor gerne. Gruß, Holm
Hi
>Die Doku und die Appnotes tragen nicht unbedingt zum Erfolg bei.
Scheint noch jemand das passende Family-Manual nicht gelesen zu haben.
MfG Spess
Ich glaub ja das Frau Holle bei Microchip oder einem Ihrer Disti's arbeitet. Woher weiß Sie sonst, dass ein deutscher Autohersteller (der Autohersteller tut mirt übrigens leid) den Baustein einsetzt? Ich glaube diese Foren werden geziehlt von den Herstellern unterlaufen um Stimmung und Meinung zu machen. Sehr schade. Bzgl. der Profitabilität von Atmel und deren Solidität habe ich keine Zweifel auch nicht an der von Microchip. Beide sind solide im Geschäftsmodel, wenn man das mal mit den anderen großen vergleicht, die nur an Staatsgeldern hängen. Der Thread heisst im übrigen XMEGA, also wieso schreibt hier jeder mit, der sich nicht dafür interessiert? Schert Euch in die anderen Foren und tragt was positives bei! Wie gesagt, hier sind ne Menge Meinungsmacher drin. Das macht so keinen Spass.
Spess53 schrieb: > Scheint noch jemand das passende Family-Manual nicht gelesen zu haben. Ich glaube, der ärgert sich gerade mehr mit einem Errata-geplagten Modell 'rum. Im Vergleich zu den klassischen MegaAVR und TinyAVR sind die Xmegas in dieser Hinsicht ja nicht gerade die großen Leuchten (zumindest die etwas älteren). :-/
Rughi schrieb: > Ich glaub ja das Frau Holle bei Microchip oder einem Ihrer Disti's > arbeitet. Woher weiß Sie sonst, dass ein deutscher Autohersteller (der > Autohersteller tut mirt übrigens leid) den Baustein einsetzt? > Ich glaube diese Foren werden geziehlt von den Herstellern unterlaufen > um Stimmung und Meinung zu machen. Sehr schade. Ich muss Dich leider enttäuschen. Ich bin nur ein ganz normaler Anwender, der vor einigen Jahren noch zwischen 3K und 5K von Atmel µCs pro Jahr eingesetzt hat. Also mehr als ein Hobbyist und deutlich weniger als ein Kunde, der einem Hersteller etwas Wert ist. Und das war daher nicht angenehm. Dein Glauben ist nicht Wissen, oh großer Rughi. Und mich für Deinen Glauben zu missbrauchen ist mächtig daneben! Daher wünsche ich Dir eine gute Besserung!
@FrauHolle, Ich frag mich halt nur, was die Leute, die Atmel nicht mögen in einem Forum machen, dass Neues aus der Atmel Gerüchteküche heisst. Ich versteh das nicht. Ein positiver Ansatz kann es nicht sein...
Rughi schrieb: > @FrauHolle, Ich frag mich halt nur, was die Leute, die Atmel nicht mögen > in einem Forum machen, dass Neues aus der Atmel Gerüchteküche heisst. > Ich versteh das nicht. Hinweis für Rughi: Das liegt daran, dass das Forum "µC & Elektronik" heißt.
>Yep, 2x 12bit bei je 2msps und gain stage, oversampled auf 16bit >Aber nehm die neueste version, zb atxmega128a1u Also, wenn ich jetzt mal ins Datenblatt des ATXMEGA128a1u schaue http://www.atmel.com/Images/doc8385.pdf finde ich auf Seite 121 0,4mVeff Rauschen bei Vref=1V. Das ergibt nach der üblichen Rechnung einen Spitzenwert vom 3,3-fachen, also rund 1,3mVs. Und das sind dann nur noch 9,5bit, statt 12bit. Auf Seite 123 finde ich das Rauschen der "analog comparator hysteresis" von rund 30mVeff, also rund 100mVs. Ist das nicht ein wenig viel? Auf Seite 124 findet man sogar noch größere Werte. Auf Seite 126 finde ich, daß die 1V Bandgapreferenz zwischen 5°C und 35°C um 6mV schwankt. Das sind 25LSB bei 12bit. Das ist die Qualität von einem 7bit Wandler. In den Erratas habe ich schließlich noch das hier gefunden: "14. ADC is non-functional in SE unsigned mode with VREF below 1.8V. When the ADC is used on single ended unsigned mode and VREF is below 1.8V, INL and DNL error is increased above +/- 10LSB, i.e. the ADC have missing codes under this condition. 15. ADC has increased linearity error when using the gain stage above 500ksps. The INL error for gain stage is increased to above 20LSB for sampling speed exceeding 500 ksps. 16. DAC Offset calibration range too small when using AVCC as reference. If using AVCC as reference, the DAC offset calibration will not totally remove the offset error. Offset could be up to 100LSB after calibration. ... 18. Internal 1V reference has noise at low temperature. The internal 1.0V reference for the ADC and DAC has increased noise at low temperatures. The noise can result in INL numbers up to +/- 20 LSB at temperatures below 0C." Ich werde wohl noch etwas warten, bis ich den XMEGA mit seinem "12bit"-Wandler einsetze...
Jürgen schrieb: > Hinweis für Rughi: Das liegt daran, dass das Forum "µC & Elektronik" > heißt. Mit der Überschrift: "Re: News aus der Atmel Gerüchteküche" Wenn ich die MCHP toll finde gehe ich doch zu denen ins Forum oder?
Rughi schrieb: > Wenn ich die MCHP toll finde gehe ich doch zu denen ins Forum oder? Also ich nicht.
Rughi schrieb: > Wenn ich die MCHP toll finde gehe ich doch zu denen ins Forum oder? Dafür verwechselst du hier die ganze Zeit einen Thread mit einem Forum ... lass' mal gut sein. Es haben Leute ihre Meinung kund getan, dass sie selbst keine Xmegas benutzen wollen. Das mögen sie tun, und damit ist's dann aber wieder gut. Die, die das nicht wollen, muss niemand evangelisieren, und sie mögen die, die auch weiterhin Xmegas benutzen wollen, von länglichen Diskussionen verschonen.
Kai Klaas schrieb: > Also, wenn ich jetzt mal ins Datenblatt des ATXMEGA128a1u schaue Dann nimm doch den: http://www.atmel.com/Images/doc8386.pdf
Jürgen schrieb: > Rughi schrieb: > >> In der Presse kann man lesen, dass die meisten Android Smartphones einen > >> Atmel Micro drin haben (Samsung, HTC), das will was heißen. Die können > >> sich nicht leisten Schrott einzubauen. > > > > Gibt es eine Quelle/Link oder nur erfunden? Ich würde einen speziellen Touch-Controller jetzt nicht mit den gängigen µC-Familien von Atmel vergleichen. Atmel hat in diesem Nischengeschäft halt Geld investiert und Glück gehabt. Aber jetzt daraus Rückschlüsse auf die XMega-Familie zu schließen finde ich zu weit hergeholt.
*** Live von der electronica *** Der neue XMega E5 kommt als 8/16/32 KB Flashvariante in TQFP32 Gehäuse im Q1/13 auf den Markt. Weitere Daten u.a. : SRAM 1/2/4 KB, EEPROM 0.5/1/1 KB, 1 SPI, 1 TWI, 2 USART, 12 PWM, 16 ADC, 2 DAC, 26 I/Os
Moby schrieb: > SRAM 1/2/4 KB, EEPROM 0.5/1/1 KB, 1 SPI, 1 TWI, 2 USART, 12 PWM, 16 ADC, > 2 DAC, 26 I/Os das ist noch nix, ein Atmel MA zeigte mir noch paar neue nette Features die das Leben leichter machen. CPLD Modul mit Lookup Table, asynchrones Event System welches auch im Sleep Mode funktioniert (endlich kann ich meinen Manchester Code in HW realisieren) und ADC/DAC mit hardware kalibrierung von Offset/Gain. Ich fand speziell die neuen Timer interessant für Motor Control und Lighting. Im PowerDown Modus mit SRAM Retention und RTC soll er nur 100nA verbrauchen und einen neuen internen 8MHz RC mit 1% Genauigkeit über den ganzen Temp.Bereich haben. Ich hab eines der ersten Xmega E Xplain Kit ergattert, lege gleich los :) Übrigens es gibt News vom Atmel Studio 6, das neue Studio erhielt eine Gallery bei der man den Keil Compiler und CodeVision integrieren kann, außerdem paar nette neue Tools wie FreeRtos Integration. Ich lade mir gerade die neue Version herunter und schau mal was es sonst noch neues gibt.
Das klingt doch schon mal gut! Werde mich am Donnerstag gleich selbst davon überzeugen.
XMaegas - viel zu wenig ROM/RAM und zu langsam. Warum schaffen aktuelle ARM mocros 1,2GHz und mehr? Habe mich vor kurzem auch gewundert, warum ein mega644 oder mega1248 nur 20MHz schafft?
Boah, ey! Mein neuer Octocoredreikommazwosiebenviergigahertzsuperdupermultiprotz is' ja sowas von geil! Damit kann ich sogar 'ne LED blinken lassen! Oder: Die Kunst besteht darin, mit wenig Ressourcen und Energie viel zu erreichen.
Bandalf Glase von Stettenbroich schrieb: > XMaegas - viel zu wenig ROM/RAM und zu langsam. Warum schaffen aktuelle > ARM mocros 1,2GHz und mehr? Habe mich vor kurzem auch gewundert, warum > ein mega644 oder mega1248 nur 20MHz schafft? Du bist eben ein Spitzenmann, mit hohen Ansprüchen und kannst dich noch wundern.
Bandalf Glase von Stettenbroich schrieb: > ARM mocros 1,2GHz und mehr? Habe mich vor kurzem auch gewundert, warum > ein mega644 oder mega1248 nur 20MHz schafft? Wozu würdest du einen 1GHz Mega16 benötigen? Pingewackel kanns nicht sein, denn das machen die Pins nicht mit. Jedenfalls nicht Pins wie du sie gewohnt bist.
Christian schrieb: > das ist noch nix, ein Atmel MA zeigte mir noch paar neue nette Features > die das Leben leichter machen. CPLD Modul mit Lookup Table, asynchrones In Hardware oder auf dem Papier? Ich verbinde mit Atmel "announce early, release never"...
>> Ich verbinde mit Atmel "announce early, release never"...
Wo hat Atmel denn announced? Ich find nix.
Stefan
Bandalf Glase von Stettenbroich schrieb: > Warum schaffen aktuelle > ARM mocros 1,2GHz und mehr? Weil sie nicht aus einem Flash-ROM arbeiten. Der ist das primär limitierende bei einem Controller, nicht der Core. Beim Flash ist so bei reichlich 30 MHz das Ende der Fahnenstange erreicht (was der Grund für die 32 MHz des Xmega sein dürfte); mit paar Tricks (Interleaving) kann man das dann vielleicht nochmal verdoppeln (sieht man bei vielen ARM-basierten Controllern). p.s.: Bitte keine unsinnigen email-Adressen angeben. Das nützt keinem was. Wenn du keine angeben willst, weil du nicht an automatischen Mails des Forensystems interessiert bist, dann lass' das Feld frei.
Jörg Wunsch schrieb: > Beim Flash ist so > bei reichlich 30 MHz das Ende der Fahnenstange erreicht Warum funktionieren die neuen U-Typen dann teilweise bis hinauf zu 64 MHz?
Lars schrieb: > Warum funktionieren die neuen U-Typen dann teilweise bis hinauf zu 64 > MHz? Jörg Wunsch schrieb: > mit paar Tricks (Interleaving) > kann man das dann vielleicht nochmal verdoppeln
Lars schrieb: > Warum funktionieren die neuen U-Typen dann teilweise bis hinauf zu 64 > MHz? Hängt damit zusammen, dass die EU-Bananenverordnung wieder abgeschafft wurde; seitdem geht das. Bitte Jörgs Post nochmal lesen.
Jürgen schrieb: > Quelle? Link? Jürgen schrieb: > Gibt es eine Quelle/Link oder nur erfunden? Also der Jürgen ist mir ja ne stinkfaule Socke. Selbst suchen macht schlau!
Moby schrieb: > Als ASM-Programmierer bin ich nun auch bei den XMegas angekommen > und sehe auch für die weitere Zukunft kein Projekt, wo ich deren > Leistungsfähigkeit jemals ausschöpfen könnte. Bei Nicht, dass ich etwas gegen Atmel hätte, aber eine Frage an dich sei mir erlaubt: Deine Projekte sind schon etwas komplexer, als die Entwicklung einer Herduhr?
Jörg Wunsch schrieb: > Weil sie nicht aus einem Flash-ROM arbeiten. Abhilfe: RAM für Programm und Bootloader aus Flash/EEPROM. Gab es beim AT91RM3400 und auch bei einem etwas vereinzelten AVR.
Jörg Wunsch schrieb: > Weil sie nicht aus einem Flash-ROM arbeiten. Der ist das primär > limitierende bei einem Controller, nicht der Core. Beim Flash ist so > bei reichlich 30 MHz das Ende der Fahnenstange erreicht (was der Grund > für die 32 MHz des Xmega sein dürfte); mit paar Tricks (Interleaving) > kann man das dann vielleicht nochmal verdoppeln (sieht man bei vielen > ARM-basierten Controllern). Wie ist das bei den Cortex-M Kernen? z.B. gibt es von ST welche die mit mit 36...168 MHz laufen, bei LPC weiss ich von einem der mit 50 MHz läuft. Haben die dann viele Waitstates wenn Code direkt aus dem Flash ausgeführt wird und so auch effektiv nicht mehr wie ca. 30 MHz??
Beim ST32F4 und 168MHz und 3.3V hat der Flash 5 Wait States. Allerdings gibt es ein Prefetch und linearer Code resultiert in 0 Wait States. Ausserdem kann man Code auch im RAM ohne Waitstates ausfuehren
ReinerWäschtKeiner schrieb: > schon etwas komplexer, als die Entwicklung einer > Herduhr? Wär auch mal ne Idee :-) Mach viel mit MSR für Heim und Hof, inklusive Internetanbindung. Glaub mir, das ist komplex genug, die Projekte in ASM ziehen sich (neben dem Job) oft viele Monate. Der XMega ist dafür optimal geeignet.
>Beim Flash ist so bei reichlich 30 MHz das Ende der Fahnenstange erreicht Nö. >Wie ist das bei den Cortex-M Kernen? Kommt auf Hersteller an.
Moby schrieb: > Mach viel mit MSR für Heim und Hof, inklusive Internetanbindung. > Glaub mir, das ist komplex genug, die Projekte in ASM ziehen sich (neben > dem Job) oft viele Monate. Der XMega ist dafür optimal geeignet. > > Sind die Stückzahlen wirklich so gross, dass sich der Aufwand für Assembler rechnet. Warum nicht einen grösseren Baustein und in C programmieren?
MCUA schrieb: >>Beim Flash ist so bei reichlich 30 MHz das Ende der Fahnenstange erreicht > Nö. Wo liegt denn die Grenze etwa?
Uwe Bonnes schrieb: > Warum nicht ... in C Also was die Vor/Nachteile von C vs. ASM betrifft möchte ich mal auf einen der gefühlt zehntausend Threads zu diesem Thema verweisen. Ansonsten darf sich der Privatmann doch die Freude und den Spaß erlauben, Hard- mit hochoptimierter ASM-Software zu einem perfekten Gesamtkunstwerk zu vereinigen! Mit wachsenden, wiederverwendbaren Codebasis gelingt dies über die Jahre auch immer schneller.
>Wo liegt denn die Grenze etwa?
ST,NXP, Freescale haben ca 25-30 MHz, Fujitsu hat 72 MHz, TI 80 MHz,
Toshiba 100MHz, Renesas 100MHz und mehr.
MCUA schrieb: > Fujitsu hat 72 MHz, TI 80 MHz, > Toshiba 100MHz, Renesas 100MHz und mehr. Und du bist dir sicher, dass das keine Varianten mit Interleave sind?
Jörg Wunsch schrieb: > Und du bist dir sicher, dass das keine Varianten mit Interleave sind? Die Renesas Flash' (MONOS-Flash) haben eine Zugriffzeit von <10ns - definitiv. Die RX600-Serie hat diese auf dem Chip. Demnächst sind Versionen mit 120MHz ohne Wartezyklen erhältlich.
Fujitsu FM3 laut Flash Programming Manual: - 60MHz 0WS, - 80MHz 2WS, aber 0WS wenn sequentiell. Das deutet darauf hin, dass es bis 60MHz echte 0WS sind.
Weitere Information dazu: http://www.elektroniknet.de/bauelemente/technik-know-how/halbleiter/article/26150/0/MONOS-Flash_ohne_Wartezyklen/
A. K. schrieb: > Das deutet darauf hin, dass es bis 60MHz echte 0WS sind. Was zu der im MONOS-Flash-Dokument genannten Verdoppelung der Geschwindigkeit gegenüber herkömmlichem Flash passen würde.
>Und du bist dir sicher, dass das keine Varianten mit Interleave sind? Wenn der Herst. sagt, es ist Single-Cycle-Flash, dann redet er ja nicht über irgentwelches LogicZeugs hintendran, sondern übers Flash und nur übers Flash. (und deswegen nat. auch für ne beliebige Adresse ausm Flash, free access) (und Fujitsu schreibt diesbez 72 MHz) (TI-Mitarbeitern war (auf der Messe) die Bedeutung schnellen Flashs nichtmal bewusst. Der sagte laut deren 'Marketing' wäre das völlig egal. haha. Und das obwohl die da ja rel. gut sind.) >Was zu der im MONOS-Flash-Dokument genannten Verdoppelung der >Geschwindigkeit gegenüber herkömmlichem Flash passen. Es interressiert ja nicht wie es heisst, sondern nur, was es abliefern kann. (Sollte Atmel mit sonem gekauften Flash nicht mal seine AVRs mit >=100MHz rennen lassen???)
neue Info zur E-Serie: caxapa.ru/thumbs/361093/XMEGA_E_MANUAL.pdf
:
Wiederhergestellt durch Admin
Schon beim alten Silabs 8051 hat man sich zu helfen gewußt, wie man 100MHz schafft, obwohl der Flash nur 25MHz kann: "The C8051F12x and C8051F13x device families incorporate a 63x4 byte branch target cache with a 4-byte prefetch engine." Ist also kein Hexenwerk. Peter
@Christian Wie gehts denn so mit dem XPlained Board? Ich würd ja gern schon mal mit dem Design eines XMega-E Projekts beginnen- nur findet sich leider im Netz immer noch keine Pinbelegung. Kannst Du die bitte mal hier posten? Warum sich Atmel mit der Veröffentlichung auf deren Webseite soviel Zeit lässt kann ich irgendwie nicht nachvollziehen. Nicht nur daß der E5 auf der electronica schon längst präsentiert wurde, auch in der Doku zum aktuellen Studio wird er ja an diversen Stellen erwähnt. Albern sowas. Grüße, Max
Hallo, da ne Frage zum Eventsystem auftauchte, hier nen praktisches Beispiel: Ein IC braucht ein SPI das die Daten bei fallender und steigender Flanke sendet. Nun könnte man nen D Flipflop am Clockausgang nachschalten oder Software SPI. Noch besser aber mit Hilfe des Eventsystems ein Event bei Flankenwechsel der Clockleitung auszulösen. Diesen nun auf den Timereingang zum raufzählen. Noch den Compareausgang am passenden Port freischalten und schon ist man absolut sync. zum SPI Takt nur mit halber frequenz. Jetzt noch die Daten per DMA reinspielen. Klasse... bis hier hin noch keinen Prozessor benutzt und sauberer Datendurchsatz für nen 8 Bitter der bei Mouser keine 3 € kostet... Grüße Zedd
Achso, freu mich auf den E Type... Weiß schon wer welche Packages es genau geben wird?
Zedd schrieb: > Achso, freu mich auf den E Type... Habe gerade einen ersten bestätigten Liefertermin erhalten. Im Oktober...
Ist ja witzig. Laut dem Datenblatt von der russischen Seite vom E Type gibts jetzt ein wenige FPGA feeling im XMega.... XCL - XMega Customer Logic... Da kann man genau das machen was ich oben schon mit dem Event System und nem Timer Compare gemacht habe, nämlich einfach mal nen D Flip Flop an den SPI Clockausgang.... Sehr gut! =)
Da lese ich doch von einem Interview mit CEO Steven Laub. Sinngemäß soll Atmel für 32 Bit primär in ARM investieren und 8 Bit AVR bleiben.
Bezüglich des gelöschten Beitrags: sowas bitte als separaten Thread in Off-Topic posten. In ein technisches Forum gehört der Börsenkram nicht 'rein.
Angehängte Dateien:
-
pinout.png
84 KB -
portac.png
83 KB -
portrd.png
61 KB
Atmel hat es immer noch nicht geschafft, für den seit über einem halben Jahr bekannten XMega-E5 konkrete Infos verfügbar zu machen. Um dem einen oder anderen trotzdem schon mal den Start eines Projekts zu ermöglichen hier die Pinbelegung! Gruß Doris
Inzwischen gibt es detaillierte Infos und auch die "XMEGA-E5 Xplained" Evaluationtools bei einigen Distris. Hab mal eins bei Mouser geordert. Die Steine selbst sollen ab September im Handel erscheinen. Datenblätter und Manuals wie immer bei ATMEL. Im Übrigen hat es bei vielen XMEGAs massive Preissenkungen gegeben. So kostet ein XMEGA16A4U-MU ab 100 Stück nur noch 1.35EUR, ein ATXMEGA128A3U-AU nur noch 2.23EUR ab 100 Stück.
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.