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?
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.
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.
>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
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.
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!
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.
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
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...
:-)
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 ;-).
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
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?
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.
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.
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"...
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.
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?
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.
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.
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???)
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
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! =)
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.