Also ich fang mal an: Erster Wunsch ist ein Schattenregistersatz für schnellstmöglichen Kontextwechsel.
eigentlich müßig, aber.. bessere Hardware-Debugmöglichkeit: - Hardware sollte im Debugmodus weiter laufen - Data-Breakpoints! - Trace!! PWMs sollten im (Debug-)Break weiterlaufen oder wenigstens einen festen Wert annehmen
na dann verwendet eben Cortex Mx oder Rx , und schon habt ihr alles was ihr euch wünscht. Ok, es steht kein AVR drauf, aber das ist dann nu wirklich kein Verlust.
Als ASM Programmierer bin ich immer noch glücklich mit AVRs arbeiten zu können! Die Komplexität von Cortex und Konsorten steht doch gerade für viele kleinere Projekte in keinem Verhältnis zum praktischen Nutzen und erschwert zunehmend die Programmierung. Das gilt ebenso schon für den Xmega. Beim Nachfolger sollte wieder der Trend Richtung Vereinfachung gehen aber ich fürchte, bei Atmel arbeitet kein Steve Jobs :) Die tonangebenden Ingenieure sollten es mit ihrem Faible für maximale Flexibilität (=Komplexität) nicht übertreiben. Viel sinnvoller als beispielsweise die erweiterten Konfigurationsmöglichkeiten der USART Schnittstelle im Xmega wär erstmal mehr SRAM gewesen.
...etwas Geduld noch , Kinder ; bald ist wieder Weihnachten !
Moby schrieb: > können! Die Komplexität von Cortex und Konsorten steht doch gerade für > viele kleinere Projekte in keinem Verhältnis zum praktischen Nutzen und > erschwert zunehmend die Programmierung. Das gilt ebenso schon für den > Xmega. Beim Nachfolger sollte wieder der Trend Richtung Vereinfachung > gehen aber ich fürchte, bei Atmel arbeitet kein Steve Jobs :) Die Kein Thema. Steig um auf Processing und den Arduino Due. Apropos, wann kommt der denn endlich? Immerhin sind ja wohl schon ein Dreivierteljahr nach der großen Ankündigung (und seitdem absolute Funkstille) erste Boards zu Betatestern gelangt.
Moby schrieb: > Beim Nachfolger sollte wieder der Trend Richtung Vereinfachung > gehen aber ich fürchte, bei Atmel arbeitet kein Steve Jobs :) Die > tonangebenden Ingenieure sollten es mit ihrem Faible für maximale > Flexibilität (=Komplexität) nicht übertreiben. Das meinst du doch nicht ernst oder? Was genau ist an dem Ding Komplex?!? Das ist ein stink einfacher XMEAG. Nix Großes - jeder Zehnklässler sollte sowas bei durchschnittlichem IQ gut bis sehr gut programmieren können. Vorrausgesetzt er hat sich ein bisschen damit beschäftigt. Von Komplexität kann man hier nun wahrlich nicht sprechen. Wem mit einem XMEGA überfordert ist, der sollte vielleicht tatsächlich auf Arduino oder sonstige Abkömmlinge umsatteln. Der XMEGA stellt halt fast eine Grenze da die der gewöhnliche Hobbybastler selten überschreitet. Moby schrieb: > Viel sinnvoller als > beispielsweise die erweiterten Konfigurationsmöglichkeiten der USART > Schnittstelle im Xmega wär erstmal mehr SRAM gewesen. Wenn man das so sieht sollte man sich eher fragen, ob der XMEAG nicht ein Stufe zu groß bzw. ungeeignet ist für das anstehende Projekt.
Ich glaub ja hier schnappt einer gerade ein wenig über... Wer so abgehoben daherschwafelt macht vermutlich die meisten Fehler :)
Moby schrieb: > Ich glaub ja hier schnappt einer gerade ein wenig über... Wer so > abgehoben daherschwafelt macht vermutlich die meisten Fehler :) Ich schnappe nicht über ich betone nur, dass wenn jemand eine derartige Kommentare wie bzgl. der erweiterten UART Konfigurationsmöglichkeiten abgibt einfach nicht auf einem Level unterwegs ist das ihn für das Level eines XMEGAs qualifiziert. Ich kann verstehen, dass für die meisten Hobbyuser UART einfach eine Schnittstelle ist, manche kennen noch den Unterschied zwischen synchron und asynchron aber das wars dann auch schon. Ohne zu googeln weiß hier doch nur jeder Zehnte was es mit UART im Detail auf sich hat. Das ist auch nicht schlimm, aber dann sollte ich mich mit solchen Kommentaren zurückhalten. Das ist wie wenn im einen Autoforum jemand schreibt: "Warum eigentlich Turbolader, der Motor saugt die Luft doch sowieso an, muss man sie doch nicht extra noch reindrücken, ist doch alles Geldmacherei und bringt eh nix!". In einem solchen Fall erlaube ich mir durchaus eine "Nicht-Säusel-Ton" anzuschlagen. Dafür bitte ich um Verständnis!
Meine Wunschliste: - DIP40 Gehäuse, jajaja, ich löte noch auf Lochraster (bin bald OPA, in etwa 20 Jahren:-) - Mehr RAM - USB Host Modus - USB Client (wie nennt man das richtig?) - Ethernet MAC/PHY intern - I/O Pins per Software auf 2V, 3.3V, 5V einstellbar (bei 5V SPannungsversorgung) - Integrierte Steckbuchsen direkt im Chip für Programmer und Quartz (das wäre doch mal mega praktisch) - Integrierte super low current hardwired Status LED, an der man ablesen kann, ob Stromversorgung und Taktquelle arbeiten und ob der Chip in einem Standby Modus ist.
also ich weiss nicht, wofür man den Xmega ernsthaft einsetzen soll, wenn man nicht muss %) Erfahrung mit 8bit AVRs zählt net wirklich, da bei den XMEGAS vieles anders ist. Leitungsmässig sind sie nicht spitze, ich brauche ein neues Programmiergerät, und Einfachheit ist auch kein Argument mehr, und der Preis auch nicht(für Hobbyanwendungen sowieso nicht) also da kann man wirklich direkt zu einem Cortex greifen... DIP Gehäuse wirds bei solchen uCs wohl nicht mehr geben, aber mit den Adaptern ist das ja nun auch kein Problem. Und ich bin sicherlich kein Lötheld, aber mit Litze, Löthonig und bischen Fummeln bekommt man auch so einen uC problemlos auf die Platine gebruzelt
Ich finde eh, das solche Diskussionen am wahren Kern vorbeigehen: AVR8 ist tot. Das Preis-/Leistungsverhältnis ist miserabel und er ist umständlich zu programmieren. Ein kleiner ARM ist viel leichter zu programmieren, gerade in Assembler. Der Komfort, den man durch 32-Bit-Register, 32-Bit-Multiplikation und ggf. auch Division (bei größeren Cortexen, glaub ab M4, oder?) hat, ist enorm. ARM-Assembler ist zudem unheimlich sexy dank hoher Orthogonalität. Nix von diesem AVR-gewurschtel wo jeder Befehl was andres kann, nicht immer alle Register zulässig sind oder unterschiedliche Konstanten möglich sind. Bei ARM sind die Möglichkeiten der Parameter fast immer gleich (welche Register sind zugänglich, welche Immediate-Werte gibt es, der Barrel-Shifter)* ARM-Assembler macht Spaß! Man muss halt einmal umlernen, dafür lernt man dann gleich die Architektur, die im Embedded-Bereich immer mehr zum Standard wird. Deswegen gibt es für ARM nicht nur Assembler und C, auch etliche andere Programmiersprachen bieten ARM-Codeerzeugung. Das wird man nie wieder umlernen müssen, wage ich jetzt mal zu behaupten. Billiger ist es allemal, und es gibt bald auch welche im DIP-Gehäuse (LPC1114 im DIP-28). Dazu gibt es spottbilige Devel-Boards, 20-30 Euro, kauf dafür mal ein AVR-Devkit... manchmal auch als Modul mit DIP-Pins, so dass auch die größeren ARMs wiederum Breadboard-tauglich werden. Alternativ kann man, gerade wenn man PIC-Fan ist, zum PIC32 mit MIPS-Core greifen, das ist auch eine etablierte Standardarchitektur, die tausend mal besser durchdacht ist als AVR8 (oder PIC12-24). Die meisten Argumente oben kann man genau so auf die PIC32 ummünzen. Reichelt hat sein Angebot grad fett ausgebaut, ab DIP28 für 5,50€. Wirklich, an all die AVR- und PIC-Fans: Wer nicht im Sub-Euro-Bereich agiert, kriegt auch als Hobbyist ab ca. 2 Euro (LPC1111 bei Darisus) ziemlich leistungsfähige ARM-µCs die grundsätzlich so funktionieren wie AVRs, aber mehr Speicher, mehr MHz, mehr Peripherie und bessere Assembler-Sprache haben. Vergleicht mal mit dem AVR, was kriegt man da schon für 2 Euro. Nur AtTiny/PIC12/PIC16 decken ein Feld ab, das ARM wohl so bald nicht erobern wird. Bei denen ist aber dieser Thread "Wunschliste" sinnlos, denn da gehts um weniger, nicht mehr. Die ARMs haben üblicherweise auch den Vorteil, dass der Upgrade-Pfad einfach ist. Die Minimalversion ist fertig gebaut und getestet, aber auf einmal will man Ethernet? SD-Karten? LCD? SRAM? SDRAM? Bei den meisten Herstellern gibt es größere Varianten, die Register- und (mehr oder weniger) Pinkompatibel sind. Das reicht bei bestimmten µCs dann bis hin zur Möglichkeit, die mit Linux zu betreiben (LPC1788 z.B., sowas geht natürlich nur mit unangenehmen Pinzahlen -- TQFP-208). Und trotzdem kann man zuerst ganz klein mit einem DIP-Teil aufm Breadboard anfangen. Je mehr man lernt, desto größer kann man werden und muss nichts umlernen. Auch der Umstieg auf andere Hersteller ist leicht. Ich entwickle z.Zt. ein Board mit LPC17xx, das bis vor kurzem auf STM32 gemünzt war. Der Wechsel war trivial, und auch softwareseitig gibt es schon fertige Bibliotheken, die herstellerübergreifende Treiberroutinen enthalten. Wirklich, statt Wunschzettel zu schreiben, bestell dir ein STM32Discovery oder LPCXpresso (die sind neben einem Prozessorboard gleichzeitig auch eigenständige Programmer/JTAG-Debugger). Wenn du ganz besonders schmerzfrei einsteigen willst und lieber was mit fertigen Programmbeispielen und einfacher Entwicklungsumgebung willst, dann hol dir den mbed. Oder geh was andres shoppen (z.B. bei watterott.com), da gibts etliche günstige Boards die echt sexy sind. Und dann spiel mal mit ARM. Du wirst es nicht bereuen. * Fußnote: Ich kenne Thumb-2 Assembler noch nicht. Kann sein dass das bei den Cortex-M-Prozessoren nicht mehr ganz so universell ist.
Wann wird denn nun das Microcontroller.Net Icon endlich auf "ARM"
umgestellt?
Das olle "AVR" in dem IC ist doch schon langsam abgenutzt.
>Aber der Strom ^^
- Ist bei gleicher Taktfrequenz sicher niedriger. Meiner wird mit 168MHz
nicht mal warm
- Außerdem kann jede Peripherieeinheit getrennt mit Takt versorgt
werden, was auch den Stromverbrauch optimiert.
Der Cortex-M3 kann 2.17 CoreMark/MHz - 1.25 DMIPS/MHz (http://www.arm.com/products/processors/cortex-m/cortex-m3.php) Der Xmega 1.46 DMIPS/MHz Der Cortex-M4 macht Multiplikationen von 2 Float-Zahlen in 5 Takte, der XMega macht das sicher nicht in 5 Takten. Google doch Deine Antworten selbst...
Und die Multiplikation von Float-Zahlen ist jetzt wie genau respräsentativ?
Je nach dem was man entwickelt. Jedenfalls kann man, wenn man ein Projekt mit vielen Float Zahlen hat, einfach vom M3 auf einen Cortex-M4 wechseln ohne gleich alles über den Haufen werden zu müssen.
Ich hab mal fix Datenblätter angeguckt: AtTiny13 vs. LPC11U24 AtTiny13 weil er von AVR als picoPower beworben wird, LPC11U24 weil es der ist, der in der Low-Power-Variante vom mbed eingesetzt wird. Beide im Active Mode. Beide werden als besonders Stromsparend beworbend. Beide liegen bei 1-2mA bei 3.3V Vdd. Beide um 10 MHz (LPC 12, AtTiny 9.6). Gönnt man sich 8mA, so kann der LPC schon 48MHz und USB. Mach das mal mit dem AtTiny.
Sam P. schrieb: > Beide im Active Mode. Und im Sleep? Aber bitte mit data retention, ansonsten vergleichst du Äpfel mit Birnen.
Current schrieb: > Ich weiß nicht ob der Arm bei 16 MHz genau so effizient ist wie ein AVR, > sag du es mir ? Ja, das sag ich dir: Überall dort, wo man bei AVR einen ganzen Sack Befehle braucht, tut's beim ARM bzw. Cortex ein einziger Befehl. Auf der diesjährigen Embedded hat man es ja schon sehen können, wie die diversen Cortexe in der Szene aufgeräumt haben - zu Recht. Mit den Cortexen gibt's endlich uC in der dickeren Lestungsklasse, wo alles zusammenkommt: leistungsfähig, sparsam, gut unterstützt und kostengünstig. Wozu da einem AVR nachtrauern? Kurzum, AVR ist mittlerweile Nostalgie. etwa genau so wie das Basteln mit nem Z80, 8080, 8051 und so. Ich will das nicht schlecht reden, irgendwas mit 'Vintage'-Teilen anzustellen, kann ja auch ganz nett sein. Aber man sollte sich darüber im Klaren sein, daß man nostalgiebastelt. W.S.
W.S. schrieb: > Überall dort, wo man bei AVR einen ganzen Sack > Befehle braucht, tut's beim ARM bzw. Cortex ein einziger Befehl. Genau. Zum Beispiel zum Toggeln eines IO-Pins. >:-) Mach's mal halblang. Der ARM hat seine guten Seiten, daran zweifelt niemand. Aber die eierlegende Wollmilchsau muss trotzdem noch erfunden werden. Ich weiß, Cortex-M0+ gibt's mittlerweile, aber da ist das mit dem "ein einziger Befehl" auch schon wieder was anderes, und mit Leckströmen sieht es bei diesen Strukturgrößen in weiten Bereichen eben auch noch nicht so rosig aus. Nicht jeder will den ganzen Tag lang numbercrunching veranstalten mit seinen Controllern.
Beim LPC gibt's Power-Down für ca. 1 µA, Deep Power Down für ca. 0.2µA. Ersterer kann neben Watchdog und GPIO auch per USB-Aktivität aufgeweckt werden und hat Data Retention, letzterer kann 18 Bytes an Daten erhalten, sontige Register und SRAM gehen verloren. Beim Tiny ist der Power-Down-Mode bei 0.2µA mit Data Retention (64 byte SRAM plus Register).
Jörg Wunsch schrieb: > und mit Leckströmen sieht es bei diesen Strukturgrößen > in weiten Bereichen eben auch noch nicht so rosig aus. Siehe meine Datenblatt-Zahlen. So ein Cortex-M0 spielt in der selben Liga wie ein Low-Power-AtTiny, hat aber das wievielfache an RAM/Flash/MHz/Peripherie? Strukturgröße my ass, die Ergebnisse stimmen. Das eigentliche Argument für die kleinen AVRs ist der Preis, denn der Cortex kommt halt in Hobbyisten-Stückzahlen nicht unter 2 Euro, da sind PIC12/16 und AtTiny besser und kleiner. Wer also eine externe Reset-Steuerung für sein Board braucht, pflanzt sich einen 6-Pin-PIC12 o.ä. drauf. Wer aber zum Basteln einen bequemen "general purpose" µC sucht, sollte dem AVR nicht nachtrauern und ARM Willkommen heißen.
Noch ein Vorteil für die ARM Prozessoren: Mit ein und der selben Entwicklungsumgebung/Hardware-Anschaffung kann man Cortex-M0, M3, M4, ARM7, 9, 11 proggen von ST, NXP, TI, Analog, Atmel, und wie die vielen anderen Hersteller sonst noch heißen. (Ja, Atmel hat auch Prozessoren mit ARM Kern im Programm, nicht nur die AVR/XMegas.)
Sam P. schrieb: > Beim LPC gibt's Power-Down für ca. 1 µA Das geht schon, die meisten M3s sind aber deutlich drüber. > Deep Power Down für ca. 0.2µA. Das ist aber eher Augenauswischerei. Was willst du mit dem Schlafen- legen ohne RAM-Erhalt?
Jörg Wunsch schrieb: > Sam P. schrieb: >> Beim LPC gibt's Power-Down für ca. 1 µA > > Das geht schon, die meisten M3s sind aber deutlich drüber. Klar, der genannte LPC ist ein M0. Die M3 sind eher High-Performance-Typen, die sind nicht gegen die AtTinys aufgestellt. Ein Vergleich XMega vs. LPC17xx mach ich jetzt aber nicht auch noch, das kann jeder der lesen kann selber tun. >> Deep Power Down für ca. 0.2µA. > > Das ist aber eher Augenauswischerei. Was willst du mit dem Schlafen- > legen ohne RAM-Erhalt? Najaaa... es ist nicht hundertprozentig das gleiche, aber unter der Annahme, dass die erhaltenswerten Nutzdaten, die man nicht im EEPROM unterbringen will, nur 18 Byte sind, ist das annähernd gleichwertig. Der Tiny erhält ja auch nur 64 Byte, mehr SRAM hat er nicht. Die Portkonfiguration fällt beim LPC halt an, das ist etwas Aufwand, aber der etwas höhere Takt gleicht das aus - wir reden ja von <100 Assemblerbefehlen. Was man auch nicht vergessen darf, ist, dass man den Strom bei vielen ARMs auch komplett wegnehmen kann. Die haben dann einen Pin für ne CR2032, die dann etliche Jahre hält, und damit ne RTC betreiben, teilweise mit Wakeup per Alarm oder per externem Pin, und praktisch immer auch mit etwas gepuffertem RAM, so um die 128 bytes, das ist mehr als der AtTiny insgesamt für SRAM, CPU-Register und Ports hat. So kriegt man auch einen Cortex-M3 in ultramobile Geräte.
Liebe ARM-Fraktion, jetzt mal Klartext, nennt mir doch mal für kleine Bastlerprojekte (die ja hier im Forum wohl in der Mehrheit zur Debatte stehen) einen Chip den man 1) selbst einlöten kann 2) der leicht und günstig erhältlich ist 3) so leicht wie AVR/PIC in eigene Hardware zu integrieren und 4) ebenso einfach mit Assembler zu programmieren ist!! Ich denke die Diskussion geht hier voll an den Bedürfnissen des Hobbyisten vorbei. Was für die Industrie wichtig sein mag (Preis/Leistung) ist da höchstens zweitrangig.
P.S. am besten gleich einen Chip der die Anforderungen meines aktuellen Projekts besser (=mehr SRAM+EEPROM) als mein jetziger XMega32A4U erfüllt: mindestens 5 UARTS und 5x16Bit Timer sowie ein paar freie IOs :-)
Moby schrieb: > 1) selbst einlöten kann > 2) der leicht und günstig erhältlich ist > 3) so leicht wie AVR/PIC in eigene Hardware zu integrieren und Vollkommen richtig! Was bringt mir ein 100Pinner im TQFP Gehäuse, wenn ich das nicht löten kann?
wer nicht mit der zeit geht, muss mit der zeit gehen. den xmega gibts ja auch nicht im DIP gehäuse oder hab ich was verpasst? und da macht ein vergleich mit einem cortex schon eher sinn. einen Atmega8 oder so vergleicht ja wohl niemand ernsthaft mit einem cortex und das löten ist nicht so das problem wie manch einer hier zu glauben scheint.
Moby schrieb: > 1) selbst einlöten kann > 2) der leicht und günstig erhältlich ist > 3) so leicht wie AVR/PIC in eigene Hardware zu integrieren und > 4) ebenso einfach mit Assembler zu programmieren ist!! 1) xQFP lässt sich mit ruhiger Hand und etwas Übung durchaus Löten. BGA kannst du da allerdings vergessen. 2) die Teile sind zu bekommen, allerdings nicht unbedingt bei jedem Teilelieferant. 3) Wo ist denn da der Unterschied? Welchen µC ich in meine Schaltung einbringe ist doch immer der gleiche Aufwand. 4) Wer in Assembler mehr macht als unbedingt notwendig kann man als Masochist bezeichnen. !!!!!! Es macht keinerlei Sinn !!!!!!!!! Assembler soviel wie notwendig, so wenig wie möglich. ==> Das macht dann keinen Unterschied zwischen den einzelnen Architekturen.
Für den Xmega sehe ich keine Anwendung, der kam einfach viel zu spät. Am meisten ärgert mich am Xmega, daß Atmel für die standard AVRs die Preise verdreifacht hat, um ihn in den Markt zu pressen. Der Schuß dürfte gründlich nach hinten losgegangen sein. Ich würde mir aber einen ATtiny85 mit CAN wünschen. So ein kleiner CAN-Slave mit 4 digital/analog IOs wäre sehr bequem einsetzbar. Und ein ATtiny84CAN für 10 IOs. Und ein ATmega328 mit 4*UART/LIN und 4*CAN als Hub. Peter
Nehme doch einen AMIS Chip als Hub. 2x AMIS = 4 Kanäle. Klappt super einfach und jeweils 2 Kanäle kann man mit einem ADUM sogar galvanisch getrennt aufbauen.
Steht an sich alles in meinem langen Post, aber ich verstehe die Berührungsängste. Darum nochmal Butter bei die Fische: Moby schrieb: > Liebe ARM-Fraktion, jetzt mal Klartext, nennt mir doch mal für kleine > Bastlerprojekte (die ja hier im Forum wohl in der Mehrheit zur Debatte > stehen) einen Chip den man > 1) selbst einlöten kann Wenn du jetzt sofort loslegen willst und nur DIP kannst/willst, ist die Auswahl natürlich gering. So spontan habe ich den LPC1114FA44 mit PLCC44-Gehäuse gefunden. 4 Euro bei Darisus, dazu ein Through-Hole-Sockel bei Reichelt für 39 Cent. Ein DIP-28 soll auch dieses Jahr noch erscheinen. Und mal ehrlich, ist TQFP-48 zu viel verlangt? Keiner behauptet, der Heimbastler soll TQFP-208 löten, die gibts auch in anfängerfreundlichen SMD-Gehäusen. Zwischen 10 und 20 Euro gibt es wie schon erwähnt die kleinen Entwicklerboards, die sind fürs Prototyping auf dem Breadboard ideal, denn die Platinen sind klein und haben Pins (oder Löcher für Pinleisten). Da ist dann der Programmer mit integriert, spart man sich also das Geld auch noch. Reicht das? > 2) der leicht und günstig erhältlich ist s.o. ARM ist billiger als AVR. > 3) so leicht wie AVR/PIC in eigene Hardware zu integrieren und Die genannten µCs sind von der externen Beschaltung genau auf AVR-Niveau. Interner RC-Oszillator, bei einigen ist der genau genug dass davon sogar der USB-Port betrieben werden kann, Hardware-UART, SPI, Timer, ADC, DAC, 5V-tolerante Pins usw. Alles was man gewohnt ist. > 4) ebenso einfach mit Assembler zu programmieren ist!! Auch das habe ich schon erzählt. ARM-Assembler ist sehr gut durchdacht, sehr logisch aufgebaut. Das macht deutlich mehr Spaß als AVR. Die Peripherie hat Register wie beim AVR, da konfiguriert man sich seinen Kram und gut. Die Datenblätter sind ähnlich aufgebaut wie bei AVR, allerdings gibt es da schon Qualitatsunterschiede zwischen den Herstellern. Eins ist klar: man ist erstmal ne Weile unproduktiv, weil man was neues lernen muss. "Anders" ist aber deswegen nicht "kompliziert". > Ich denke die Diskussion geht hier voll an den Bedürfnissen des > Hobbyisten vorbei. Was für die Industrie wichtig sein mag > (Preis/Leistung) ist da höchstens zweitrangig. Ich bin selber Hobbyist. Ich werde nie ein elektronisches Gerät entwerfen, das dann vermarktet wird. Aber ich sehe doch, dass ich teuer Geld für wenig Leistung (AVR) ausgeben kann, oder für weniger wesentlich mehr bekomme. Nur Bestellen beim Reichelt, das geht nicht so gut. Der hat nur Atmel-ARM7 ab LQFP-64 im Angebot, und die nicht besonders günstig. Der ist aber trotzdem nicht zu verachten, da ist die Dokumentation sicherlich näher an dem, was man schon von den 8-Bittern kennt, und bestimmt die Peripherie auch. Wer ARM will, muss schon separate Webshops bemühen. Die Bezugsquellenlisten der Artikel http://www.mikrocontroller.net/articles/STM32 und http://www.mikrocontroller.net/articles/LPC1xxx im Wiki sind da sehr hilfreich. Da ist der Preis dann auch besser.
Und zur not gibt es ja einache boards auf denen das ganze SMD futter samt oszilator, JTAG port, ... drauf ist die man dann auf seine patine stöpseln kann. (2,54mm raster)
Der XMEGA kostet je nach Modell zwischen 3 und 12 Euro. Bei allen Wünschen, was die Traum CPU denn alles können soll, was darf sie denn mit den neuen Features kosten ? Vielleicht gibt es ja schon die Lösung, ist den meisten aber zu teuer ... Gruß, dasrotemopped.
Sam P. schrieb: > Ich bin selber Hobbyist. Ich werde nie ein elektronisches Gerät > entwerfen, das dann vermarktet wird. Aber ich sehe doch, dass ich teuer > Geld für wenig Leistung (AVR) ausgeben kann, oder für weniger wesentlich > mehr bekomme. Im Hobbybereich hat DIP sehr viele Vorteile. Man kann schnell mal was auf ne Uniplatine pappen und ausprobieren. Und wenn man einen Fehler gemacht hat, lötet man eben um. Und wenn man mal den MC zerstört hat, steckt man einfach den nächsten in die IC-Fassung. Und wenn man später doch eine richtige Platine macht, muß es keine 4-Layer sein. Mit SMD würden die meisten Hobbyprojekte unvollendet bleiben. Man müßte erstmal eine Platine routen und fertigen lassen. Und dann ist ein IC kaputt und beim Runterlöten reißen Leiterzüge ab. Oder ein Schaltungsfehler und die Platine ist für die Tonne. Mit DIP spart man vielleicht nicht am Preis des MC, aber erheblich am Preis für das ganze Drumherum. Und Zeit spart man auch viel. Ich kann daher gut verstehen, daß im Hobby die 8-Bitter deutlich lieber genommen werden. Man nimmt einfach den AVR, pappt die 100nF Pille dran, eine Spannung 1,8..5,5V (muß nichtmal stabilisiert sein) und fertig ist die komplette Grundbeschaltung. Peter
Peter Dannegger schrieb: > Man nimmt einfach den AVR, pappt die 100nF Pille dran, eine Spannung > 1,8..5,5V (muß nichtmal stabilisiert sein) und fertig ist die komplette > Grundbeschaltung. Ja aber das isses doch: Nimm 1,8..3.3V, die obligatorischen 100nF, fertich. Wenn du auf den DIP-28 von NXP wartest oder den jetzt real existierenden PLCC nimmt (mit Sockel, den du ja sinnvollerweise auch bei DIP vorschlägst), geht das auch mit Lochraster. Wer einfach nur was steuern will, soll sich den mbed zulegen, der kommt als DIP-Platine daher. Da spart man sich neben der externen Beschaltung dann auch gleich den ganzen K(r)ampf mit Toolchain, Software und IDE, weil das Web-Basiert abläuft. Wird hier sogar an der Uni genutzt, eben wegen des schnellen Einstiegs. Nachteil ist, dass der mbed um die 50 Euro kostet. Guck dir mal auf http://mbed.org/handbook/mbed-Compiler an, wie einfach ein LED-Blinker ist. Das ist leichter als beim AVR. In den Kommentaren ist auch gezeigt, wie schmerzfrei man C und ASM mischen kann. Und wenn der Prototyp dann läuft, pappt man sich nen Standalone-Controller auf Platine.
Genau, DIP ist für Prototypen in Handarbeit einfach praktischer. Klar gibt es SMD zu DIP Adapter-Platinen, die sind aber in der Regel unverschämt teuer. Wieso eigentlich? Ich verwende oft sogar lieber mehrere kleine AVR's (mit I2C verbunden) anstatt einen großen, weil ich dann nicht so viele Pins auf einem Knubbel habe. Stell Dir mal einen DIP-Adapter für den ATmega128 vor. Müste ja doppel-reihige Stiftleisten habe - nicht gerade angenehm für Punktraster Arbeiten. Mit Lackdrähten kann man zwar sehr hohe Packungsdichten erreichen und da wäre dann auch egal, wie viele Pins pro Fläche belegt werden, aber das verkauft sich schlecht. Da haben die Kunden immer bedenken, bezüglich der haltbarkeit (obwohl mir noch nie eine solche Platine kaputt gegangen ist).
DIP finde ich als Bastler auch sehr praktisch, da haben Stefan und Peter recht. ABER: Welchen xmega gibt es denn bitte schön im DIP Gehäuse? Die Sache ist doch die, dass wenn ich enen µC in der Klasse (Speicher, Peripherie, Leistung) haben will, ich gleich zu einem Cortex greifen kann! Also Cortex statt xmega nicht Cortex statt ATtiny!
Peter Dannegger schrieb: > Man müßte > erstmal eine Platine routen und fertigen lassen. Jetzt weißt du, warum ich den BAE-Autorouter so mag. ;-) Ja, fertigen (oder fertigen lassen) muss man noch, aber dafür haben wir ja nun Jakob Kleinen.
Mit dem XMEGA hat Atmel schon einiges gegenüber den alten Mega Serie verbessert. Der Takt hat sich verdoppelt und vor allem gibt es DMA im XMEGA was einiges an Performance bringt. Allerdings muss man sagen das 8Bit nicht mehr wirklich zeitgemäß ist. Auch eine Floating Point Unit muss heute schon im µC vorhanden sein. Allerdings muss man sagen das die ARMs oft keinen internen EEPROM besitzen, diesen benötigt man ja oft um Geräteparametern abzuspeichern. Zudem benötigt man oft externen Flash für den Programmcode, dies ist oft umständlich
Wenn man Arm als DIP will, was spricht z.B. gegen die ST Discovery Boards?
Johann schrieb: > Zudem benötigt man oft externen Flash für den Programmcode, dies ist oft > umständlich Da vergleichst du aber Äpfel mit Birnen, also bspw. ARM9 mit Cortex-M3.
Moby schrieb: > P.S. am besten gleich einen Chip der die Anforderungen meines aktuellen > Projekts besser (=mehr SRAM+EEPROM) als mein jetziger XMega32A4U > erfüllt: mindestens 5 UARTS und 5x16Bit Timer sowie ein paar freie IOs > :-) ATxmega128A4U hat doppelt soviel SRAM und EEPROM und ist Pinkompatibel. Alle A4U sind Pinkompatibel, genauso wie die A1er untereinander usw.
Solange ein ATMEGA644 von Speicher under der Geschwindigkeit reicht, würde ich den nutzen. Danach wahrscheinlich eher Cortex. Xmega ist also übrig. Für einen Nachfolger: Lohnt sich eher nicht, da sind dann doch die Cortex einfach schon die bessere Wahl finde ich. OT: Meine Meinung: Für den Anfänger ist AVR (TINY/MEGA Serie) die erste Wahl. Ein Cortex ist einfach komplexer. Jetzt schreien viele: so ein Blödsinn. Klar, wenn man das zwei dreimal gemacht hat, dann bekommt man ihn auch leicht zum laufen. Aber so eine "Plug&PLay" Lösung wie AVR in Verbindung mit z.B. WinAVR gibt es nicht bei ARM. Man sollte schon den Clocktree durchblicken und die Taktfrequenz, die an den jeweiligen Peripherieeinheiten anliegen darf. Weiter noch die Powerverwaltung (Peripherie ein/aus) und das Interrupthandling beim Cortex ist zwar gut, aber muß auch erstmal durchblickt sein. Das alles ist beim AVR meiner Meinung nach deutlich einfacher. Wenn man dann noch die AVRLib mit der NEWLIB vergleicht, auch das läuft beim AVR ohne das man da extra Arbeit reinstecken muß Bei der NEWLIB ist da schon mehr Arbeit nötig. OK einige Toolchains erleichtern das auch. Und so eine ausführliche Doku wie es zur AVRLib gibt, sucht man bei der NEWLIB auch vergeblich. Startup-Code für 'C'... bei AVR braucht man keine Gedanken daran verschwenden, beim Cortex schon. Gut das haben einige IDEs auch schon gekappselt aber trotzdem bleibt es komplexer, wenn ich eine Kommandozeilen basierte Toolchain für den Cortex nutzen möchte. Mal eben schnell eine kleine Schaltung für einen Versuch zusammen stecken/löten geht mit DIP-Gehäusen auch schneller. Unterm Strich ist der AVR für Anfänger oder kleine Aufgaben einfacher. Zugegeben, die Cortexe haben ihren Reiz, aber sind auch deutlich komplexer. Aus Langeweile haben die Hersteller keine Peripherie-Lib dabeigelegt und damit versucht(!) den Einstieg zu erleichtern.
Ralph schrieb: > Wer in Assembler mehr macht als unbedingt notwendig kann man als > Masochist bezeichnen. > > !!!!!! Es macht keinerlei Sinn !!!!!!!!! Ich programmiere seit Jahren ausschließlich in Assembler und über dessen Vorteile muß man sich hier wirklich nicht mehr auslassen. Bislang langt mir ein Xmega als Standard-Controller- hat alles drin was ich brauche; die Programmiertools, erstellte Software und Wissen sind weiterverwendbar. Deshalb wünsche ich mir eher einen Nachfolger (mit mehr SRAM bitte) als auf ARM umzusteigen. Ein wenig ökonomisch sollte man mit seiner Lebenszeit auch umgehen- und nicht alle Jahre wieder von vorn beginnen... Aber OK, ich rede hier auch nur von einem Hobby :)
Moby schrieb: > über dessen > Vorteile muß man sich hier wirklich nicht mehr auslassen. wäre mal interessant zu hören. Es gibt keine !!!!
Alles hat seine Zeit, und wer nur einen Hammer hat, für den sieht alles wie ein Nagel aus. Ich habe hier inzwischen meine XMega-Alternative gefunden: PIC24/dsPIC. - 16 Bit, die dspICs haben zusätzlich 40-Bit Register und DSP-Erweiterungen - bis zu 70 MIPS (PIC24E/dspic33E) - kleinere Typen gibts auch als DIL - Serie geht von 14 Pins bis hin zu 100 Pinnern - bis zu 96k RAM eingebaut - Registersatz und Architektur ähnlich wie bei AVR (aber 16 bittig), die (Vor)Urteile gegenüber den 8 Bit PICs treffen hier nicht mehr zu - Programmieren und debuggen über 2 Pins+Reset, PicKit3-Clone gibts für 20 Euro in der Bucht beim Chinesen - Konzept mit Konfigurationswörtern ist ähnlich wie die Fuses bei den AVRs, aber man kann sich nicht aussperren - Peripherieauswahl teilweise besser, praktisches Konzept der Remappable Pins (Spezialfunktionen können auf jeden Portpin gelegt werden) - Entwicklungsumgebung: entweder das alte, stabile MPLAB8 (entspricht dem AVRStudio4, Windows only) oder das neue MPLAB X (entspricht dem AVRStudio 5/6, aber JAVA statt .net; läuft unter Windows, Linux, Mac OSX; alle drei Plattformen werden von Microchip aktiv unterstützt) Ich sage mal: wer AVR kennt, wird sich beim PIC24 relativ schnell zuhause fühlen, egal ob in C oder Assembler. Der PIC24 besetzt eben die Lücke zwischen den klassischen 8-Bittern AVR/PIC10/12/16/18 und den ARMs, d.h. sie sind so einfach anzuwenden wie AVRs, bieten dabei aber deutlich mehr Leistung und sind nicht teurer. Für größere Projekte greife ich auch zu PIC32 oder Cortex M3/M4, so ist das nicht. Es kommt eben auf den Einzelfall an. Ich persönlich habe also meinen Xmega-Nachfolger gefunden. Und das obwohl ich die komplette Entwicklungsumgebung für XMega da habe inkl JTAGICE 3 und XMEGA-A3BU Xplained Demoboard. fchk
Frank K. schrieb: > Ich habe hier inzwischen meine XMega-Alternative gefunden: PIC24/dsPIC. Gibt es für die eigentlich einen ordentlichen C++ Compiler? Ordentlich heißt dabei vor allem gute Template Unterstützung/Optimierung.
Moby schrieb: > Ein wenig ökonomisch sollte > man mit seiner Lebenszeit auch umgehen- und nicht alle Jahre wieder von > vorn beginnen... Das widerspricht allerdings der Assemblerprogrammierung. C ist extrem zeitökonomischer und auch portabel. Mit C fängt man bei einer anderen Architektur nicht von vorn an. Man macht direkt weiter. Moby schrieb: > Aber OK, ich rede hier auch nur von einem Hobby :) Bei einem Hobby ist ja der Weg das Ziel, d.h. die Programmierbeschäftigung und nicht das fertige Produkt. Insoweit ist die Wahl von Assembler natürlich richtig. Nur wer effizient und flexibel sein will, der benutzt C. Peter
Fabian G. schrieb: > Frank K. schrieb: >> Ich habe hier inzwischen meine XMega-Alternative gefunden: PIC24/dsPIC. > > Gibt es für die eigentlich einen ordentlichen C++ Compiler? Ordentlich > heißt dabei vor allem gute Template Unterstützung/Optimierung. Offiziell unterstützt Microchip kein C++. In der Praxis ist der C30 jedoch nur ein modifizierter gcc. Zu den Hitech-Compilern kann ich nichts sagen. fchk
Peter Dannegger schrieb: >> Ein wenig ökonomisch sollte >> man mit seiner Lebenszeit auch umgehen- und nicht alle Jahre wieder von >> vorn beginnen... > > Das widerspricht allerdings der Assemblerprogrammierung. Nun ja, da ist was dran und auch wieder nicht, je nachdem wie stark man eine Sprache verinnerlicht hat und mit welchem System man herangeht:) Für jeden verwendeten AVR (und das sind ganz wenige) verwende ich eine Vorlage mit allen wichtigen Grundinitialisierungen und fertigen abgekapselten, interruptgesteuerten Treiberbausteinen für die wenigen verwendeten peripheren Einheiten. Insofern kein erhöhter Aufwand. Die eigentliche Aufgabe ist oft genauso schnell gecodet. Die Kunst der Vereinfachung besteht dann auch darin sich hardwaremäßig zu beschränken. Einen XMega32A4U für 4 Euro etwa kann ich für die allermeisten Aufgaben einsetzen, Überdimensionierung in manchen Fällen hin oder her. Zuweilen freut man sich hinterher das man immer noch Reserven hat! Externe Baugruppen werden grundsätzlich via USART angebunden, Sensorik zuweilen via I2C. Das ist keine grundsätzliche Beschränkung, es gibt genügend Angebote/Bauteile dafür. Aufwendigere Standard-Dinge wie Anbindung von SD-Karten, Soundausgaben (meine Empfehlung: ump3 playback Modul) Bluetooth (BTM220) oder Internet (z.B. RN171) delegiert man. Wirklich kein Grund das selbst zu machen. Lohn der Mühe: Wunderbar kompakte, schnelle, übersichtliche Software bei wenig Schreibaufwand! Natürlich verzichtet man so auf die vielen fertigen C-Libs oder das Framework im neuen AVR-Studio. Zugegeben. Aber oft tauscht man die fertige (oft unangepasste) Funktion gegen allzuviel komplexe Doku und, noch schlimmer, unbekannte Nebeneffekte und Fehlerquellen ein. Peter Dannegger schrieb: > C ist ... auch portabel. Schön, mag sein, wenn man unterschiedliche Architekturen bedienen muß. Wann aber / warum sollte das im Hobbybereich nötig sein? Man entwickelt für ein Projekt mit einer Hardware- und das bleibt für mich auf absehbare Zeit der nicht komplizierter als nötige, bastlerfreundliche AVR! Peter Dannegger schrieb: > Nur wer effizient und flexibel > sein will, der benutzt C. Sorry, bezogen auf die eigentliche Programmierung der Hardware kann das nur heißen: Assembler!
Moby schrieb: >> Nur wer effizient und flexibel >> sein will, der benutzt C. > > Sorry, bezogen auf die eigentliche Programmierung der Hardware kann das > nur heißen: Assembler! Ihr meint zwei verschiedene Dinge mit Effizienz: du meinst die Ausnutzung der letzten 10 % Resourcen der Hardware, Peter meint die Effizienz des Programmierers (notwendiger Aufwand).
Ganz ehrlich: Wofür ein ATmega zu klein ist, setze ich ein Notebook ein. Oder eine Platine mit ARM (wie mbed oder STM32 Discovery). Ich habe keinen Bedarf für Xmegas. Mir würde es schon reichen, wenn es ATmegas mit erheblich mehr RAM (z.B. 64kB) geben würde, vorzugweise auch Modelle im DIP40 Gehäuse.
Der XMega ist schon besser als ein Mega, aber die Errata hat's auch in sich. Wenn der noch ne FPU hätte, würde ich ihn nur verwenden. An die Syntax gewöhnt man sich schnell. Gibt's für die ARMs auch ne freie IDE außer das Atmel Studio? Was mir negativ aufstößt ist z.B. Bei dem STM32F4 Discovery dass es erstmal sehr viel Aufwand ist eine IDE zu finden, die einfach zu handeln ist. Aber die Performance ist schon der Hammer, 168MHz, 192kB RAM und ne FPU, einfach geil... Ingo
Ingo schrieb: > aber die Errata hat's auch in > sich Hat sich mit den neuen U(SB) Typen meist erledigt Ingo schrieb: > STM32F4 Discovery ... 168MHz, 192kB RAM und ne FPU, > einfach geil... Ja geil schon, aber für 1 großes Projekt und nicht für viele kleine :)
Stefan Frings schrieb: > Ganz ehrlich: Wofür ein ATmega zu klein ist, setze ich ein Notebook ein. Na ja... ich gebe zu bedenken, Platz & Stromverbrauch :)
Ingo schrieb: > Gibt's für die ARMs auch ne freie IDE außer das Atmel Studio? Ja gibt es Ingo schrieb: > Was mir > negativ aufstößt ist z.B. Bei dem STM32F4 Discovery dass es erstmal sehr > viel Aufwand ist eine IDE zu finden, die einfach zu handeln ist. Einarbeitung in eine unbekannte IDE ist immer mit Arbeit verbunden. Mal mehr mal weniger. Mir persönlich gefällt der STM mit seiner IDE und Umgebung nicht besonders. Ich komme mit den Lm3sxxx von TI ( Stellaris) und der CodeComposerStudio IDE bedeutend besser zurecht.
Markus Horbach schrieb: > Der XMEGA kostet je nach Modell zwischen 3 und 12 Euro. Den Atxmega gibts sehr viel günstiger. Es gibt ja die leicht abgespeckte D-Variante. Der Atxmega16D4 kostet z.B. bei Mouser nur 1,4€, der 32er 1,68€. Selbst der ATXMEGA128D3 kostet nur 2,24€ (natürlich exkl. MwSt, bei Einzelabnahme). Wenn man mit einem UART weniger und auf den schnellen ADC verzichten kann ist es doch schon ein sehr annehmbarer Preis.
Spielt ihr hier µC Quartett??? So ließt es sich jedenfalls... Ich schlag mal paar Kategorien vor die mit auf die Karte müssen: USB Device: J/N µA im Deep Power Down: Preis pro 1k: Bitbreite: Max MHz: MfG Basti ;) P.S. : http://de.mouser.com/ProductDetail/Atmel/ATXMEGA32A4U-AU/?qs=HbI%2fMOA3e15cJNiXny0NsrxmAlxA1Fib16vg62fSimU%3d XMega 32 mit USB Device (läuft auch inoffiziell auf 48 MHz stabil) für unter 2 € ab 10 Stück .... So teuer sind die nun auch nicht ;)
Sebastian Förster schrieb: > µA im Deep Power Down: Frag' lieber nach µA im power-down mit Datenerhalt. Ansonsten hast du sofort wieder die Marketinheinis auf dem Hals, die dir als "deep power-down" nämlich einen komplett abgeschalteten Controller verkaufen, bei dem RAM-Inhalt und CPU-Register weg sind.
huch schrieb: > Ich wünsche mir für den Nachfolger einen ARM-Kern ;) Ja, ist OK, aber lieber eine Fujitsu-FR70-Kern, Bus 32 bittig herausgeführt und nen eingebauten TFT-Controller. SO. W.S.
W.S. schrieb: > lieber eine Fujitsu-FR70-Kern, Bus 32 bittig > herausgeführt und nen eingebauten TFT-Controller. Ja genau, was denn noch, Mensch Leute bleibt auf dem Teppich! Ein XMega ist mal in erster Linie AVR-kompatibel.
Was ihr immer gleich mit nen Xmega wollt. Ein ATtiny84 mit 2..4 Interruptprioritäten und CAN und ich wäre wunschlos glücklich. Peter
naja, als hobbyanwender sucht man sich ja aber lieber einen grossen controller mit platz für die zukunft, als sich alle 4 wochen mit einem neuen controller auseinanderzusetzen.
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.