MCUA schrieb: > Die CPU ist seit Urzeit 1997 unverändert! Du bist ja prima im Bilde. :-) > Die hatten das wohl aus Norwegen gekauft, und nie mehr angerührt. "Gekauft" ist gut. Die Norweger haben damit Atmel völlig umgekrempelt. Aus einem Laden, der (neben einem Sammelsurium anderer Dinge) vor allem Flash-Speicher hergestellt hat, ist nun ein Microcontroller-Laden geworden. > Warum nicht ein paar Bits mehr im OP-code? Weil es dann kein AVR mehr wäre. Das ist ein 8/16-bit-Prozessor, und daher ist der Opcode eben auch 16 bit breit. Den Versuch mit dem "Alternativ-ARM" (aka. AVR32) hat's ja gegeben, aber der ist halt nicht so zum Fliegen gekommen, wie der gute alte AVR-Kern. ARMs bekommt man ja (neben den Xmegas) von Atmel ebenso, wenn man das will.
>vor allem Flash-Speicher hergestellt hat, aber auch 51er >Weil es dann kein AVR mehr wäre. Und? Aber ein (kompatibler) AVR2. >Das ist ein 8/16-bit-Prozessor, und >daher ist der Opcode eben auch 16 bit breit. 16 bit breit, toll >ist nun ein Microcontroller-Laden geworden ja, aber keine Microcontroller-Firma
MCUA schrieb: >>Weil es dann kein AVR mehr wäre. > Und? > Aber ein (kompatibler) AVR2. Was wäre da noch kompatibel, wenn man die Wortbreite ändert? Microchip macht das ja so. Da gibt es verschiedene Wortbreiten und wenn man von einer Familie zur anderen wechselt, muss man sich total umstellen, braucht häufig neue Compiler etc. Beim AVR hat man vom kleinsten Tiny bis zum größten XMEGA (fast) den gleichen Befehlssatz, vom Hardwaremultiplier einmal abgesehen. Daher kann man auch immer dieselbe, vertraute Toolchain verwenden. Ich persönlich sehe das als Vorteil. Auch das da in den vielen Jahren nichts geändert wurde. Andere sehen das anders, sonst gäbe es die PICs ja sicher nicht mehr.
Jörg Wunsch schrieb: > ARMs bekommt man ja (neben den Xmegas) von Atmel ebenso, > wenn man das will. Bin mal gespannt, wer auf Dauer die Oberhand behält? Vor AVR waren die 8051 das Zugpferd. Jetzt sind es nur noch Statisten. Aktuell kümmert man sich um M0 und M0+. ;-)
ARM dran schrieb im Beitrag #3620403: > Bin mal gespannt, wer auf Dauer die Oberhand behält? Vor AVR waren die > 8051 das Zugpferd. Jetzt sind es nur noch Statisten. Aktuell kümmert man > sich um M0 und M0+. ;-) Ich arbeite mit den verschiedensten Controller, habe aber einen Schwerpunkt bei AVR und ARM. Für ein aktuelles Projekt benötige ich 2-4 interne DACs (externe DACs per SPI ist zu langsam, außerdem benötigen diese zu viel Platz). Aktuell bin ich daher bei den XMegas (64A1U - kostet bei 1k +- 2 EUR) gelandet, würde aber aus Gründen der Zukunftssicherheit gerne auf M0/M3 wechseln. Kennt jemand entsprechende Modelle? NXP bietet maximal 1 DAC an.
>Für ein aktuelles Projekt benötige ich 2-4 interne DACs
STM32F103 Serie hat 2 DAC's aber erst im 100pol. Gehäuse soweit ich
weiss.
4 DAC's hat nur AD in der ADUC7xxx Serie. Ist aber kein Arm-Cortex
sondern Arm7. Wobei ich den Eindruck habe, dass AD die ADC's und DAC's
am besten hinbringt, aber auch halt etwas teurer ist.
Grüsse
>Was wäre da noch kompatibel, wenn man die Wortbreite ändert?
Der ASM-Befehlssatz könnte ja rückwärts-kompatibel bleiben, nur halt
erweitert. Der Obj-code müsste (weil Embedd) nicht der gleiche sein.
(es gibt ja mehrere Architekturen, die so erweitert wurden, (bsp auch
X86 (sogar mit gleichem Obj-code)).
MCUA schrieb: >> Was wäre da noch kompatibel, wenn man die Wortbreite ändert? > Der ASM-Befehlssatz könnte ja rückwärts-kompatibel bleiben, nur halt > erweitert. Und, wer braucht das (außer dir, wobei du nicht schreibst, wofür du es brauchst und wie viele Millionen Stück du dann kaufen willst)? Ehrlich, bei der Konkurrenz aus dem Cortex-M-Bereich ist es doch völlig nutzlos, sich noch Gedanken um eine weitere 8/16-Bit-Architektur zu machen. Die, die es gibt, tun, was sie sollen, und wer mehr braucht, würde sich kaum noch in eine neue Familie einarbeiten wollen.
>Und, wer braucht das Na (fast) alle, die den AVR noch weiter benutzen wollen, und es gibt anscheind viele davon.
MCUA schrieb: > Na (fast) alle, die den AVR noch weiter benutzen wollen, und es gibt > anscheind viele davon. Da du wohl nicht dazu gehörst, warum glaubst du, für andere sprechen zu müssen?
DisplayFreak schrieb: > Ich arbeite mit den verschiedensten Controller, habe aber einen > Schwerpunkt bei AVR und ARM. Für ein aktuelles Projekt benötige ich 2-4 > interne DACs (externe DACs per SPI ist zu langsam, außerdem benötigen > diese zu viel Platz). Aktuell bin ich daher bei den XMegas (64A1U - > kostet bei 1k +- 2 EUR) gelandet, würde aber aus Gründen der > Zukunftssicherheit gerne auf M0/M3 wechseln. Kennt jemand entsprechende > Modelle? NXP bietet maximal 1 DAC an. Warum machst Du Dir sorgen? Atmel gibt 12Jahre Lifetime commitment auf alle AVR, dazu haben sie ja gerade erst Automotive Variante qualifiziert. So eine Investition tätigt man nicht wenn man keine Kunden hätte. Automotive = langjährige Verfügbarkeit. Weiterhin sind die AVR auch in externen Fabs qualifiziert, sowas braucht man dann heute nicht mehr abzukündigen oder Die bank vorhalten. Man geht zu UMC oder TSMC und bestellt die Produktion nach. Xmega sind wirklich gut von der Peripherie, 2 unabhängige DAC Kanäle mit DMA, 1Msps, Register für Kalibrierung, versch. ext. Outputs, versch. Referenzen wie VDDDA,1V,2xExt, max INL von +-2.5 und einer Resistive Load von 1Ohm. Der SAMD20 hat auch zwei Kanäle und der DAC ist dem des Xmega sehr ähnlich hat leider nur einen DAC Kanal bekommen und die DAC sind etwas langsamer, aber wenn du auf SAM4S schaust gibt es immerhin 2 DAC Kanäle. Es gibt schon gründe warum Atmel weiter in Xmega investiert, z.b. solche Features die es in der Form nicht so oft gibt. Meine Meinung dazu
Was auf der EmbeddedSystems '97 einige mit
AutomatischerVerstärkungsRegelung benannt haben, hat sich bis heute kein
bisschen weiterentwickelt!
>Xmega sind wirklich gut von der Peripherie...
Ja?
"The SPI module is unbuffered in the transmit direction.."
Hi, Andreas schrieb: > Weiterhin sind die AVR > auch in externen Fabs qualifiziert, sowas braucht man dann heute nicht > mehr abzukündigen oder Die bank vorhalten. Man geht zu UMC oder TSMC und > bestellt die Produktion nach. "[...]AVR auch in externen Fabs[...]" DER war gut. ;-) Atmel ist bei den AVR (bzw. im gesamten µC Bereich???) wieder wie zu seinen Anfangszeiten ein reiner Fabless-Konzern geworden. Da läuft ALLES über die Fertigungsdienstleister. Mit den entsprechenden Vorteilen, vor allem aber mit den erheblichen Nachteilen die das so mit sich bringt. Den im gegensatz zu dem was manche hier zu glauben scheinen erhöht dies nicht die Liefersicherheit, sondern verringert diese erheblich was die immer wiederkehrenden Lieferprobleme -zuletzt in den Jahren 09-11 mit angekündigten Wartezeiten von über einem Jahr für bestimmte Bauteile- eindrücklich bewiesen haben. Es ist ja auch logisch, für den Fertiger spielt nur der reine Verdienst pro Auftrag eine Rolle. Markenstrategische Überlegungen usw. die auch das vorhalten von Kapazitäten für alte Prozesse beinhalten um Kunden nicht zu verprellen interessieren den nicht die Bohne. Vor allem nicht in Zeiten wo die Auftragsbücher voll sind und er sich die Kunden aussuchen kann. Wenn da durch den abbau auch der letzten Möglichkeit für ältere Prozesse zugunsten von neuen Anlagen mehr Geld verdient werden kann wird er das tun. Und wenn dann der Kunde das nächste mal Bestellt wird der Auftrag einfach abgelehnt weil er es nicht mehr kann. Ausgelastet ist er sowieso. Und in den Zeiten wo die Auftragsbücher wie in den letzten JAhren aus allen Nähten platzen führt selbst bei nicht veralteten Prozessen dann eine kleine Fehlplanung dann zu massivsten Verzögerungen. Es sind dann einfach derart lange Wartezeiten bei den Fertigern vorhanden das die Firmen gar keine Möglichkeit haben kurzzeitig zu reagieren. Wird dann der Bedarf einfach unterschätzt wird oder gar wie um 2010 rum in befürchtung eines Umsatzeinbruches gar positionierte Aufträge gecancelt werden muss man sich nach feststellung des Irrtums wieder GAAAANZ WEIT hinten in der Schlange anstellen. Und die Kunden welche nicht zu den absoluten Großabnehmern gehören bekommen dann Schlagartig Lieferzeiten von 60 Wochen gemeldet... Zwar sind damal dann viele Bausteine doch schneller wieder lieferbar gewesen als die ersten Verfügbarkeitsangaben befürchten liessen. Aber es waren trotzdem teilweise viele Monate und vermutlich auch nur deshalb weil viele (wie in meinem Bereich) dann nach dem die Meldung kam das die wieder verfügbar sind zum großen Erstaunen von Atmel dann einfach abgewunken haben weil mittlerweile ein Design Out zugunsten von Microchip, NXP oder ST (als Beispiele) erfolgt ist- der Bedarf sich also massiv verringert hat... (Wobei ST in Sachen Lieferzeiten durchaus auch schon mal den einen oder anderen Bock geschossen hat, aber kein Vergleich zu Atmel...) Daher ist z.B. für mich Atmel wann immer ich die Wahl habe mittlerweile ganz weit hinten auf der Liste. Egal was es konkret für ein Baustein ist. (Ausgenommen davon sind nur Bauteine für die es eine 100% kompatible SecondSource gibt, im µC Bereich also keine!) Speziell zu den XMEGA kommt dann noch dazu das die zwar für einige sehr spezielle Anwendungen wirklich ECHTE VORTEILE bringen, für die allermeisten Anwendungen aber andere Produkte -sowohl aus dem eigenen HAus als auch von anderen HErstellern- mindestens genauso gut, wenn nicht sogar besser geeignet sind. Damit ist für viele der Anreiz einen neuen Typ in den Bestand aufzunehmen eher gering. Allerdings: Es gibt ganz offensichtlich einen Interessentenkreis der das anders sieht und immerhin groß genug ist das Atmel immer noch Energie in die Weiterentwicklung der XMEGA steckt. Auch wenn die meiste Energie derzeit zweifellos in die ARM Produkte investiert wird. Letzten Endes muss man also in Kenntniss der jeweiligen Anwendung entscheiden was nun das Beste ist. Hat man sonst nur AVR im Einsatz und kann mit diesen eine neue Anforderung nicht erfüllen - wohl aber mit den XMEGA- dann kann der XMEGA sicher die Ideale wahl sein. Hat man aber bereits diverse ARM (incl. Atmel) oder "breitere" PICs im Einsatz und ist mit den Tools sowie den Beschaffungsgegebenheiten gut vertraut, dann wird oft dort eine "elegantere" Alternative zu finden sind. Gruß Carsten
Detlev T. schrieb: > Was wäre da noch kompatibel, wenn man die Wortbreite ändert? Wenn man (der Hersteller!) es will: Die IDE, die Programmiertools, der "userseitige Teil" (Befehlssatz, Syntax) des Compilers, zumindest in C die Registerbezeichnungen. Somit kann man eine volle "Aufwärtskompatiblität" udes älteren Codes und sehr weitgehende Abwärtskompatiblität auf Quellcodebasis bewerkstelligen. Selbst in ASM könnte man eine solche Kompatiblität zumindest in einer Richtung in großen Teilen hinbekommen, auch wenn es da ohne jegliche Bearbeitung des Codes wohl nicht mehr gehen wird. > Microchip macht das ja so. Da gibt es verschiedene Wortbreiten und wenn > man von einer Familie zur anderen wechselt, muss man sich total > umstellen, braucht häufig neue Compiler etc. Beim AVR hat man vom > kleinsten Tiny bis zum größten XMEGA (fast) den gleichen Befehlssatz, > vom Hardwaremultiplier einmal abgesehen. Daher kann man auch immer > dieselbe, vertraute Toolchain verwenden. Schreibt da jemand vom Hörensagen oder ist das bewusste Wahrnehmungsverzerrung? JA - Microchip hat verschiedene Familien mit jeweils verschiedenen Wortbreiten im Programm. Und zu den unterschiedlichen Familien gehören auch teilweise verschiedene Compiler. (IDE & Programmer/Debugger sind aber für die nicht absolut veralteten Serien immer Identisch) Aber der Vergleich mit "kleinsten Tiny bis zum größten XMEGA" gegenüber den "vielen Wortbreiten" trifft hier trotzdem so absolut nicht zu. Ganz deutlich wird es wenn man sich die Hochsprachenseite ansieht: Dort gibt es pro Registerbreite (8, 16 & 32Bit) immer nur jeweils EINEN Compiler. (IDE & Programmieradapter sind ja immer gleich) Wenn der Anwender also auf der 8Bit Schiene unterwegs ist (und nur diese entspricht ja den AVR) macht es für ihn also überhaupt keinen Unterschied ob er nun einen kleinen 10F200 im SOT23 Gehäuse oder einen PIC18F97J94 im 100 Pin TQFP mit USB, LCD Treiber incl. Charge Pump, Touch Sensor uvm. beschreibt. So lange der µC die Benötigten Ressourcen hat verhält er sich für den Anwender gleich. Und auf die Ressourcen muss man ja auch bei den AVR achten... Nur im Gegensatz zu den AVR hat man hier ERGÄNZEND noch die Möglichkeit mit geringen änderungen im Code nur durch auswahl eines anderen µC in der IDE unter verwendung derselben sonstigen Tools seinen Code auch noch auf 16 oder 32 Bittern zum laufen zu bringen. Das führt dann zu solchen Dingen das es überhaupt kein Problem ist ein Projekt nach einer ersten Abschätzung mit einem großen 16Bitter wie dem PIC24FJ256GB zu beginnen. Dann aber, weil die Bestellung für fünf Tage in den Rückstand geht und keine 24fj256 mehr im eigenen Bestand sind, statt des 24ers einen PIC32MX795 (selbes PinOut) auf das Entwicklungsboard zu packen um damit die Programmentwicklung zu starten. Einfal weil es dann nach Ankunft der 24er innerhalb von weniger als 30 Minuten gelingt den ganze mit dem Pic32 entwickelten Code auf den nun statt des PIC32 aufgelöteten PIC24 zum laufen zu bringen um damit dann die Entwicklung abzuschließen. Und als ich danach dann festgestellt habe das wir dank Änderungen der Anforderungen wesentlich weniger Speicher usw. brauchen und somit den PIC24FJ32GB als kleinsten PIC mit USB Host Funktionalität einsetzen können war das auch überhaupt kein Thema weil auf dem dann bereits 5Minuten später die Firmware ebenfalls lief. Und dies ist wie gesagt ein Wechsel zwischen völlig verschiedenen Familien, bei ATMEL also so als wenn man zwischen AVR und ARM hin und herspringen will. Wobei Atmel allerdings auch begonnen hat es etwas zu vereinfachen in dem Atmel Studio sowie einige Programmiertools sowohl AVR wie auch deren ARM unterstützen. > Ich persönlich sehe das als Vorteil. Auch das da in den vielen Jahren > nichts geändert wurde. Andere sehen das anders, sonst gäbe es die PICs > ja sicher nicht mehr. Wie gesagt, der Vorteil ist keiner weil du Äpfel mit Birnen vergleichst. Innerhalb einer Produktlinie kann es zwar bei den Binärfiles erhebliche Unterschiede geben, aber schon bei den ASM Quellcodes ist zumindest bei den Grundbefehlen die Kompatibilität sehr groß (Die großen Bausteine können halt mehr als die kleinen, aber das ist bei Atmel ja auch nicht anders) Und selbst die geringen noch vorhandenen Unterschiede bei ASM sind nur dem Umstand geschuldet das die PIC halt ein viel breiteres Spektrum an Peripherie abdecken. Wenn man die Auswahl auf ein ähnlich eingeschränktes Funktionsspektrum wie bei den AVR verfügbar eingrenzen würde könnte sich eine Auswahl von Typen jeder Baugrösse heraussuchen die selbst auf ASM ebene genau denselben Kompatibilitätsgrad haben wie die AVR untereinander. Es ist halt etwas anderes eine Kompatibilität von 376 verschiedenen Grundtypen mit der von 171 verschiedener Grundtypen zu vergleichen! (171 == 218 8Bit AVR abzüglich der Dupletten wegen Automotive oder besonderem Temperaturbereich die bei Microchip ja anders als bei Atmel nicht als eigenständige Typen sondern als Variante des Grundtypes laufen) Wobei man selbst da nch für den Anwender praktisch Identische µC mehrfach zählt, das gibt es bei Microchip aber dann auch. Ab C merkt der Anwender auf der 8Bit Schiene ausser den durch die verschiedenen Ressourcen gegebenen Einschränkungen dann keine Unterschiede mehr. Und die (geringen) Unterschiede zu den 16 & 32 Bit zählen ja gar nicht weil du dann ja auch die AVRmit den ARM vergleichen müsstest wo die Unterschiede für den Anwender Stärker sind. Gruß Carsten
Also ich seh in den Angeboten der großen Bastlerlieferanten Reichelt & Co. 8-Bit AVR und PIC immer noch weit, weit vorne. Das hat gewisse Gründe die hier oft genug in aller Ausführlichkeit schon zur Debatte standen. Also von den Schwarzmalern bloß nicht ins Bockshorn jagen lassen ;-)
Moby schrieb: > Angeboten der großen Bastlerlieferanten Reichelt & > Co. 8-Bit AVR und PIC immer noch weit, weit vorne Genau es ist heute Bastelware. Das kann man auch gut hier im Forum nachlesen: Beitrag "neuer ATMega168P lässt sich nicht Programmieren"
MCUA schrieb: >>Xmega sind wirklich gut von der Peripherie... > Ja? > "The SPI module is unbuffered in the transmit direction.." Und wo genau ist dein Problem damit? Als Master spielt das sowieso niemals eine Rolle und als Slave eigentlich auch nicht, jedenfalls nicht mehr beim Xmega. Beim klassischen AVR-Mega hingegen ist das wirklich eine äußerst lästige Einschränkung bezüglich der Leistungsfähigkeit der SPI-Schnittstelle. Vielleicht hast du nur die neuen Features der Xmega nicht verstanden oder bist unfähig, sie sinnvoll zu nutzen? Nein, sie stecken nicht im SPI-Modul...
Hustler schrieb: > Genau es ist heute Bastelware. Das kann man auch gut hier im Forum > nachlesen: > Beitrag "neuer ATMega168P lässt sich nicht Programmieren" Nö. Kann man nicht. Da kann man nachlesen was rauskommt wenn halbgares Material zur Programmierung verwendet wird. c-hater schrieb: > Vielleicht hast du nur die neuen Features der Xmega nicht verstanden > oder bist unfähig, sie sinnvoll zu nutzen? Wenn man diese verdammte "Fehlerquelle" nur ausschließen könnte...
c-hater schrieb: > MCUA schrieb: > >>>Xmega sind wirklich gut von der Peripherie... >> Ja? >> "The SPI module is unbuffered in the transmit direction.." > > Und wo genau ist dein Problem damit? Als Master spielt das sowieso > niemals eine Rolle und als Slave eigentlich auch nicht, jedenfalls nicht > mehr beim Xmega. Beim klassischen AVR-Mega hingegen ist das wirklich > eine äußerst lästige Einschränkung bezüglich der Leistungsfähigkeit der > SPI-Schnittstelle. > > Vielleicht hast du nur die neuen Features der Xmega nicht verstanden > oder bist unfähig, sie sinnvoll zu nutzen? > > Nein, sie stecken nicht im SPI-Modul... TJo, richtig. Mit dem Event System und DMA lässt sich das empfangene Byte direkt in den SRAM kopieren oder beim fertig gesendeten Byte direkt das nächste aus dem SRAM holen. Dagegen sieht ne Hardware FIFO alt aus.
Martin Wende schrieb: > Mit dem Event System und DMA lässt sich das empfangene Byte direkt in > den SRAM kopieren Das mag ja beim Mega neu sein, andere kennen vergleichbare Techniken schon seit Jahr(zehnt)en.
alter Hut schrieb: > Martin Wende schrieb: >> Mit dem Event System und DMA lässt sich das empfangene Byte direkt in >> den SRAM kopieren > > Das mag ja beim Mega neu sein, andere kennen vergleichbare Techniken > schon seit Jahr(zehnt)en. Uuuuuuund am Thema vorbei! Darum gings grade garnicht, sondern inwiefern denn eine hardware FIFO am SPI nun eien Makel darstellt oder nicht.
Martin Wende schrieb: > Uuuuuuund am Thema vorbei! wirklich? Das Thema heißt "was spricht eigentlich gegen die xmega?". Da passt das schon.
und es geh weiter...gerade entdeckt: neue Xmega nun auch in 105°C z.b. im atxmega128A1U entdeckt
> Vielleicht hast du nur die neuen Features der Xmega nicht verstanden > oder bist unfähig, sie sinnvoll zu nutzen? Ja? Keine Ahnung aber rumlabern! Vielleicht hast du ja auch noch nie kapiert, das solche Schnittstellen, um flüssig funkt. zu können, prinz. immer auch noch einen Buffer brauchen! Völlig wurscht ob DMA vorhanden oder nicht. Kannste guggen bei richtigen uCs (nicht bei AVR-Spielzeug). Alle anderen (mit DMA) haben das auch. warum wohl? Und selbst wenn DMA schon vorhanden, kann ggfs noch FIFO sinnvoll sein. (den so schnell wie's damit geht/ginge, wirds mit DMA nicht möglich sein).
>Als Master spielt das sowieso niemals eine Rolle ..
Schwachsinn
Was für den XMega spricht. Multi-Slave bei I2C/TWI leicht zu programmieren, weil dafür Register vorhanden sind. Softwarekonfiguration des Takts, Runtime-Kalibrieration des Systemtakts (DFLL). Gibt ja auch Anwendungen wo der Takt und die Zeit in etwa Stimmen sollte auch ohne große exteren Beschaltung. Die Register endlich einmal aufgeräumt und durchgängig konsistent benannt. Ansonsten soll jeder damit glücklich werden was ihm gefällt. Kurt
KKM57P .. schrieb: > Softwarekonfiguration > des Takts, Runtime-Kalibrieration des Systemtakts (DFLL). Gibt ja auch > Anwendungen wo der Takt und die Zeit in etwa Stimmen sollte auch ohne > große exteren Beschaltung. Am Takt muß man i.d.R. nix rumspielen, das Ding läuft auch ohne Quarz bei intern 2 oder 32 Mhz hinreichend stabil (zumindest kann man da für Uart-Anwendungen sprechen). Interessant bei den neueren U-Typen: Viel Spielraum für Übertaktung, locker bis hin zum Doppelten der Spezifikation... Also das Ding hat genug Power und Peripherie, um den vielen AVR Anwendungen noch für viele Jahre ein bequemes, einfach händelbares Zuhause zu bieten.
Moby schrieb: > das Ding läuft auch ohne Quarz > bei intern 2 oder 32 Mhz hinreichend stabil (zumindest kann man da für > Uart-Anwendungen sprechen) Genau, und das völlig unbahängig von der Temperatur!? Natürlich funktioniert das nicht! Unser Mobby Oberbastler hat nicht die höchsten Ansprüche. ;-)
Aufsicht schrieb: > Moby schrieb: > das Ding läuft auch ohne Quarz > bei intern 2 oder 32 Mhz hinreichend stabil (zumindest kann man da für > Uart-Anwendungen sprechen) > > Genau, und das völlig unbahängig von der Temperatur!? > Natürlich funktioniert das nicht! Nee, unbahängig nicht, aber es langt trotzdem locker ;-)
Es macht für mich schon einen gewaltigen Unterschied ob ich +-1% oder schlechter liege beim Takt oder 0,02% mit DFLL erreiche. Dann spiel ich auch nicht rum sondern nutze dafür vorgesehene Bordmittel sprich DFLL.;)
1 | DFLLRC32M.CTRL = DFLL_ENABLE_bm ; |
2 | DFLLRC2M.CTRL = DFLL_ENABLE_bm ; |
musst schon entschuldigen moby, die "aufsicht" weiss die begriffe hinreichend und runtime-calibration nicht richtig zu deuten :)
Püh, langer Thread. Hat aber dazu geführt, dass ich mein Arsenal an ATtiny13/85, ATmega32, ATmega328, ATXmega128a3u, STM8S003, STM8S103, STM32F05x, STM32F103, STM32F4xx, MSP430xxxx, noch um zehn TSSOP20-STM32F030F4P6 und 20 Adapterplatinchen TSSOP->DIP ergänze (rund 10 Euro inklusive Versand insgesamt für alle Teile). So ein "kleiner" Cortex-M0 klingt sehr verlockend und dürfte den Xmega auch einstecken - 48MHz vs 32 MHz, und dann auch noch 32 Bit. 16 KByte Flash und 4 KByte RAM sind Und wenn ich damit nur 'nen Furzsensor auslese. Und was heißt das im Endeffekt auf die Eingangsfragestellung? Ist doch toll, etwas Neues zu lernen. Hält den Geist frisch und setzt neue Kapazitäten frei. Wobei ich den Xmega immer noch nicht ans Laufen gebracht habe; der avrdude-Bug mit LUFA-Programmern ist ein voller Showstopper.
Ah OK, ein Bug, der etwas Nachdenken erfordert ...
Habe schon darüber nachgedacht, auf meinem MBA (chronischer Platzmangel mit 128GB SSD) ein avrdude selber abzupatchen (wie dort verlinkt - ist zwar kaputt, aber liefe für mich wohl) und zu compilieren. Damit würde ich mir aber die schöne Ordnung zerstören, die ich durch die vorgefertigt genutzten Pakete habe ( http://www.obdev.at/products/crosspack/download-de.html ). Es ist da tatsächlich auch Faulheit im Spiel. Falls du das meinst. Eine neuere LUFA-Firmware habe ich nicht, und auch ein neues CrossPack ist nach Bug-Eröffnung nicht erschienen.
:
Bearbeitet durch User
Dirk K. schrieb: > Falls du das meinst. Nein, ich meinte, dass ich dort mal etwas länger über einen korrekten Fix nachdenken muss. Die Zuordnung der Endpoints war da initial ein wenig ad-hoc, und orientierte sich an dem, was die Atmel-eigenen Tools so brauchen.
Ich - persönlich - finde nichts dagegen ... Genauso wenig wie gegen STM32 oder PICxx oder ... Aktuell portiere ich eine Anwendung von MEGA auf XMEGA - und vieles ist bekannt aber auch ganz neu. Es ist schade, dass es nur so (relativ) wenig Unterstützung gibt aber das ist mir egal. Ich möchte gerne DMA einsetzen und das kann ich mit der MEGA-Reihe nicht. Es ist vieles viel "einleuchtender" und manches "gewöhnungsbedürftig" aber ich bin sehr zufrieden. Ich betrachte das Ganze aber auch nicht aus professioneller Sicht sondern rein Privat. Es ist mir egal, ob der Chip 2 Euro mehr kostet wie ein anderer Chip - da ich keine Serien- oder Massenproduktion anstrebe sondern rein aus Spass und Hobbymässig agiere. Ich möchte viele ausprobieren und der ATXMEGA ist nur ein Schritt in eine Richtung - welche auch immer es sein wird. Aktuell scheue ich die STM32-Fraktion noch etwas - das kann sich aber schnell ändern. Keine Ahnung, wo ich im nächsten Jahr sein werde. Kurz: NICHTS - schaun mer mal ... :-)
Dieter Frohnapfel schrieb: > Keine > Ahnung, wo ich im nächsten Jahr sein werde. Am besten immer dort wo die gestellte Aufgabe einfachstmöglich gelöst wird. Ganz jenseits von Zeit und Raum ;-)
:-P :-P :-P :-P :-P schrieb: > Ganz genau, inder Welt der 32Bit. ;-) Dafür gibt es sicher Beispiele. Wenn auch nicht allzu viele :-)
Schnauze voll schrieb: > Was spricht gegen den xmega? > > Das Mobby ihn benutzt. :-P Kriterium ist die Art der Anwendung. Kein Mobby oder sonstwas... Ich meine, wenn mans professionell angeht! :-P :-P :-P :-P :-P schrieb: > Ganz genau, inder Welt der 32Bit. ;-) Ich steig erst bei dreistelligen Bitzahlen wieder um- alles andere sind ja doch nur Zwischenlösungen ;-)
Beitrag #5388274 wurde von einem Moderator gelöscht.
Beitrag #5389357 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten