Hallo Leute, wie der Titel erahnen lässt, geht es in diesem Thread hier um Präferenzen für bestimmte Mikrocontrollerfamilien. Jedoch soll das hier kein Bashing-Thread, wie viele andere, werden. Sondern ich möchte ganz gerne von euren Erfahrungen profitieren und gerne erfahren, warum Ihr welche Typen bevorzugt und wann man auch welche setzen sollte. Also was sind die Anforderungen, die bei einer Entscheidung eine Rolle spielen. Ich persönlich habe bisher Erfahrungen mit der AVR-Familie in C gesammelt (und früher etwas 8051 in ASM). Da mir der Vergleich zu anderen Familien fehlt, kann ich Aversionen gegen die AVR-Familie nicht verstehen. Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist, es gäbe dort Probleme mit Interrupt. Keine Ahnung mehr welche, ich glaube das hatte irgendwas mit freier Wählbarkeit oder Priorisierungen zutun. Genau kann ich es nicht wieder geben. Jetzt las ich auf Heise folgendes: http://www.heise.de/hardware-hacks/news/foren/S-Re-bringt-wohl-tatsaechlicht-nichts-Schneller-waere-es-natuerlich-Linux-anzupass/forum-225391/msg-21639707/read/ Und ich möchte ganz gerne wissen, ob diese Aversionen berechtigt sind? Wo liegen denn die Vorteile bei den PICs von Microchip und den MSP von TI und wie sie nicht alle heißen? Ich persönlich gehe da immer recht pragmatisch vor: -> Mit welchen µC kann ich eine bestimmte Aufgabe lösen? -> Wie hoch wäre der Aufwand, die Aufgabe mit den jeweiligen Controller zu lösen? -> Wie sind die Kosten und die Verfügbarkeit? Ich habe sicher auch bisher noch nicht die Hammer Projekte mit µCs gemacht, denn bisher konnte ich alle meine Aufgaben gleich gut (zu mindest glaube ich das) mit allen Familien lösen. Am Ende stellte sich für mich dann nur die Frage, mit welchen Familien habe ich die meisten Erfahrungen. Und da bleibe ich dann beim AVR hängen. Für ein Freizeitprojekt wiederum sind diese Punkte ja fast egal (abgesehen vom Preis). Ich werde sicher aus Neugier mich bald mit einem PIC beschäftigen. Leider fehlt mir dazu im Moment das passende Projekt. _ Was aber sagt Ihr? Worin liegen die Vorteile der jeweiligen Familien? Auch bei den µCs von Freescale und Infinion und Co. Auch kam mal der Marktanteil zu Sprache. Da sieht es bei der AVR-Familie aber auch nicht so schlimm aus: http://www.elektroniknet.de/automotive/technik-know-how/bauelemente/article/26993/0/Renesas_dominiert_Mikrocontroller_Infineon_neue_Nr1_im_Automotive-Geschaeft/ Wäre dankbar für einen interessanten Thread! Gruß Fabian
Fabian Hoemcke schrieb: > Da mir der Vergleich zu anderen Familien fehlt, kann ich Aversionen > gegen die AVR-Familie nicht verstehen. In diesem Board wirst du auch eher Aversionen gegen PICs finden. ;) Nein, im Ernst: Objetiv sollte man den Controller einsetzen, den man am besten kennt und der für die gestellte Aufgabe geeignet ist. Da sowohl bei Atmel als auch bei Microchip die Auswahl derartig groß ist das für alle Anwendungsfälle was dabei ist, ist es letztendlich immer eine subjektive Sache.
@ Fabian Hoemcke (Firma: Beuth Hochschule für Technik) (brein) >Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist, es gäbe >dort Probleme mit Interrupt. Jaja. War das der gleiche, der Komparatoren als OPV "nutzt"? >Keine Ahnung mehr welche, ich glaube das >hatte irgendwas mit freier Wählbarkeit oder Priorisierungen zutun. Die ist fest. Und man kann nur mit "Handarbeit" verschachtelte Interrupts nutzen. Spielt praktisch aber kaum eine Rolle, der AVR ist so schnell, dass es auch ohne geht ;-). Siehe Interrupt. >http://www.heise.de/hardware-hacks/news/foren/S-Re... >Und ich möchte ganz gerne wissen, ob diese Aversionen berechtigt sind? nein, das ist der übliche Internettmüll, aka Flameware. >Wo liegen denn die Vorteile bei den PICs von Microchip und den MSP von >TI und wie sie nicht alle heißen? siehe Flameware. ;-) >Ich habe sicher auch bisher noch nicht die Hammer Projekte mit µCs >gemacht, denn bisher konnte ich alle meine Aufgaben gleich gut (zu >mindest glaube ich das) mit allen Familien lösen. Das gilt auch für 99% aller Projekte im Hobbybereich und wahrscheinlich 90% aller Profiprojekte. MfG Falk
Fabian Hoemcke schrieb: > Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist, Es ist voellig egal, wie gut oder schlecht AVRs nun im Vergleich zu anderen Kontrollern sind - in Anbetracht der Tatsache, dass AVRs in vielen professionellen Anwendungen stecken, ist so eine Aussage einfach nur dumm und zeigt, wie viel von diesem Professor zu halten ist.
Falk Brunner schrieb: >>http://www.heise.de/hardware-hacks/news/foren/S-Re... ("Harvard völlig ungeeignet") >>Und ich möchte ganz gerne wissen, ob diese Aversionen berechtigt sind? > > nein, das ist der übliche Internettmüll, aka Flameware. Das wird natürlich dann auch von Leuten geschrieben, die gar nicht mehr wissen, dass UNIX auf einer Harvard-Maschine groß geworden ist: die mögliche Verdopplung des Speicherraums (je Prozess) der PDP-11 durch die Aufteilung in data and instruction memory wurde seinerzeit recht euphorisch begrüßt. Effektiv wurde damit aus der ursprünglichen von-Neumann-Architektur eine Harvard-Architektur (zumindest aus Sicht der Prozesse, auch wenn natürlich keine getrennten Busse existiert haben).
Also nur mal so vorneweg: Ich gehöre auch eher zu den Anfängern im Controllerbereich. Allerdings habe ich schon mit PIC, AVR und einem 8051 kleinere bis grössere Projekte realisiert. 8051 hatten wir in der Schule, war ich eigentlich immer recht zufrieden, hat mich aber nicht gerade umgehauen. PIC hat mich einfach nur angekotzt. Ich kann dir nicht mal sagen warum. Hat einfach lange nicht geklappt, war ein ewiges hin und her bis ich mal was zum Laufen gekriegt habe, muss aber natürlich nicht am PIC gelegen haben :) Entwicklungsumgebung gefällt mir auch nicht, Datenblätter finde ich aber übersichtlicher als die von AVR. AVR fand ich eigentlich von Anfang an gut. Mit AVRStudio 5 konnte ich mich sofort anfreunden, die Ein- und Ausgangsregister sind ein bisschen gewöhnungsbedürftig, allerdings bilden sie wohl einen Vorteil, wenn man mal den Durchblick hat. Aber eben, ist halt alles subjektiv. Jeder denkt ein bisschen anderst, ich denke die Logik im AVR entspricht noch am ehesten der Logik in meinem Kopf. Meine Projekte (Codeschloss, RGB-Lampe, Uhr) liessen sich aber wohl auf allen realisieren. Wie es bei hochkomplizierten Anwendungen aussieht vermag ich (noch) nicht zu beurteilen. MFG Dave
Mittlerweile kann ein µC von einem Hersteller auch das was die Konkurrenz-Controller können, in 90% aller Fälle. Was für mich entscheidend ist letzendlich, --> gibt es freie Compiler oder günstige Debugger für die µC-Familie --> gibt es den den Controller noch in 15 Jahren, man muß ja Ersatzteile liefern Es gibt Hersteller die garantieren Systemverfügbarkeit. Und es gibt Hersteller die mit großen TamTam Vertreter und Werbung auf einem losslassen, und dann ganze Familien abkündigen ... und Du sitzt da mit'ner Software die vielleicht nicht mal dokumentiert ist und mußt ein Redesign machen, mal so ganz fix ... AVR --> AVR Studio, hat seine Macken aber läuft frei, und sind lange Verfügbar Microchip --> garantieren Systemverfügbarkeit. Und Interrupts sind in sauberer oder sicherer Software sowieso nicht zulässig
Fabian Hoemcke schrieb: > Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist Und das ist wohl so was von typisches Sch**ss Klugschscheisser-Professoren-Gelaber. Ich glaube das kannst du getrost ignorieren.
mkausulm schrieb: > Und Interrupts sind in sauberer oder sicherer Software sowieso nicht > zulässig Das musst du jetzt mal erklären. Bin schon gespannt.
Also nur durch Bastler ist Atmel nicht knapp vor Microchip gelandet. Aber schenken tun die sich fast nichts. http://www.elektroniknet.de/bauelemente/news/article/86934/0/Die_groessten_Mikrocontroller-Hersteller_2011/ Ich setze beides ein ;) Hans
Fabian Hoemcke schrieb: > Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist, es gäbe > dort Probleme mit Interrupt. Keine Ahnung mehr welche, ich glaube das > hatte irgendwas mit freier Wählbarkeit oder Priorisierungen zutun. Genau > kann ich es nicht wieder geben. Die Aversionen sind aus meiner Sicht nicht berechtigt. Atmel (bzw die Uni Trondheim) hat beim Design des AVR-Kerns geigentlich gar nicht so schlechte Arbeit geleistet. Für mich liegen die eigentlichen Kritikpunkte woanders: 1. Atmel als Firma Atmel ist nicht gerade als zuverlässiger Lieferant bekannt. Sie hatten früher eigenene Halbleiterfabriken gehabt, haben aber fast alles verkauft und agieren weitgehend "fabless" wie viele andere auch. Das an sich ist nun nichts verwerfliches, machen andere auch. Atmel hat sich aber nicht unbedingt geschickt angestellt. Während der Krise 2008/2009 hatte ich zB ernsthafte Probleme, von denen Dataflashes (SPI-Flashbausteine mit kleiner Sektorgröße) zu bekommen. Verfügbarkeit Null. Selbst bei den AVRs gab es lange Lieferzeit, schon bei so popeligen Sachen wie nem Mega328p in TQFP. Wer so etwas life erlebt hat, ist nachher sehr vorsichtig, wenn es darum geht, Atmel-Zeugs einzudesignen. Anderes Thema: Abkündigung der AVR32AP7000'er Serie. Das hat etliche Leute kalt erwischt. Atmel hatte einfach nicht die personellen und finanziellen Kapazitäten, um AVR32 und ARM Cortex M3 gleichermaßen zu supporten, und haben bei AVR32 die Axt angesetzt. Autsch. Ein weiterer Grund, die Finger davon zu lassen. Microchip fertigt fast alles in eigenen Fabriken. In der Krise hatte ich keinerlei Probleme, irgendwas von denen zu bekommen. Die haben Anfang der 90'er, als sie aus General Instruments entstanden, einmal Massenabkündigungen gefahren, und dann nie wieder. Man kann von denen auch noch den ältesten PIC von 1984 bekommen. Ein Kunde, der unbedingt für irgendein zertifiziertes Design irgendeinen alten PIC brauchte, hat von denen noch ein "Lifetime Supply" bekommen, sprich: Die haben die alten Maskensätze rausgeholt und nochmal extra für ihn ein Dutzend Wafer durchlaufen lassen, so dass er für den Rest seines Lebens genug hat. Wenn man eigene Fabs hat, kann man das machen. So etwas schafft Vertrauen. 2. AVR und GGC AVR ist nicht zuletzt auch durch die Verfügbarkeit eines brauchbaren GCC-Ports populär geworden. Dabei sind AVR und GCC kein "Dream Team". Beim Design der AVR-Architektur saß IAR (schwedischer Compilerbauer) mit am Tisch, und die AVR-Architektur wurde an die IAR-Compiler angepasst. Der IAR-Compiler ist daher der beste Compiler, den man für AVR kaufen kann. Leider ist der auch saumäßig teuer, aber das spielt für Automotive keine Rolle. GCC erzeugt keinen optimalen Code, weil er eigentlich für 32 Bit Unix-Maschinen gedacht ist, und der Fokus bei der Weiterentwicklung des GCC liegen eher auf x86/x64/ARM/MIPS/PPC. Es kann sein, dass neuere GCC-Versionen größeren Code erzeugen als ältere. Die AVR-Portierung hängt immer hinterher und ist auch nicht in den Hauptzweig integriert. Die verschiedenen Adressräume sind für den GCC ein Hindernis - andere Compiler sind darauf wesentlich besser angepasst. Microchip hat das Heft selber in die Hand genommen und selbst Compiler entwickelt und einen Compilerhersteller (Hitech) gekauft. Für die 16-Bit PIC24/dsPIC haben sie einen eigenen GCC-Port gebaut, wobei PIC24 GGC-freundlich designt wurde. PIC32 hat eh einen MIPS-Kern (also im Prinzip das, was Mitte der 90'er in den fetten SGI Grafikworkstations werkelte), und dafür gabs bereits einen GCC-Port, bevor PIC32 existierte. Der Microchip Port ist nur besonders angepasst. 3. Support AVR schiebt vieles auf die Community ab, Microchip macht vieles eher selber. Siehe Compiler, TCP/IP-Stack, WLAN, Bluetooth, Grafik,... da hat Microchip einfach einen um Klassen besseren Support. 4. Preis Für den Preis einen AVRs bekomme ich auch einen kleinen PIC24/dsPIC, und der ist 16-bittig und deutlich schneller. Die XMegas sind von Preis/Rechenleistung her unattraktiv, dafür kann ich auch einen PIC32 oder Cortex M3 einsetzen, der zwei Klassen mehr Rechenleistung hat. Das wären meine Anmerkungen dazu. fchk
PS: 5. Peripherie Microchip hat im direkten Vergleich die bessere Auswahl an on-Chip Peripherie. Beispiele: - µC mit CAN in kleinen Gehäusen: AVR Fehlanzeige, PIC: viele - µC mit Ethernet integriert: AVR Fehlanzeige, PIC: 18F97J60 Serie fchk
@Frank: Das ist eine sehr schöne Zusammenfassung, die ich so unterschreiben würde. ein wichtiger Punkt ist noch die preisliche Situation. Es ist ein Trend zu beobachten, wo AVRs in letzter Zeit ganz gut im Preis anziehen. Die Gründe weiß ich nicht. Bin selbst aber auch AVR-Überzeugter.
Hi, Fabian Hoemcke schrieb: > Ich persönlich gehe da immer recht pragmatisch vor: > > -> Mit welchen µC kann ich eine bestimmte Aufgabe lösen? > -> Wie hoch wäre der Aufwand, die Aufgabe mit den jeweiligen Controller > zu lösen? > -> Wie sind die Kosten und die Verfügbarkeit? Bei kommerziellen Projekten ist das auch die EINZIG VERNÜNFTIGE Vorgehensweise. Wobei natürlich auch überlegungen wie "was setze ich in meinen Anderen Produkten ein, habe ich auf Lager usw." dabei im Rahmen der Aufwandsbetrachtung mit berücksichtigt werden müssen. (So das am Ende vielleicht der Zweitbeste Controller doch die bessere Wahl ist) Bei Privaten Bastelleien muss man es nicht ganz so streng sehen, ein gewisser Sinn steckt aber auch da hinter solchen Überlgungen. Aber BTT: Die AVR sind eine Controllerfamilie von vielen und gerade für Standardanwendungen genauso gut oder schlecht geeignet wie vergleichbare Typen anderer HErsteller (z.B. PIC18F) Allerdings polarisieren die AVR recht stark. Das liegt aber weniger an den Stärken oder Schwächen der Controller sondern eher ein teilen derer Fangemeinde. Es gibt da, genauso wie bei den Linuxanhängern, eine Reihe von "ULTRAFANS" bzw. "FANBOYS" die ihre Wahl als die Einzig Richtige ansehen und alles andere "Niedermachen" So konnte (und manchmal kann) man es auch hier im Forum oft beobachten. Wenn nach einem geeigneten Controller gefragt wird dann wird von einigen sofort REFLEXARTIG AVR genannt und andere Vorschläge gleich niedergemacht, selbst wenn die AVR gar keinen Sinn in dieser Anwendung machen. Wenn jemand ein Interessantes Projekt vorstellt das mit einem anderen µC als dem AVR realisiert wurde, dann ist mitunter die erste REaktion die Frage warum das nicht mit einem AVR gemacht wurde. (Besonders extrem lange Zeit wenn es ein PIC war) Oder es werden wahnsinns Klimmzüge gemacht um den AVR in seiner Schaltung ans LAufen zu bekommen, massig Peripherie verbaut usw. wo der Controller eines anderen HErstellers fast ohne Aussenbeschaltung bequem den Dienst versehen könnte. Und dieses Verhalten dieser Kreise kommt einem dann Schalgartig in den Sinn wenn man AVR hört und suggeriert dann das es sich beim AVR um einen "IdiotenController" handelt. Völlig ohne REale Grundlage im Sinne von HArdwarekriterien. Daher wird der AVR entweder HEIßGELIEBT oder schlechter gemacht als er ist! Mal etwas zu mir: ICh habe Erfahrung mit den AVR, aber setze sie (fast) nicht mehr ein. Bei Neudesigns überhaupt nicht mehr und in den letzten JAhren musste ich bei Altentwicklungen so einige überarbeiten und AVR ausdesignen. Privat habe ich schon einiges früher nach einer kurzen Euphoriephase die AVR Ad Akta gelegt und wieder die PICs bevorzugt obwohl bei vielen Dingen die AVR gleichermaßen geeignet gewesen währen. Die Beweggründe beim kommerziellen Entwickeln und bei den privaten Spielereien sind dabei aber teilweise andere. Im Kommerziellen Bereich ist besonders die Verfügbarkeit nach der Bankenkrise mit teilweise über 60 Wochen Lieferzeit ausschlaggebend gewesen und in folge dessen auch der Unwille von Seiten Atmels Firmen die "nur" einige hundert bis 10K µC/Monat verbauen irgendwie entgegen zu kommen. (Ist halt nur Kleinvieh) Im Privaten Bereich sind die Gründe vielfältiger, wobei ich sogar schon bei explizit privaten Anfragen aus der "Vor-Kommerziellen Zeit" das Gefühl hatte von Seiten Mircochips mehr entgegenkommen zu haben als ich es selbst bei Kontakt im Auftrag einer Firma mit einigen tausend µC/Monat jemals von ATMEL erfahren hat. Die genauen Gründe für die private Abkehr würden hier den Rahmen des Beitrags sprengen. Es hat allerdings nichts mit der Eignung zu tun (Ausser vielleicht das bei PIC die Auswahl an On Chip Periepherie viel Umfangreicher ist) sondern es sind alles "Soft Facts". Das Portfolio der von mir verwendete Controllerfamilien ist natürlich noch deutlich größer als nur PIC und Atmel AVR, aber diese beiden eignen sich doch am besten für einen Vergleich... Gruß Carsten
Hans schrieb: > Also nur durch Bastler ist Atmel nicht knapp vor Microchip > gelandet. > Aber schenken tun die sich fast nichts. http://www.elektroniknet.de/bauelemente/news/article/86934/0/Die_groessten_Mikrocontroller-Hersteller_2011/ Wobei du aber nicht vergessen darfst das diese Liste auf Basis der gesamten µC Verkäufe zustande kommen ist und atmel bei weitem nicht nur AVR herstellt. Da sind auch noch die ARM Familie und die 8051. Zudem sind die im Smartcardbereich recht stark. Gruß Carsten
Marwin schrieb: > Fabian Hoemcke schrieb: >> Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist, > Es ist voellig egal, wie gut oder schlecht AVRs nun im Vergleich zu > anderen Kontrollern sind - in Anbetracht der Tatsache, dass AVRs in > vielen professionellen Anwendungen stecken, ist so eine Aussage einfach > nur dumm und zeigt, wie viel von diesem Professor zu halten ist. Das er in so vielen Anwendungen steckt zeigt das er billig ist ;) Ich hab sehr viel mit MSP430 gemacht und dann ein Projekt mit ATTiny. Danach war mir klar das ich AVR Projekte nur noch machen werden wenn ich dazu gezwungen werde :) Das war mit dem ATTiny wirklich ein Krampf, da hatte man ständig im Hinterkopf wie viel einfacher jetzt ein MSP gewesen wäre.
@ Jörg S. (joerg-s) >Danach war mir klar das ich AVR Projekte nur noch machen werden wenn ich >dazu gezwungen werde :) Naja. >Das war mit dem ATTiny wirklich ein Krampf, da hatte man ständig im >Hinterkopf wie viel einfacher jetzt ein MSP gewesen wäre. Was denn?
Jörg S. schrieb: > Das er in so vielen Anwendungen steckt zeigt das er billig ist ;) Dabei gibt es doch laufend beschwerden, dass AVRs doch viel teurer seien als vergleichbare PICs. Auch in diesem Thread. Frank K. schrieb: > - µC mit CAN in kleinen Gehäusen: AVR Fehlanzeige, PIC: viele Der Vollständigkeit halber: was ist für dich klein? Der 16M1 sollte bis QFN erhältlich sein. Carsten Sch. schrieb: > Oder es werden wahnsinns Klimmzüge gemacht um den AVR in seiner > Schaltung ans LAufen zu bekommen, massig Peripherie verbaut usw. wo der > Controller eines anderen HErstellers fast ohne Aussenbeschaltung bequem > den Dienst versehen könnte. Wobei man bei Hobbyschaltungen auch beachten sollte, dass es viele nicht auf sich nehmen werden, sich in eine neue Controllerfamilie einzuarbeiten, nur weil diese für ein bestimmtes Projekt besser geeignet ist.
Dave Chappelle schrieb: >> Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist > > Und das ist wohl so was von typisches Sch**ss > Klugschscheisser-Professoren-Gelaber. Ich glaube das kannst du getrost > ignorieren. Sorry, aber dummes "Gelaber" kommt nicht nur von besagtem Prof. Schaut euch doch mal hochintegrierte 32-Bit Architekturen an, z.B. AVR32 - vielleicht seht ihr dann was mit Spielzeug gemeint ist. Bevor man persönlich beleidigt ist, weil einem jemand seine Ansichten mitgeteilt hat, sollte man vielleicht auch mal versuchen zu verstehen worum es eigentlich geht. Gruß, Edson
Meister Eder schrieb: > Dave Chappelle schrieb: >>> Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist >> >> Und das ist wohl so was von typisches Sch**ss >> Klugschscheisser-Professoren-Gelaber. Ich glaube das kannst du getrost >> ignorieren. > > Sorry, aber dummes "Gelaber" kommt nicht nur von besagtem Prof. Schaut > euch doch mal hochintegrierte 32-Bit Architekturen an, z.B. AVR32 - > vielleicht seht ihr dann was mit Spielzeug gemeint ist. Bitte? Willst du jetzt in jedem Kühlschrank einen 32 Bit Prozessor einsetzen oder was? Das, was du meinst ist nicht "Spielzeug" sondern eher "Kleinformat". > Bevor man persönlich beleidigt ist, weil einem jemand seine Ansichten > mitgeteilt hat, sollte man vielleicht auch mal versuchen zu verstehen > worum es eigentlich geht. Das gilt aber auch, bevor man mitreden möchte.
Warum ich AVR verwende ? Mein Stiefsohn hat sich den Kram von Velleman für die PICs mitgenommen und nie mehr zurückgebracht. Dann hat ein Bekannter von mir mich suf die AVR gehoben. Einfach so ;) Faszinierend finde ich, was heute in so kleine schwarze Käfer hineingeht. Mein erster 6510-Nachbau war da schon erheblich größer und konnte erheblich weniger ... Ich bin kein Dogmatiker - ich probiere das halt auch mal aus. Beruflich arbeite ich mit "echten" PCs und großen Datenvolumen, Speicher spielt keine Rolle. Aber einem ATTiny2312 mal bis auf's letzte Byte den Flash zuzumachen ist einfach interessant ...
Simon K. schrieb: > Bitte? Komm wieder runter. Simon K. schrieb: > Das, was du meinst ist nicht "Spielzeug" sondern eher "Kleinformat". Ok, wenn es dein Ego stärkt: dann halt Kleinformat. Simon K. schrieb: >> Bevor man persönlich beleidigt ist, weil einem jemand seine Ansichten >> mitgeteilt hat, sollte man vielleicht auch mal versuchen zu verstehen >> worum es eigentlich geht. > Das gilt aber auch, bevor man mitreden möchte. Dann fass dir mal an die eigene Nase. Siehe: Simon K. schrieb: > Willst du jetzt in jedem Kühlschrank einen 32 Bit Prozessor > einsetzen oder was? Diese "Frage" ist ja wohl außer provokant höchstens noch dämlich. Gruß, Edson
Wir gruenden einfach die NSAVRP ;) Ich hab auch schon nen paar ziemlich gute Ideen fuer wirkungsvolle Propaganda :D z.B. "Kill that PIC!" ;)
Ich arbeite recht gerne mit AVR-µC. Allerdings setzt sich bei mir mehr und mehr die Erkenntnis durch, dass ein Wechsel auf Cortex M3/M0 sinnvoll ist. Die Gründe sind für mich eher pragmatischer Natur: - gleicher/geringerer Preis bei wesentlich mehr Leistung - ein Programmieradapter kostet weniger als 10 Euro und ist Debugfähig - Zeitgemäßere Technik - Keine Verfuserei mehr - mehr Speed An AVRs mag ich: - Einfache Architektur - Kenne ich recht gut - Schöne IDE (AVR Studio) - Viele Bastlergehäuse (Dip) Gruß jonny
Liebe Leute, diese Diskussion ist mirnoch nicht konkret genug. Ich kenne mich ganz gut mit 8080, 80186, Z80, MCS51 Serie und AVR (nur 8 bit) aus. Von PIC und ARM habe ich noch gar keine Ahnung, weil ich bisher mit AVR und MCS51 immer gut zurecht gekommen war. Aber ich würde gerne mal erfahren, welche Vorteile PIC Controller im Vergleich zu AVR haben. Welche Features könnten mich dazu bewegen, mich mit PIC auseinander zu setzen. Woführ lohnt es sich, den Einsatz dieser Bauteile zu erlernen und in entsprechende Hardware (Programmer, Debugger, Evaluation Kits) zu investieren? Hier gibt es doch sicher Leute, die beide Konkurrenten kennen und mal die interessantesten Unterschiede nennen können, oder? PS: Geringfügige Performance Unterschiede, die sich aus dem Compiler oder Befehlssatz ergeben, finde ich persönlich uninteressant. Ob ein Controller nun 10 Mio oder 20 Mio Additionen pro Sekunde schafft, ist nur für die wenigsten Anwendungen von Bedeutung - jedenfalls was meine Anwendungen angeht. Mein AVR Webserver läuft auf einem AVR mit 20Mhz, würde aber auch mit 2Mhz zufriedenstellend funktionieren. Soviel zur Performance.
> Mein AVR Webserver läuft auf einem AVR mit 20Mhz, würde aber auch mit > 2Mhz zufriedenstellend funktionieren. Soviel zur Performance. wo du grade davon sprichst: Es gibt Cortex M3 Controller mit integriertem Mac+Phy. Das bedeutet, dass man den µC so nehmen kann wie er ist (abgesehen von ein bischen Hühnerfutter) und eine Ethernetbuchse direkt(!) anschließen kann und fertig ist die Hardware für einen Webserver. Sowas könnte für dich vielleicht von Interesse sein. lg jonny
vn nn schrieb: > Der Vollständigkeit halber: was ist für dich klein? Der 16M1 sollte bis > QFN erhältlich sein. 16M1 und erhältlich? Äh ... wo? (bitte mit Nennung der Lagerbestände) fchk
Mein AVR-Webserver läuft mit 16 MHz und 8KB. Mein "richtiger" mit 2,3 GHz und 4 GB. Über Performance braucht man nicht reden. Sie erfüllen aber beide ihre Zweck. Ist deswegen einer schlecht ?
Frank K. schrieb: > 16M1 und erhältlich? Äh ... wo? (bitte mit Nennung der Lagerbestände) Digikey z.B., Lagerbestand findest du online. War aber auch nur als Beispiel gedacht, da du die Frage nach "wie klein ist klein" immer noch nicht beantwortet hast, die Automotivecontroller sind natürlich auf dem freien Markt eher rar.
Vielleicht kann man die Unterschiede besser aufbrechen, um informiertere Entscheidungen machen zu können: * Hardward oder von Neumann: Kann Code aus dem RAM direkt ausgeführt werden, oder nicht. Harward hat gewisse Vorteile, da dadurch die Befehlsausführung sehr einfach sehr schnell werden kann, ohne die Echtzeitfähigkeit zu beeinträchtigen. Von Neumann-Architekturen ermöglichen es komplexere Betriebssysteme zu machen, die beispielsweise die Software von SD-Karte laden, oder Overlays verwenden * Integrierte Hardware: Da geht es auch viel um den persönlichen Geschmack. Ich musst mal einen Arm von ST programmieren, die Hardware konnte zwar viel, war aber umständlich anzusprechen. Ein ATMega hat da einfachere Hardware, die man schnell mal mit 4 Zeilen Assembler in Betrieb nehmen kann. * Softwareunterstützung: Gibts für die entsprechende Plattform freie Compiler und oder Assembler? Sind die brauchbar? Sind die installierbar? Das sind meiner Ansicht nach die wirklich großen Unterschiede.
>> Und Interrupts sind in sauberer oder sicherer Software sowieso nicht >> zulässig >Das musst du jetzt mal erklären. Bin schon gespannt. Das kann man nicht erklären, weils nicht stimmt. Kompliziertere Software (nicht simple SPS) hat immer mehrere INTs, die zudem in mehreren Prioritäten aufgeteilt sein muss. Da hat AVR ein Riessenproblem!! Denn schnelle INTs (bzw alle INTs) softw.mässig zu verarbeiten (die sonst ggfs wegen zu geringer Prio garnicht bei CPU ankämen) kostet extrem viel an Leistung. (...bis für die normale App fast nichts mehr übrig ist, und der uC nur noch Context-Switche macht...) Auch der XMEGA hat nur 3 Ebenen, auch zu wenig (warum haben die bei diesem Neudesign nicht mehr reingemacht?) Aber jede UC-Familie hat sein Macken! (manche haben nichtmal ein ExtBusInterface; manchen wirds schlecht, wenn sie mehr als 2 mA treiben sollen; manche gibts nur als BGA; manche kann man nur auf dem Papier kaufen; manche belügen einen;)
>* Hardward oder von Neumann: Kann Code aus dem RAM direkt ausgeführt >werden, oder nicht. Harward hat gewisse Vorteile,.... Diese Unterscheidung ist veraltet
also ich habe sowohl erfahrung mit PICs als auch mit AVRs gemacht. ich muss sagen die PICs haben mich deutlich mehr überzeugt für die PICs mit gibts MPLAB, finde ich übersichtlich und einfach gehandhabt. compiler gibts auf der seite zum laden das AVRstudio hingegen hät ich ko*** können. bei der 2010er version die anlehnung an visual studio hat mich schonmal abgeschreckt und nach dem ich die ressourcenverwaltung mir angesehen habe war mir auch bewusst warum. die umgebung frisst unmengen viel(meine erfahrung). und alleine dafür, dass ich meine software überspielen muss, ein menü aufrufen muss um dort ein untermenü zu öffnen wo dann ein button ist, ist mir zuviel. oder gibts da eine leichtere lösung? in MPLAB gabs da einen einfach button auf der "startseite" ansonsten finde ich beide controller arten recht gut. hatte mit den datenblättern keine probleme und die uC haben gemacht was sie sollten. einzigst sollte man die verfügbarkeit anmerken von weiteren bauteilen von microchip. bei einem projekt hatte ich einen fertigbausatz mit einem at90can und daran hing ein can-modul von microchip was ich ziemlich witzig fand. preislich finde ich die PICs top. dort kann man auch mal ein sample bestellen. bei atmel weiß ich das nun ausm kopf leider nicht :) aber denke mal da wird es auch was geben anhang: ich finde bei den PICs auch top, dort gibt es für nicht alt zu viel geld einen programmer der auch zu gleich debuggen kann. bei atmel wurde mir erstmal ein haufen zeugs angeboten, wo ich damals garnicht wusste was ich nun nehmen soll etc. pepe
Falk Brunner schrieb: >>Das war mit dem ATTiny wirklich ein Krampf, da hatte man ständig im >>Hinterkopf wie viel einfacher jetzt ein MSP gewesen wäre. > Was denn? Siehe: Beitrag "Re: Wieso Atmel?"
Stefan Frings schrieb: > Liebe Leute, > diese Diskussion ist mirnoch nicht konkret genug. > ... > Aber ich würde gerne mal erfahren, welche Vorteile PIC Controller im > Vergleich zu AVR haben. Welche Features könnten mich dazu bewegen, mich > mit PIC auseinander zu setzen. Woführ lohnt es sich, den Einsatz dieser > Bauteile zu erlernen und in entsprechende Hardware (Programmer, > Debugger, Evaluation Kits) zu investieren? ICh dachte dir geht es um die Voreingenommenheit gegenüber den AVR und nicht um die spezielle Diskussion PIC vs. AVR Den großteil der Gründe hat Frank schon recht ausführlich dargelegt. Aber neben dem im in meinem vorherigen BEitrag genannten Grund warum ich kommerziell wo es nur geht die AVR mittlerweile Meide hier nochmal meine Gründe für den (wieder-) Umstieg von AVR auf Pic im reinen Hobbbereich. ISt aber über weite Strecken Deckungsgleich mit Franks Meinung. * Bei PIC habe ich eine viel größere Peripherieauswahl. Es sind fast alle denkbaren Peripheriekombinationen verfügbar. Große Teile dieses Umfangreichen Sortiments sind auch über die den Hobbyisten zugänglichen Bezugkanäle verfügbar. Daher auch: * Bei PIC habe ich eine viel bessere Verfügbarkeit auch von Speziellen Teilen der Produktpalette * Bei PIC habe ich eine viel größere Auswahl an Gehäuseformen. Alle µC wo es technisch sinnvoll ist sind auch in DIP zu bekommen und werden immer noch neu auch in DIP herausgebracht. Das ist bei Hobbyprojekten für mich (im Gegensatz zu Auftragsentwicklungen) immer noch ein Argument. Selbst 16 und 32 Bit Controller in DIP gibt es. Bausteine mit CAN oder USB in DIP sind bei PIC Standard und überall zu bekommen. Bei AVR wie schon geschrieben Fehlanzeige. Da gibt es die nur in SMD und lange waren die in Kleinstückzahlen mit dieser Hardware auch nur schwer für Hobbyisten verfügbar. (Ist jetzt aber etwas besser, Reichelt hat die mittlerweile auch im Bestand - seit kurzem!) AVR mit Ehthernet im µC gibt es gar nicht! * Bisher habe ich von Microchip immer die deutlich bessere Unterstützung bkommen. Sei es zu den Zeiten wo ich "nur" der kleine Bastler war -und das auch zu erkennen gegeben habe- oder als ich mich im Rahmen von Hochschulprojekten um Unterstützung bemühte. Genauso wie als Entwickler. Von Atmel hingegen - fast Null. * Der für mich wohl wichtigste Punkt aber ist die Versorgung mit Frameworks, Beispielapplikationen und auch die Entwicklungstools. Wobei ich da ganz klar sage das da auch viel Geschmackssache hinter steht. ZWar hat Atmel natürlich auch einiges an AN und Programmbeispielen auf der Homepage, aber der Hauptteil des Supports erfolgt dezentral über die "Community". JA - Es gibt eine Menge Lösungen für einen großen Teil der zu lösenden Probleme im Netz. Ein Teil davon ist Mist, ein anderer brilliant! Bei Microchip gibt es einen viel Umfangreicheren Support an Frameworks, Libraries o.ä. vom Hersteller selbst. Als Folge davon ist der Teil der Lösungen durch dritte Parteien deutlich geringer als bei den AVR. Das es einen großen Anteil an Lösungen von vielen verschiedenen Quellen gibt ist für einige ja gerade DAS ARGUMENT für die AVR. Aber ich bevorzuge genau das Gegenteil. Bei den Lösungen durch dritte muss ich nicht selten erst einmal an vielen Stellen suchen und mir erst einmal Gedanken machen ob das überhaupt ein sinnvolle Lösung ist. Habe ich eine Lösung gefunden die mir gefällt muss ich dann sehen wie sieht es mit der Rechtefrage aus? Für Privatprojekte die den Hobbykeller nie verlassen völlig egal. Aber schon wenn ich die veröffentlichen will wird es Interessant. Und wenn es kommerziell wird erst recht! Da ist immer einiges zu beachten und vor allem können sich die eingeräumten Rechte auch mal ändern wenn der Autor das will! Ist das alles geklärt habe ich dann neben meinem Code eine Menge verschiedener Programmierstile in einem umfangreichen Projekt die schnell jeden Ansatz von eingeführten Konventionen über den Haufen werfen. Und natürlich hat man den Effekt das es für einige Dinge teilweise hunderte Lösungen gibt (z.B. Libs zur Ansteuerung von HD44780) aber für unpopuläre Dinge fast nichts! Bei Microchip hingegen kommt das alles aus einer HAnd, es passt zusammen was mir die Einführung vernünftiger Konventionen einfach macht. Die Rechtefrage ist klar (Zur absolut freien Verfügung solange auf PIC) und ich habe eine Stelle wo ich suchen muss. Bei den Softwaretools ist es Ähnlich. Für AVR gibt es die verschiedensten Tools, weit mehr als für PIC, aber man muss das alles auch zueinander passend hinbekommen. AVR Studio ist von Atmel selbst, aber schon der Compiler ist rein von dritter Seite bereitgestellt. Klar, GCC ist Open Source und wenn etwas nicht passt kann man -sofern man das Wissen hat- sicher leichter etwas dran ändern und den für sich anpassen als beim nicht/bzw nur teilweise offenen C Compiler von Microchip. Aber wenn ich das Wissen nicht habe und ich habe ein vielleicht nicht gerade populäres Problem habe ich keinerlei festen Ansprechpartner und niemand den ich auf die Finger hauen kann und muss einfach hoffen das sich irgendwann jemand der Sache mal annimmt. Auch so Sachen wie PID/VID Kennung bei USB Anwendungen zeigen das von MC da genauso auch an kleine Kunden gedacht wird. Gerade für Kleinserien wo die (zwingend notwendige) Beantragung einer eigene PID viel zu Unrentabel ist bietet Microchip es an auf Antrag KOSTENLOS eine individuelle VID/PID Kombination zuzuteilen. (VID ist dann eine von Microchip, PID wird dann von MC einzeln zugeteilt). Von Atmel gibt es soetwas überhaupt nicht. Einzig eine für alle gleiche PID darf genutzt werden wenn man keine eigene VID hat was natürlich bei Kommerziellen Projekten ein NoGo ist und selbst bei Hobbybetätigung schon mal ein echtes Problem mit sich bringen kann. * Und als letztes - Die Entwicklungshardware! Microchip hat schon früh für ganz kleines Geld Programmer herausgebracht die auch Debuggen können. Selbst das kleinste Modell ist für den Bastler völlig ausreichend und unterstützt ALLE aktuellen µC, von 8Bit bis zu 32Bit. Sowohl der Schaltplan wie auch die Firmware zu diesem Ding sind von der Microchipseite zu bekommen so das man sich auch selbst so ein Ding bauen könnte und es einige 100% Kompatible Clones für noch weniger Euros gibt. Dazu ist die Entwicklungsumgebung und die Hardwaretools für die volle Bandbreite der PICs geeignet. Mit dem Pickit3 für 30Euro kann man sowohl den 0815 PIC18F45K20 programmieren und debuggen wie den "großen" 32Bit PIC mit MIPS Kern PIC32MX795L. Natürlich auch die 16Bit PIC24 sowie die dSPIC mit rudimentären DSPfunktionen. Bei Atmel AVR waren die Debugging Möglichkeiten lange Zeit viel viel schlechter und auch nur mit Geräten möglich die das 10Fache des DebugFähigen PIC Programmers kosteten. Mittlerweile ist zwar mit dem Dragon auch für die AVR ein LowCost Debugger verfügbar, aber für den doppelten Preis eines PICKIT3 in der robusten Ausführung der auch teilweise dramatische Misshandlungen übersteht bekommt man da nur eine bestückte fragile Platine die in einigen Version schon durch eine einfache Berührung im Betrieb zerstört wird und wenn ich das jetzt richtig im Kopf habe keineswegs alle AVR unterstützt. Zudem gibt es beim PIC keinerlei Probleme mit Verfusen oder ähnlichen. Zum Abschluss noch eine Anmerkung zur Geschwindigkeit: Mir kommt es wie dir anscheinend auch in vielen Teilbereichen NICHT auf das letzte Quentchen Geschwindigkeit an. Wenn ich etwas "sehr Schnell" brauche nehme ich eh etwas "Leistungsfähigeres" Da dies aber immer als Argument "gegen" PICs genannt wird eine kurze Anmerkung dazu: JA- Bei den 8Bit PIC ist der Befehlstakt 1/4 des Oszillatortaktes was bei den AVR nicht der Fall ist. Wenn man dann aber etwas hinter die Kulissen schaut relativiert sich das sehr schnell! Denn die 1/4 Teilung beim PIC hat durchaus ihren Sinn da während eines Taktzyklus verschiedene Zustände durchlaufen werden. Dadurch sind fast alle Befehle der PICs in nur einem Taktzyklus abgearbeitet. Die meisten AVR Befehle brauchen aber mehr als einen Taktzyklus, zwei oder drei sind da die Regel! Da die moderneren 8Bit PICs aber mit 48 oder gar 64MHz Oszillatorfrequenz arbeiten können (Intern durch PLL erzeugt) sind diese im Endeffekt sogar schneller. Aber wie gesagt - Wenn es auf das letzte Quentchen GEschwindigkeit ankommt nehme ich lieber gleich einen Leistungsfähigeren µC! Daher ist dieses Argument eher relativ. Nur dem Protokoll wegen: Die 24er PIC haben nur eine Teilung durch 2, die 32Pics gar keine! Aber um auf deine Frage zurückzukommen: Einen wirklich ZWINGENDEN Grund sich neben den AVR auch mit den PICs zu beschäftigen gibt es insbesondere für Hobbyisten nicht. Im als Entwickler im gewerblichen Bereich hingegen sollte man zumindest die Möglichkeiten der meisten gängigen Familien kennen. Gerade bei den PIC erfordert dies ja auch keinen ungewöhnlichen Aufwand. Für den Anfang ist man mit 30Euro für einen Programer und Debugger dabei. Wenn mich jetzt jemand aber konkret so fragen würde, dann würde ich es zumindest so zusammenfassen: Pics haben die größere Auswahl an Möglichkeiten. Viele Bausteine einfach VErfügbar. Mit derselben günstigen Hardware und derselben Entwicklungsumgebung kann man vom kleinen 8Bit sechspinner über die 16Bit mit DSP Funktionalitäten bis hin zum 32Bit mit MIPS Kern alles Programmieren und bei den meisten PICs auch debuggen. Als Bastler hat man eine hohe Verfügbarkeit und insbesondere auch deutlich mehr an Bausteinen im DIP Gehäuse was dem schnellen Test auf Steckboard oder Lochraster (auf LR ja bleibende 1pcs Entwicklungen) enorm entgegen kommt. Auch zukünftig wird es eine Menge REleases in DIP noch geben. (Wogegen ATMEL das schon lange Einschränkt und zukünftig noch weiter Einschränken wird) Softwarem HArdware, Framework und Demos alles aus einer Hand mit (gefühlt) deutlich Kundenorientierten Support. Als letztes nenne ich dann einfach mal den Preis. Mittlerweile sind die meisten AVR deutlich teurer als die vergleichbaren PICs. Wenn man zum Beispiel den ATMEGA64 mit dem PIC18F46K20 vergleicht der hinsichtlich Speicher, RAM, Peripherie und GEschwindigkeit ähnliche Daten hat, so kostet der ATMEGA64 bei REichelt 6,95Euro, der PIC18F46K20 aber nur 2,40Euro. Oder der Vergleich vom ATMEGA32 mit dem PIC18F45K20 wo die Daten wieder ähnlich sind (wobei der Atmega geringfügig mehr Speicher hat, 1K6 Byte vs. 2K) so kostet der ATMEGA32 im DIP40 Gehäuse 3,90Euro, der PIC18F45K20 im DIP40 2,25Euro. Aber noch einmal: Das alles sind meiner Ansicht nach Vorteile der PICs. Aber es ist nicht so gravierend das man sich unebdingt als AVR Nutzer mit PICs beschäftigen müsste. Wobei es sicher nicht verkehrt ist ;-) ICh arbeite Hobbymäßig einfach lieber mit PIC, andere halt lieber mit AVR. Aber in meinem Fall war dann die Nichtverfügbarkeit vieler Bausteine in den letzten JAhren (Frank hat die Gründe genannt) halt der Grund das ich auch kommerziell wann immer es geht die Atmels nun meide und damit nun noch weniger Gründe habe mal wieder ein AVR Projekt zu machen. Das ist wirklich nur noch eine Ausnahme um in Übung zu bleiben falls im gewerblichen BEreich eine AVR Nutzung explizit gefordert wird und ich daher keine Wahlmöglichkeit habe. Gruß Carsten
Jörg S. schrieb: > Siehe: Beitrag "Re: Wieso Atmel?" Wobei der wesentliche Punkt dabei ist: "Als jahrelanger MSP430 Programmierer hab ich letztens ein ATTiny44 programmieren müssen." Glaub' mir, als jahrelanger AVR-Programmierer wäre ich genauso geschockt, was beim (setze hier den kleinsten MSP430 ein, den du finden kannst) alles so anders ist als beim ATmega1281, mit dem ich jeden Tag zu tun habe. Da hast da einfach Äpfel mit Bananen verglichen, und daraus geschlussfolgert, dass die Äpfel vom Bauern B den dir bekannten Bananen vom Bauern A ja nicht das Wasser reichen können, weshalb alle Äpfel wohl nicht so das Gelbe vom Ei seien. ;-)
NACHTRAG: Einen Punkt hatte ich noch vergessen Aufzuzählen: Die X Version von Microchip gibt es nicht nur für Windows sondern es wird auch eine LINUX und MAC version angeboten. AVR Studio von Atmel hingegen ist rein für Windows verfügbar. Und mit dem setzen auf VisualStudio als Grundlage wird die Hürde für die Nutzung unter Linux oder MAc noch höher gelegt. Es ist sicher möglich (Vermutlich etwas in Richtung VM, Bin selber kaum noch beim Thema Linux aktiv informiert). Aber es wird wohl mehr notwendig sein als eine einfache Installation. Gruß Carsten
Carsten Sch. schrieb: > Die X Version von Microchip Ach, Microchip gibt es jetzt in einer X-Version? SCNR :-)
Jörg Wunsch schrieb: > Glaub' mir, als jahrelanger AVR-Programmierer wäre ich genauso > geschockt, was beim (setze hier den kleinsten MSP430 ein, den du > finden kannst) alles so anders ist als beim ATmega1281, mit dem > ich jeden Tag zu tun habe. Es ging ja nicht um anders, sondern um weniger. Sicher lag die Entäuschung darin das man gewohnte Sachen (Eine Funktion kann auf 2 oder drei Pins gelegt werden, Interrupts für alle Pins, etc.) nicht da waren, aber das ungewohnte war dabei halt das diese Dinge einfach nicht existiert haben beim ATTiny. Arbeite derzeit mit einem PIC16, der ist auch erst mal ungewohnt, aber da hab ich wesentlich weniger Probleme. Allerdings auch nicht so gut wie MSP430 ;) > Da hast da einfach Äpfel mit Bananen verglichen,.. Na ja, der MSP430 mag eher ein 16Bit sein, aber der Zielmarkt ist schon identisch.
Carsten Sch. schrieb: > Die X Version von Microchip gibt es nicht nur für Windows sondern es > wird auch eine LINUX und MAC version angeboten. > AVR Studio von Atmel hingegen ist rein für Windows verfügbar. Und mit > dem setzen auf VisualStudio als Grundlage wird die Hürde für die Nutzung > unter Linux oder MAc noch höher gelegt. Gut, der Schritt hin zu Visual Studio (AVR-Studio 4 lief ja wenigstens beinahe unter Wine) wird mir sowieso immer ein Rätsel bleiben. Allein schon, weil es bereits ein Eclipse-Plugin gibt, an dem sich Atmel ja problemlos beteiligen hätte können. Hätte ihnen wohl Geld und Arbeit erspart und nebenbei auch noch Offenheit signalisiert.
Jörg S. schrieb: > Es ging ja nicht um anders, sondern um weniger. Klar, du hast dir ja auch den zweitkleinsten AVR (damals) ausgesucht (oder aussuchen müssen). Es ist irgendwie logisch, dass man für einen kleinen Preis oder eine kleine Bauform Abstriche an der Funktionalität machen muss. Wenn man den Blick mal aus einer anderen Richtung wählt, könnte man über den MSP430 zum Beispiel genervt sein, weil er zwar eine JTAG- Schnittstelle implementiert, aber kein JTAG. Einen JTAG-AVR kannst du mit einem beliebigen anderen JTAG-Device verketten (kann ein weiterer AVR sein, aber auch ein CPLD oder FPGA), das geht mit dem MSP430 nicht (habe ich zumindest so gehört). Ich denke, dass sich gerade diese beiden Familien im Großen und Ganzen nicht viel nehmen. Dein Beispiel ist dafür ein Typisches, warum man bei der Wahl einer Plattform am besten bei dem bleibt, was man schon kennt: man kommt damit am schnellsten zurecht.
Also, ich hab jetzt tatsächlich mal Mplap X für Linux heruntergeladen. Dabei ist mir negativ aufgefallen: #1 225MB nur für die IDE #2 Es gibt keine Pakete, so dass ich das ganze auch wieder einfach los werde wenns ist #3 Es gibt kein Repository damit ich automatisch Updates bekomme #4 Es ist langsam #5 Vieles ist irgendwie Verschoben, halb abgeschnitten und so. Das ist jedenfalls kein GTK oder QT #6 Man kann ich Quellcode nicht zoomen (Strg+Scrollen) #7 Man kann keine Blöcke von Code markieren (indem man mit dem Cursor in eine Ecke des auszuwählenden Rechtecks klickt und dann mit Strg+Shift in die andere) (Mit Blöcken meine ich wirklich Blöcke, nicht mehrere Zeilen) #8 Und eines der größten Übel: Auf der Homepage von dem X-Teil bekommt man nicht mal einen anständigen Compiler für 16F ohne dafür zu blechen... Gibts überhaupt einen? Vielleicht hätte man auch ne andere Grundlage als Netbeans wählen sollen... Was mir positiv aufgefallen ist: #1 Das es das Teil überhaupt für Linux gibt ;-) #2 Schon mal viel besser als MPLAB ohne X #3 Das das ganze mit Makefiles gesteuert wird. Somit lassen sich bestehende Projekte auch sehr leicht mit anderen Editoren/IDEs verheiraten Andererseits ist das alles auch schon wieder furchtbar kompliziert... Wenn ich ein neues AVR-Projekt mit makefile mache, dann kopiere ich ein anderes Makefile und passe ggf. das target, die Frequenz und die includes an. Hier geht das wohl bei weitem nicht so einfach, so wie das aussieht.. Der Gesamteindruck ist jetzt irgendwie.. überladen. Überall ploppt was auf, das ganze fügt sich kaum ins System ein, es ist total undurchsichtig und ohne Geld auch beschränkt. Der Mehrwert was mir die Aktion gebracht hat ist relativ wenig. Ich weis jetzt dass man auf Linux relativ einfach PICs programmieren kann. Dafür habe ich eine mehr oder weniger unbrauchbare IDE und einen beschränkten Compiler.. Aber zumindest für die Ausbildung (Pic erzwungen) sollts das Zeug tun. Ich werde wohl weiterhin bei GCC+Makefile+Geany+Avrdude bleiben. (Quasi das Kiss-Prinzip ;-) simpel, durchschaubar, schnell, klein)
Stefan Frings schrieb: > Aber ich würde gerne mal erfahren, welche Vorteile PIC Controller im > Vergleich zu AVR haben. Solche Anfragen können meiner Erfahrung nach sehr schnell Ausarten. Aber um die Anfrage ansich zu vergleichen: Welche Vorteile hat BMW gegenüber Audi? Das, was nicht Geschmacksabhängig ist, ist Modellabhängig. "Ein Audi A3 (100PS) hat viel zu wenig Platz und ist zu schwach. Nimm einen 5er BMW mit 200PS, der is viel toller und hat dazu auch mehr Leistung und Platz", wobei es trotzdem noch den Audi A8 mit 450PS gibt. Doch ich finde es gut, dass hier nur nach persönlichen Argumenten FÜR EINE µC-FAMILIE/HERSTELLER gefragt ist. So bleibt das Thema (der und der ist besser als der und der, weil...) hoffentlich rar. Ich benutze für Projekte ausschließlich PICs. Dazu gekommen bin ich durch meine Ausbildung zum Elektroniker für Geräte und Systeme. In dieser Ausbildung wurde/wird der PIC in der Berufsschule und in den Prüfungen und Projekten beim Betrieb behandelt. Ich hab dafür den ASM Befehlssatz gelernt und konnte ihn mir ohne große beschwerden merken (habe schon öfter gelesen, dass der PIC-ASM kompliziert/wirr/schwer/unlogisch/uneffektiv sein soll). Ich habe für all meine Projekte einen passenden PIC gefunden, ich konnte ihn mir Problemlos bei Reichelt kaufen, es hat alles soweit funktioniert und ich hatte nie das Bedürfnis, erst recht nicht den Zwang zu anderen Microcontroller-Familien auszuweichen. Wo ein PIC16F nicht mehr reicht, nehm ich ein PIC18F. Wo dieser nicht mehr reicht, nehm ich einen dsPIC und danach einen PIC32. Ich hab mir mal zum rumspielen einen dsPIC besorgt, jedoch hat mir ein 16F oder 18F bisher immer gereicht (das ist natürlich abhängig vom Projekt). Ich seh einfach keine Notwendigkeit, mich mit vergleichbaren µCs auseinander zu setzen, da ich diese Zeit auch in die Vertiefung der PICs stecken kann. Das einzige, wo es für mich aus meiner Sicht Sinn macht, mich damit zu beschäftigen, wären FPGAs und ARM Cortex. Jedoch hab ich die PICs nichtmal zur Hälfte ausgeschöpft, also wird bis dahin noch ein bisschen Zeit verstreichen. Ich will mit Folgendem nicht sagen, dass es keinen anderen Hersteller gibt, der "so oder noch besser" ist, es sind nur meine Erfahungen. Was ich gut an Microchip finde: - Es gibt für ansich alles, was man braucht, interne Peripherie. PWM, ADC, DAC (gut, 5bit bei 8bit PICs ist nicht sooo viel), CLC, I²C, SPI, UART, USB, Ethernet, CAN, usw. Abgesehen vom Ethernet alles auch im DIP, was mich als Bastler schon anspricht. - Ich finde die Datenblätter sehr, sehr übersichtlich. Ich finde alles sehr schnell, das Inhaltsverzeichnis ist verlinkt mit den Seiten und auch das Inhaltsregister der PDF (also nicht das in Textform am Anfang, sondern das, was man im Reader aufklappen kann) ist sehr fein Aufteilbar. Für alle PICs sind diese auch sehr ähnlich aufgebaut, also von PIC10 - PIC32. - Microchip bietet neben den PICs auch andere Bauteile an, wie: ADCs, DACs, Speicher, Controller, XBee, OPs, usw an und hat dazu nicht genauso gute Manuals wie bei den PICs, sondern oft auch ein Beispiel inkl. Code, wie man diese mit dem PIC verbinden und benutzen kann. - Der Support, selbst bei so "Nutzlosen" Kunden wie mir, der eine Jahresabnahme von 10-15 PICs hat, ist sehr gut. Mir wurde sogar Kostenfrei ein PICKIT3 zugesendet, nur weil ich meinte, ich will 3.3V PICs programmieren, was mit dem Brenner8 von Sprut nicht geht. Alles in Allem bin ich sehr zufrieden, habe noch Luft nach oben (dsPIC, PIC32) und hatte nie ein Problem, wo das Problem darin lag, den richtigen PIC zu finden. Was kann ich noch sagen... Preislich sind die PICs für mich gut, solange man neue PICs nimmt und nicht die überteuerten "alten Säcke" wie PIC16F84 graus. Was die Lieferzeit, Verfügbarkeit usw. angeht, bin ich leider der falsche Mann, doch laut Beiträgen hier (speziell von fchk) gibt es auch da nichts zu meckern. Wenn mich jemand fragt (oder jemand hier im Forum), sag ich immer, dass er/sie sich Informieren soll, welche µCs es gibt. Mit welchen Datenblättern kommt er besser zurecht, gibt es Freunde, die schon eine µC-Familie benutzen, um später evtl helfen zu können. DAS sind die Entscheidungskriterien, die ich für wichtig halte. Tutorials findet man für alles, Hilfe in Foren auch (zugegeben hauptsächlich AVR, PIC und ARM), einen passenden µC findet man, erschwinglich sind auch alle. Doch was nützt einem ein PIC, wenn man damit nicht klar kommt und sich nach einem AVR sehnt. Was nützt es, den Einstieg in µC mit AVRs zu machen, wenn Kollegen und/oder Freunde alle samt mit PICs arbeiten? Das einzige, wo ich jedem zu PIC raten würde, ist, wenn jemand beschließt, eine Ausbildung zum EGS zu machen, eben weil ich weiß, dass dort die PICs der Standard ist. Wenn man den ASM-Code und den Aufbau von PICs kennt und schonmal welche programmiert hat, fällt es einem VIEL leichter, eine gute Note im Test zu kriegen. PS: Ich find es ein Unding, wie die PICs hier vernachlässigt und diskriminiert werden. Jedes blöde AVR ist auf den Artikel verlinkt, aber das "PIC" nicht! ;)
>- Es gibt für ansich alles, was man braucht, interne Peripherie.
Aber kein ExtBusInterface!
Stefan Frings schrieb: > Aber ich würde gerne mal erfahren, welche Vorteile PIC Controller im > Vergleich zu AVR haben. Je nach gewünschter Anforderung ist es manchmal auch einfach nur der Preis. Im Hobbybereich ist das nahezu egal, bei größeren Stückzahlen jedoch nicht mehr. Wenn Du z.B. nur einen ganz "kleinen" µC benötigst ist der PIC10F200 unschlagbar günstig. Der kostet bei 5k Stück nur noch 0,32 US$.
>Wenn Du z.B. nur einen ganz "kleinen" µC benötigst ist der PIC10F200 >unschlagbar günstig. Der kostet bei 5k Stück nur noch 0,32 US$. Der wird dann aber durch den kleinsten STM8 getopt.
> Der wird dann aber durch den kleinsten STM8 getopt.
Glaube ich nicht. Lasse mich aber auch gerne belehren :-) Kannst Du Typ,
Bezugsquelle und Preise nennen? Oben genannter Preis stammt von
MicrochipDirect.
MCUA schrieb: >>- Es gibt für ansich alles, was man braucht, interne Peripherie. > Aber kein ExtBusInterface! Wenn du DMA meinst, irrst du dich. Oder ich seh den Unterschied nicht. Chris schrieb: > Wenn Du z.B. nur einen ganz "kleinen" µC benötigst ist der PIC10F200 > unschlagbar günstig. Der kostet bei 5k Stück nur noch 0,32 US$. Also ich seh den "PIC10F200T-I/OT" für 0,30 US$. Was ich vergessen hab, wo ich grad da war: Die Homepage von Microchip ist meiner Meinung sehr durchdacht, Übersichtlich und enthällt alles, was man braucht. Ich will einen PIC18F haben, also klick ich drauf und ich seh eine Übersicht ALLER PIC18F, die es gibt. Mit 2 klicks ist das Datenblatt offen. Es ist alles schön auf der ganzen Breite der Seite verteilt, dass man die PICs gleich vergleichen kann.
>> Der wird dann aber durch den kleinsten STM8 getopt. >Glaube ich nicht. Kannst du glauben. ST ist da sehr aggressiv. EBV hat die. PIC10F200: Achne, der hat 16 B RAM! STM8 (20 MIPS!) hat min 1kB RAM u 128B EEPROM! und einige Schnitte mit drauf.
Vielen Dank Leute für die aufschlussreichen Antworten. Ihr habt mir damit einen wirklich guten Eindruck zu mindest in die PIC-Familien gegeben. Aber mal ehrlich, über 50 Posts??? ^^ Ich wusste, dass Threads zu diesem Thema schnell groß werden. Hätte in dem Zeitraum mit vielleicht 5 oder 10 Antworten gerechnet, aber gleich 50? Das hatte mich umgehauen. Das hatte eine Weile gedauert, bis ich es durchgelesen hatte. Kam mir ja fast vor wie ein Troll obwohl das wirklich nicht in meiner Absicht lag. Auch ist mir bekannt, dass solche Threads leicht unsachlich werden können. Daher auch danke dafür, dass Ihr meiner Bitte, nach Sachlichkeit nachgekommen seid. Jetzt möchte ich kurz auf ein paar Punkte eingehen: Falk Brunner schrieb: >>Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist, es gäbe >>dort Probleme mit Interrupt. > > Jaja. War das der gleiche, der Komparatoren als OPV "nutzt"? Nein! Mit Nichten. Würde er es wissen, dass ich das tat, wäre ich wohl schon lange geext. ;) Leider hatte ich die entsprechende Vorlesung nicht bei ihm. Dann hätte ich mir und euch wohl so einiges ersparen können. Generell möchte ich auch sagen, dass ich nur seine Ansicht zu diesem Thema wieder gegeben habe. Mir ging es nicht darum diese Ansicht als solche in Frage zu stellen, sondern dass Thema, dass damit aufgeworfen wurde zu erörtern. Also bitte urteilt nicht über den Prof, sondern über die µC. Und nach allem was ich gelesen habe, ist es ja auch nicht unbegründet, wenngleich auch nicht differenziert. Carsten Sch. schrieb: > Oder es werden wahnsinns Klimmzüge gemacht um den AVR in seiner > Schaltung ans LAufen zu bekommen, massig Peripherie verbaut usw. wo der > Controller eines anderen HErstellers fast ohne Aussenbeschaltung bequem > den Dienst versehen könnte. Genau das ist einer der Punkte, worauf ich hinaus wollte. Was waren das für Klimmzüge die gemacht werden mussten? Und wie, besser mit welchem µC hätte man das einfacher haben können? Hier wäre ein Beispiel super, damit ich mir das besser vorstellen kann. Carsten Sch. schrieb: > Verfügbarkeit nach der Bankenkrise mit teilweise über > 60 Wochen Lieferzeit Das ist natürlich ein Unding. OK, diese Lieferengpässe sind auch bei ATMEL nicht Usus, aber das ist schon krass. Zumal das eine Finanzkrise war und nicht Fukushima. Carsten Sch. schrieb: > PID/VID Kennung bei USB Anwendungen Damit hatte ich bisher nie zutun. Fragt sich auch ob jemals. Aber das ist durchaus nachvollziehbar. Was hat sowas für Folgen? Werden AVRs nicht in USB-Produkte/-Projekte eingesetzt? Tim R. schrieb: > ich finde bei den PICs auch top, dort gibt es für nicht alt zu > viel geld einen programmer der auch zu gleich debuggen kann. Carsten Sch. schrieb: > * Und als letztes - Die Entwicklungshardware! > Microchip hat schon früh für ganz kleines Geld Programmer herausgebracht > die auch Debuggen können. Selbst das kleinste Modell ist für den Bastler > völlig ausreichend und unterstützt ALLE aktuellen µC, von 8Bit bis zu > 32Bit. Sowohl der Schaltplan wie auch die Firmware zu diesem Ding sind > von der Microchipseite zu bekommen so das man sich auch selbst so ein > Ding bauen könnte und es einige 100% Kompatible Clones für noch weniger > Euros gibt. Das hört sich schon mal gut an. Ich hatte, (als ich noch etwas mehr Geld verdient hatte) mir ohne zu zögern das STK500 zugelegt, dass bis heute noch 80€ kostet. Viel zu viel Geld, für das, was ich jetzt im Nachhinein sehe, dass es kann. OK, cool ist die Sache mit den Oscis und den verschiedenen Spannungen die man über AVRDude einstellen kann. Aber dass man noch nicht mal alle ATtiny und ATmegas (z.B. 128 | also nur DIPs) programmieren kann ist schon traurig. Und die Zusatzmodule, mit denen man das könnte kosten ebenso viel Geld und sind zum Teil gar nicht mehr verfügbar (STK501). Das ganze Spiel geht mit dem STK600 weiter. Carsten Sch. schrieb: > Pickit3 für 30Euro OK, erst 80€ ausgeben und dann fragen ob es nicht noch billiger geht. ^^ Aber ja, gibt es nicht auch solch' universelle Programmer für weniger Geld? http://www.ebay.de/itm/AUSVERKAUF-PIC-PROGRAMMER-KIT-8-18-28-40PIN-MICROCHIP-/200382626290?pt=LH_DefaultDomain_77&hash=item2ea7bc39f2 http://www.ebay.de/itm/PIC-EEPROM-Programmer-PIC-16F84-24Cxxx-/280821404654?pt=Wissenschaftliche_Ger%C3%A4te&hash=item41624293ee <-- Das ist eher ein Scherz! ;) Über die Controller von TI wurde bisher kaum was gesagt. Obwohl ich mir sicher bald mal das LaunchPad besorgen werde. http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_(MSP-EXP430G2)#Meet_the_LaunchPad_.28MSP-EXP430G2.29 Das Ding kostet selbst mit dem Touch-Modul fast nix, und wenn man sich mal durchließt, was die MSP430 alles so an Peripherie haben, stehen die den µCs von MC und ATMEL in Nichts nach. Außerdem sind die MSPs bekannt für ihre geringe Power Consumption. Was wohl deren großer Vorteil ist. Zu den Controllern von Freescale und Infinion wurde hier noch gar nicht geurteilt, oder habe ich was überlesen? So, zu letzt möchte ich noch ein Wort über die IDE verlieren. Eingangs hatte ich diesen Aspekt übersehen. Da ATMEL vieles der Community überlässt, gibt es viele Lösungen auch für Linux. OK soweit. Ich persönlich und da bin ich gefestigt, benutze eclipse. Ich kann verstehen, wenn andere es nicht mögen und wenn sie es nur wegen Java nicht mögen, aber ich benutze es für fast alles. Ich kann damit in Jave/C/C++/ASM/Java-Dalvic und viele weite Programmiersprachen für die verdienen Targets programmieren. Selbst Python soll wohl möglich sein und mit Sigasi kann ich sogar für FPGAs programmieren, wenn auch nicht mit Schematics. Ich finde die Usability und die Features klasse. Wenn auch da noch Patz nach oben ist. Einziger Wermutstropfen, für C# muss ich Mono und MonoDevelop nehmen. Zurück zum Thema, da ich hauptsächlich unter Linux programmiere, gibt es denn auch gute Toolchains für andere µC-Familien? Gut, gelesen haben wir, dass MPLAB nicht so prall ist, aber die Tools für Linux gibt. Anzunehmen ist dann wohl auch, dass es sie auch für eclipse gibt. Werde es bei Gelegenheit prüfen. Wie sieht es mit den µCs von TI und den anderen Herstellern aus? Was ARMs angeht, so ist das für mich eine andere Klasse von µC. Ein wenig so wie LKWs und Familienkutschen (wollte jetzt auch mal ein hinkendes Auto-Gleichnis unterbringen ;)). Werde mich sicher auch mal damit Beschäftigen. Auch Boards dafür sind jetzt nicht so teuer: STM32 VL DISCOVERY gibt es für 15€ bei www.segor.de und im Embedded Project Journal findet man etliche solcher Anzeigen. Jedoch will ich das jetzt hier nicht durcheinander werfen. Das einzige was mich dazu noch interessieren könnte ist, wie hoch ist/vermutet Ihr die Zuverlässigkeit von ATMEL bezüglich ihrer ARM-based Controller? Ansonsten bedanke ich mich sehr für eure Beiträge und wünsche euch noch einen schönen Abend! Fabian
Hi, MCUA schrieb: >>- Es gibt für ansich alles, was man braucht, interne Peripherie. > Aber kein ExtBusInterface! DOCH - Das gibt es bei diversen PICs auch! HAlt nicht bei allen. Wie gesagt: Vielfältige Peripherie und man wählt was man braucht! Simon S. schrieb: > Also, ich hab jetzt tatsächlich mal Mplap X für Linux heruntergeladen. > Dabei ist mir negativ aufgefallen: > > #1 225MB nur für die IDE Naja, das ist schon Happig... Aber doch nichts gegen die 396 für AVR Studio5. Von den 616MB für die FullInstallation mal ganz zu schweigen ;-) Simon S. schrieb: > #8 Und eines der größten Übel: Auf der Homepage von dem X-Teil bekommt > man nicht mal einen anständigen Compiler für 16F ohne dafür zu > blechen... Gibts überhaupt einen? Da hast du dann aber nicht richtig GEschaut. ODer es ist noch etwas wegen den gerade laufenden Seitenumbau (Seit ein paar Tagen sind da laufend Änderungen zu beobachten) noch unter dem Tisch gefallen. Es gibt sowohl die eine Version des HiTEch Compilers für die PIC10/12/16 kostenlos, genauso wie es jetzt für MPLAB X mit dem XC 8 einen Compiler gibt der ALLE 8Bitter von PIC10 bis PIC18 unterstützt. Ebenfalls kostenlos verfügbar. Simon S. schrieb: > es ist total undurchsichtig und ohne Geld auch beschränkt. Ob es wirklich undurchsichtig ist oder das nur ein allererster Eindruck ist muss ich selbst auch noch eruieren. ICh hatte mir das vor ein paar Monaten schon mal kurz angesehen, aber da lag mir die 8er Version noch mehr und vor allem da MPLABX da noch ausdrücklich als BETA gekennzeichnet war kam es für mich im kommerziellen Umfeld eh nicht in Frage, zumal die 8er Version völlig ausreicht. Ohne GEld beschränkt stimmt so ganz auch nicht. DIE COMPILER sind teilweise etwas Beschränkt, zumindest nach Ablauf von 60Tagen wenn man die ProVersion installiert (die Kostenlose Lite Version ist immer einheitlich). Diese Beschränkung bezieht sich aber auch nur auf den maximalen Optimierungsgrad und damit macht es bei großen Programmen dann manchmal den Unterschied aus ob das Programm noch in die PIC Variante mit kleinem Speicher passt oder ob es doch die nächsthöhere Stufe sein muss die 10%. mehr Kostet pro Stück. Für Hobbyisten und Kleinserien VÖLLIG Irrelevant, bei Massenproduktion ist das dann natürlich schon ein Unterschied wenn man pro Tag 5000 PICs Verbaut und pro PIC 20 ct. Einspart sind es schon tausend Euro pro Tag. WEnn es dann gar 50K Pics/Tag sind... Aber für den Hobbyist der 20 Pics/JAhr Verbaut macht das dann einen Unterschied von vielleicht 5Euro/Jahr aus... Wobei ich meine das es sogar bisher nicht untersagt war in der TrialPEriode mit dem Compiler -der ja volle Optimierung hatte- Code mit maximaler Effizienz zu generieren und die fertigen HexFiles dann auch nach ende der TrialPeriode weiterhin kommerziell zu nutzen. Aber Festnageln lassen würde ich mich darauf jetzt nicht. Zum Rest kann ich aber nichts sagen, mir gefällt Momentan noch die Version 8 einfach besser. Wenn das aktuell laufende Projekt beendet ist wollte ich mir die Version X noch mal genauer ansehen, auf kurz oder lang wird da kein Weg dran vorbeiführen, aber momentan stehe ich eher hinter dem etwas simpleren ohne zu viel Schnickschnak. Sicher - Es ist keine Frage: Auch die PICs sind nicht in jeder Hinsicht die Perfekten Controller. Es gibt auch bei denen Schwachpunkte. Aber die gibt es nun einmal bei jedem Controller und man muss selbst sehen welche Punkte einem selbst wichtig sind und welche keine Rolle spielen und dann seine Entscheidung darauf aufbauen. Und da ist bei mir im privaten Bereich unter den 8Bittern nun einmal die PIC Familie der Punktsieger. Im 32Bit Bereich mache ich geringfügig mehr mit den ARM, aber PIC32 sind nah dran, verteilung vielleicht 60/40. Kommt halt darauf an wo ich gerade den am besten geeigneten Controller finde. Wobei sich die ARM dann noch auf die drei HErsteller NXP, STM und TI aufteilen. Gruß Carsten P.S.: ICh habe gerade überrascht festgestellt das Microchip jetzt auch 8051 fertigt/fertigen will. Es handelt sich dabei um Ersatzprodukte für die von NXP abgekündigten 80(c)51 Prozessoren die dazu 100% Kompatibel sind. Wobei dazu im Moment keinerlei vergleichbare Softwareunterstützung wie bei den PIC vorhanden ist und auch die Tools -zumindest im Moment- absolut nicht zu den PIC kompatibel sind. (Wobei ich anhand der Werbeaussagen vermute das es für diese auch über kurz oder Lang Pinkompatible Typen mit PIC Kern geben wird- Im Moment würde ich dann zumindest für einen Typ Luftsprünge machen) Das die die Produktion von abgekündigter Bauteile anderer aufnehmen zeigt auch wieder recht gut das bei Microchip die "Renditeschwelle" ab der die die Produktion einer Serie für Sinnvoll halten scheinbar DEUTLICH niedriger liegt als bei vielen anderen die immer wieder mit radikalen Abkündigungen auf sich aufmerksam machen. Was ein riesen Pluspunkt für jeden ist der diese Bausteine in Produkten mit einem geplant langen Produktionszeitraum einsetzen will.
Carsten Sch. schrieb: > P.S.: ICh habe gerade überrascht festgestellt das Microchip jetzt auch > 8051 fertigt/fertigen will. Es handelt sich dabei um Ersatzprodukte für > die von NXP abgekündigten 80(c)51 Prozessoren die dazu 100% Kompatibel > sind. Wobei dazu im Moment keinerlei vergleichbare Softwareunterstützung > wie bei den PIC vorhanden ist und auch die Tools -zumindest im Moment- > absolut nicht zu den PIC kompatibel sind. Auf http://www.microchip.com/pagehandler/en-us/family/8051legacy/products/home.html gibts die Vergleichsliste. Ich hab einfach mal geguckt, diese sind Samplebar und auch "In Stock", also theoretisch sofort lieferbar: SST89C58RC SST89E516RD SST89E516RD2 SST89V516RD2 Nur da, wie von dir erwähnt, sich diese nicht mit dem PICKIT brennen lassen, ist dies für mich eher unrelevant. Ich komm wie gesagt mit den PICs klar und nur um zu testen, kauf ich mir keine neue Hardware.
Fabian Hoemcke schrieb: > Carsten Sch. schrieb: >> Oder es werden wahnsinns Klimmzüge gemacht um den AVR in seiner >> Schaltung ans LAufen zu bekommen, massig Peripherie verbaut usw. wo der >> Controller eines anderen HErstellers fast ohne Aussenbeschaltung bequem >> den Dienst versehen könnte. > Genau das ist einer der Punkte, worauf ich hinaus wollte. Was waren das > für Klimmzüge die gemacht werden mussten? Und wie, besser mit welchem µC > hätte man das einfacher haben können? > Hier wäre ein Beispiel super, damit ich mir das besser vorstellen kann. Naja, so ohne weiteres jetzt kanpp und konkret das nachvollzuiehbar zu beschreiben ist so eine Sache. Aber ich denke ein gutes Beispiel ist die USB Geschichte: USB AVR waren für Hobbyisten lange Zeit schwer zu bekommen und sind auch heute ja nur in SMD verfügbar. Und das Anfangs auch nur in nicht mehr Anfängerfreundlichen GEhäusen mit 64 Pins und ähnliches. Gibt jetzt zwar auch versionen im TFQP32, aber das ist noch nicht so lange. Aus diesen Grund hat sich zu diesem Zeitpunkt jemand dann die Mühe gemacht und eine USB Version rein in Software implementiert die über normale IOs läuft und die auch noch heute Rege benutzt wird. Nicht falsch verstehen, diese REalisierung das es funktioniert ist für sich selbst betrachtet natürlich schon eine echte Leistung. Keine Frage. Aber technsich macht es wenig Sinn. Es ist recht unflexibel, frisst enorme Ressourcen und ist auch nicht wirklich dem Standard entsprechend so das es durchaus auch Verbindungsprobleme geben kann. Das alles aber wo es für weniger Euros als man für den "normalen" Atmel ausgeben müsste unzählige Varianten von µC mit integrierter USB HArdware von anderen HErstellern in allen GEhäuservarianten problemlos bei jedem 0815 Elektronikversender und selbst schon manchen kleinen Lädchen bekommen konnte. Und das war auch schon so als diese USB in SOftware Lösung aufkam. Ein etwas differenzierter zu sehendes Beispiel sind dann Dinge wo externe Zusatzbausteine angeschlossen werden die eine eigene Intelligenz haben - nur um eine Funktionalität zu haben die Controller anderer HErsteller, die auch noch WENIGER KOSTEN als der reine Zusatzbaustein, schon integriert haben. Als Beispiel greife ich mal hier auch auf USB zurück wo dann lieber der FTDI für 4-5 Euro verwendet wird anstelle einen Controller mit internem USB zu nehmen die es als Pic ab 2 Euro bis hin zu 5Euro für die große Version gibt. Auch in ALLEN GEhäuseformen, also problemlos auch ohne SMD verarbeiten zu können benutzbar. (Wobei es ja nicht nur PIC gibt, das gilt für andere Hersteller genauso, z.B. Renesas wird hier kaum genannt, ist in verkauften Controllern gemessen aber vor Atmel und Microchip!) > Carsten Sch. schrieb: >> Verfügbarkeit nach der Bankenkrise mit teilweise über >> 60 Wochen Lieferzeit > Das ist natürlich ein Unding. OK, diese Lieferengpässe sind auch bei > ATMEL nicht Usus, aber das ist schon krass. > Zumal das eine Finanzkrise war und nicht Fukushima. JA, es war einfach unmöglich. Das bedeutet für die Betroffenen Unternehmen ja nichts anderes als das die 60Wochen nicht produzieren können (oder redesignen müssen). Und das war ein rein hausgemachtes Problem und damit jederzeit wiederholbar! > > Carsten Sch. schrieb: >> PID/VID Kennung bei USB Anwendungen > Damit hatte ich bisher nie zutun. Fragt sich auch ob jemals. > Aber das ist durchaus nachvollziehbar. > Was hat sowas für Folgen? Werden AVRs nicht in USB-Produkte/-Projekte > eingesetzt? Doch, natürlich werden auch die AT90USB und ARM von Atmel in USB Produkten eingesetzt. Aber das geht halt nur wenn die Firma eine eigene VID hat die mal schnell einige Tausend Euro kostet. Für eine Firma die einige Tausend bis zehntausen GEräte pro Tag herstellt Lachhaft. Für den Kleinbetrieb der vielleicht nur eine Nische abdeckt und neben anderen Produkten halt nur 500 USB GEräte/Jahr produziert oft genug ein Grund dieses Produkt nicht auf den Markt zu bringen. Als reiner Hobbyist ist das noch halbwegs egal, da kann man ja beliebige Kombinationen wählen, sollten halt nur nicht dieselben Sein wie gerade aktuell am rechner angeschlossene andere HArdware - aber da hat man genug möglichkeiten. Nur weiterverbreiten ist dann schon kritisch. Dies ist also ein Problem das NUR die Kleinen Betrifft und von der MC Lösung profitieren auch nur die kleinen und kleinsten. Jeder mit Ausreichend durchsatz ist ausgeschlossen. Also genau die Gruppe die bei anderen Unternehmen keine Beachtung finden weil ja keine Stückzahlen rüberkommen. (Ich meine die Kostenlose PID ist nur für HErsteller die weniger als 2000? oder waren es doch mehr? Geräte pro Jahr auf den Markt bringen) Das zeigt halt genau das was ich selbst auch immer wieder bemerke: NAtürlich ist Microchip ein Umsatzorientiertes Unternehmen das Gewinn erwirtschaften soll/muss. Trotzdem wird sich deutlich mehr auch um kleine Kunden gekümmert. Siehe auch: Michael Skropski schrieb: > - Der Support, selbst bei so "Nutzlosen" Kunden wie mir, der eine > Jahresabnahme von 10-15 PICs hat, ist sehr gut. Mir wurde sogar > Kostenfrei ein PICKIT3 zugesendet, nur weil ich meinte, ich will 3.3V > PICs programmieren, was mit dem Brenner8 von Sprut nicht geht. Solches hört man immer wieder das bei vernüftigen Anfragen und wenn jemand dann Glaubhaft macht das er Bedarf hat durchaus auch mal in dieser Richtung was überkommt. ICh für meinen TEil habe zum Beispiel für die Einrichtung eines Studentenlabors an der FH wo den Studis MAterial kostenlos zur freien Verfügung stehen soll(bzw. jetzt ja steht) von MC auf einfache Anfrage wie selbstverständlich eine größere Menge Bausteine bekommen. Atmel wollte gar nicht mit mir reden... Oder Schulungen die kostenlos besucht werden können (habe ich auch gemacht) Sicher: da steckt auch einiges an Eigennutz dahinter denn aus dem Kreis vieler kleiner und kleinster Kunden erwächst auch immer wal wieder ein großer Kunde der dann richtig Umsatz bringt. Aber das ist ja in dieser Handlungsweise einfach eine WIN-WIN Situation. Ganz im GEgensatz zu anderen Firmen wo man erst dann zählt wenn man 100K+ Bausteine pro Monat abnimmt. NAtürlich gibt es neben MC auch andere Hersteller die sich auf der einen oder anderen Weise kooperativ verhalten. Ein anderes Beispiel ist da TI mit ihrer recht großzügigen Sample Politik. Wo auch Dinge bekommt wenn man sich ehrlich als Bastler Outet. Manchmal selbst Dinge die nicht Automatisch als Sample geordert werden können und recht teuer sind... (gibt noch weitere) Aber von SEiten Atmel war es immer nur sehr zäh. Selbst bei echten Bedarf, beispielsweise wo ich für eine kommerzielle Entwicklung mit USB eingestiegen bin und einfach nur IRGENDWIE ein paar AT90USB haben wollte, gerne auch gegen Bezahlung, haben die mich nur zurück an den Distri verwiesen der mit vorher schon Mitgeteilt hat (Auf Anfrage nach KAUF!) das ich wenn überhaupt ja nur ganze VE kaufen könnte und Samples dieser Bauteine im Moment nicht verfügbar sind. Schon gar nicht kurzfristig. (Und das war lange zeit vor der Bankenkrise). Die Anfrage nach BEzugsquellen bei Microchip endete dann damit das ich eine Liste von Bezugquellen bekam UND die Mitteilung das aber bereits die Zusendung von je 5 pcs. diverser Typen an mich veranlasst wurde. (gesamt 20 Stück!) Naja, welcher µC nun in der Entwicklung zum Einsatz kam dürfte Klar sein. NAch meinen letzten Infos werden zwar nur ca. 250 Geräte/Monat von dieser Entwicklung gebaut. Aber das schon ein paar JAhre lang und wohl auch nochjt ein paar Jahre... ISt halt etwas Kleinvieh, aber deutlich mehr als der Vorgang gekostet hat... > Über die Controller von TI wurde bisher kaum was gesagt. > Obwohl ich mir sicher bald mal das LaunchPad besorgen werde. > http://processors.wiki.ti.com/index.php/MSP430_LaunchPad_(MSP-EXP430G2)#Meet_the_LaunchPad_.28MSP-EXP430G2.29 > Das Ding kostet selbst mit dem Touch-Modul fast nix, und wenn man sich > mal durchließt, was die MSP430 alles so an Peripherie haben, stehen die > den µCs von MC und ATMEL in Nichts nach. > Außerdem sind die MSPs bekannt für ihre geringe Power Consumption. Was > wohl deren großer Vorteil ist. > Zu den Controllern von Freescale und Infinion wurde hier noch gar nicht > geurteilt, oder habe ich was überlesen? > JA, die Controller von TI und auch anderen Herstellern sind im Hobbybereich halt einfach nicht so verbreitet, was aber nichts über die tatsächliche Eignung oder deren VErbreitung in der Industrie aussagt. Ich hatte ja schon mal Renesas als Beispiel genannt, wo viele Bastler nicht einmal mit dem Namen etwas anfangen können, der Hersteller beim Verkauf aber noch vor Atmel und MC steht! Zum Thema Leistungsaufnahme: Ja, das gibt es einige gute Stromsparer unter den MSP. Aber auch MC hat da gut nachgelegt. Einige Typen der XLP Serie sind da auch ganz vorne mit dabei. > So, zu letzt möchte ich noch ein Wort über die IDE verlieren. > ... Zur IDE und den Tools unter Linux kann ich leider nicht viel Sagen... Wie gesagt habe ich meine Beschäftigung mit Linux fast ganz eingestellt. Etwas im EbeddedBereich und ein paar Dinge im SErverbereich mache ich noch. Aber für die Heimarbeit fahre ICH mit Windows trotz aller Unkenrufe einfach besser. Mit Linux hatte ich einfach zu viele Probleme mit Inkompatiblitäten sowohl von HArd- wie auch von Softwareseite. Das ich teilweise darauf angewisen bin sehr Alte Software und auch HArdware immer mal wieder zu verwenden macht die Sache nicht besser. GEnauso wie der mit Einsteckkarten vollgestopfte REchner. (Messwerterfassung, Firewire, SCSI, IEEE488, Zusätzliche Com und LPT eine Videokarte für den Anschluss des NetworkAnalyzers) Daher müssen hier andere Das WOrt ergreifen. > Was ARMs angeht, so ist das für mich eine andere Klasse von µC. Ein > wenig so wie LKWs und Familienkutschen (wollte jetzt auch mal ein > hinkendes Auto-Gleichnis unterbringen ;)). Ja, wenn du jetzt ARM mit AVR ergleichst oder es bei den PIC auf die 8Bitter einschränkst stimmt das schon. Wobei auch ARM nicht gleich ARM ist. Da sind im Moment die ARM7, CORTEX M0/M3/M4 und die ARM9 gängig. Wobei die Cortex sehr vereinfacht gesagt nur eine WEiterentwicklung der ARM7 sind, der Vergleich aber zwischen ARM7 und ARM9 ist dann in etwa so wie der Vergleich zwischen aufgemotzem GOLF GTI und einem Formel 1 Rennwagen. Wenn man PIC aber allgemein annimt dann darf man nicht vergessen das es ja auch noch die PIC32 gibt die Leistungsmäßig im Bereich der ARM7/CortexM3 liegen. Die haben nur anstelle einer ARM Achitektur einen MIPS kern, also die ZWeite bekannte Architektur (und keine MC Einzelentwicklung) . Das einzige was mich dazu noch > interessieren könnte ist, wie hoch ist/vermutet Ihr die Zuverlässigkeit > von ATMEL bezüglich ihrer ARM-based Controller? Kann da nichts genaues zu sagen... Würde das genauso einstufen wie bei den AVR da ja auch hier dasselbe gilt. Keine eigenen Fabs mehr, die Herstellung wird nur noch als Dienstleistung eingekauft. ICh selbst verwende aber aktuell keine Atmel ARM. In Benutzung sind CortexM3 von ST/TI und NXP. ICh bin der Meinung das die die interessantere Peripherie haben und da mehr Leistung fürs GEld überkommt. (Und meine Erfahrung mit Atmel und der Lieferzuverlässigkeit tat dann ihr übriges) Gruß carsten
An Atmel stört mich momentan am meisten der Hersteller... :-} Das alter AVR-Studio war so naja, das neue auf Basis von Visual Studio ist meiner Meinung nach ein totaler Griff ins Klo. Da hätte man besser z.B. mal bei Tasking nachgeguckt, was die mit Eclipse alles auf die Beine gestellt haben. Es gibt dann zwar eher eine bescheidene Auswahl an Mikroprozessoren, dafür sind die aber auch von hervorragender Qualität. Damit meine ich, dass z.B. etliche Microchip-Bausteine (nicht nur die PIC) teilweise über vier oder fünf Siliziumrevisionen kaputt sind. Das ist einfach schade, zumal es sich oft um furchtbar ungünstige Fehler handelt ('spurious', 'unreliable', 'in 1 to 3 percent of the devices', ...). Prominentes Beispiel ist der ENC28J60... der ist höchst interessant, weil er dem Mikroprozessor die aufwendige CRC-Rechnerei abnimmt. Theoretisch, denn praktisch ist die CRC-Einheit kaputt. Dazu kommt bei den kleinen PIC(10, 12, 16) teilweise noch das steinzeitliche Design. Das kann man denen natürlich nicht vorwerfen, immerhin gibt es die auch schon ewig. Richtig Spaß macht erst die 18er Serie, nur die gibts unter 18 Pin nicht. Geerbt haben aber auch die den schrägen Befehlssatz, bei Arithmetik muss alles durch das W-Register gequetscht werden. Für mich als Hobbyisten sind die PIC damit zwar wirklich interessant, weil es so viele Möglichkeiten gibt. Aber praktisch greif ich dann doch lieber wieder zu AVR und MSP, wenn ich allein schon wieder in ein Erratum von Microchip hineinschaue :-/
Ich weiß nicht was ihr immer mit dem AVR-Studio habt. Es gibt doch avra und einige Programme zum hochladen, z.Bsp. avrdude. Das ist ein wichtiger Punkt, ich will nicht irgendwelche Binärsoftware vom Hersteller auf meinem Rechner installieren müssen.
Hmm... meine Erfahrungen. Ich verwende im Hobbybereich seit ca 7 Jahren PICs und seit einem Jahr ATMegas. Die PICs habe ihre Einschränkungen (zB. Pull-up nur auf Port B, geringer Strom auf allen Ports ausser B u.C,) und sind, wenn ich das richtig sehe bei 20 MHz 4x langsamer als ATMegas. Dafür haben sie einen sehr schnellen AD-Wandler von dem man auf dem AVR nur träumen kann. Im Vergleich zu AVR-Studio ist der MPLAB IDE Editor ziemlich buggy und die Toolchain ist deutlich langsamer. Die Hardware: Auch hier erlebt man so seine Späßchen, ich hatte vor Jahren mal die Erfahrung gemacht, daß die AD-Kanäle nicht sauber getrennt sind. Dann funktionierte in der Grund-Config ein PIC als I2C-Slave nicht, der zog sofort den Bus auf low. Hardware-Bug? Keine Ahnung. Hab's nach einem Wochenende Fehlersuche mit nem AVR realisiert, ging auf Anhieb. Dagegen halte ich die ANs und sonstige Doku von Microchip für erheblich besser, innovativer und mehr Anregungen bietend. Meine Affinität zu den beiden: ATMega 51% PIC18 49% Your milage may vary.
Jörg Wunsch schrieb: > Jörg S. schrieb: >> Es ging ja nicht um anders, sondern um weniger. > Klar, du hast dir ja auch den zweitkleinsten AVR (damals) ausgesucht > (oder aussuchen müssen). Es ist irgendwie logisch, dass man für > einen kleinen Preis oder eine kleine Bauform Abstriche an der > Funktionalität machen muss. Ja, aber beim MSP430 musste ich das in Grundlegenden Sachen nicht. Da kann der kleinste MSP430 z.B. in sachen Pin-Interrupts exakt das gleich wie der Größte. > Dein Beispiel ist dafür ein Typisches, warum man > bei der Wahl einer Plattform am besten bei dem bleibt, was man schon > kennt: man kommt damit am schnellsten zurecht. Auch beim AVR bin ich schnell zurecht gekommen. So unterschiedlich sind die üblichen Controller in der Programmierung nicht. Diese Aussage trifft vielleicht eher auf den PSoC zu.
@ Jörg S. (joerg-s) >>>Das war mit dem ATTiny wirklich ein Krampf, da hatte man ständig im >>>Hinterkopf wie viel einfacher jetzt ein MSP gewesen wäre. >> Was denn? >Siehe: Beitrag "Re: Wieso Atmel?" >Als jahrelanger MSP430 Programmierer hab ich letztens ein ATTiny44 >programmieren müssen. War regelrecht geschockt wie viel weniger die >Dinger können Wirklich? > (Keine Schmitt-Trigger Eingänge, Falsch. Fast ALLE Pins haben Schmitt-Trigger. ISt leider nicht so explizit beschrieben im Datenblatt. > keine wahlweisen Timer Port-Pins, ??? Timer gibt es sehr wohl, wenn gleich fest an Pins gebunden. > Keine Interrupt Flags für einzelne Pins, Doch, Pin Change Interrupt, wenn gleich das die etwas älteren noch nicht haben. > keine Auswahl auf welche Flanke man einen Interrupt haben will, Aber sicher, wenn gleich nur für die INT0/1 Pins und nicht für die Masse der Pin Change Interrupts. >nur 1,1V Ref. Spg, Kein Probblem, eine Spannung kann man problemlos runterteilen, verstärken ist aufwändiger. > kein JTAG,...) Brauchst du das? Haben alle größeren AVRs, bei den kleinen reicht ISP. >Ich vermute mal das die größerer Serien mehr können, aber im Vergleich >zum MSP schon echt hart mit was sich die AVRler rumärgern müssen ;) Du hast Luxusprobleme. Nein, nicht mal das, du bist einfach zu faul zum Datenblattlesen. >jedenfalls auch nicht wirklich verstehen warum gerade Anfänger und >Bastler auf die Dinger abfahren... "Wer sich selbst erhöht soll erniedrigt werden." So, hier mal mein Senf. Das man am Ende mit jedem aktuellen Controller die meisten Aufgaben gut bis sehr gut lösen kann, wenn man weiß was man tut, wurde ja nun schon mehrfach gesagt. Macken haben alle. PIC-Assembler, oh Graus. Beim PIC bin ich mal über den UART gestolpert, da deaktiviert sich der Receiver wenn er einen Data Overflow hat. So ein Mist. Beim MSP430 war ich leicht erschüttert, wie langsam der beim IO-Wackeln ist. Drei Dutzend verschiedene Adressierungsarten, aber alle brauchen ihre Zeit, so 4-5 Takte! Da ist der AVR deutlich besser. Über das unsägliche durch 4 Teilen des Oszillatortakts der kleinen PICs reden wir mal nicht weiter. OK, ein Manko der AVRs ist das verfusen, vor allem für Anfänger nervig, für Fortgeschrittene und Profis kein Thema. Der MSP430 hat leichte Vorteile bei den Sleep Modes, da kann er das Hauptprogramm ständig ruhen lassen und nur die Interrupts laufen, wenn man es will. Ist aber nicht kriegsentscheidend. MFG Falk
Der AVR hat sich dadurch sehr weit verbreitet, weil er beim Erscheinen 1997 schon per ISP programmierbar war. Da waren viele andere noch OTP oder mit Fenster und benötigten extra Programmier- und Löschgeräte. Lustig sahen sie ja aus, die 8-Pinner mit Fenster. Es hat lange gedauert, ehe PIC nachgeholt hat und man nicht mehr einen Mülleimer für die verproggten OTP-PICs brauchte. Leistungsmäßig mit den AVRs sind die PIC18 vergleichbar. Da wurden dann endlich auch Interruptvektoren, Pointer auf Flash und echter Stack verfügbar. Das Bankumschalten für IO-Zugriffe ist aber wohl immer noch notwendig. Ein großer Nachteil der AVRs sind die fehlenden Interruptprioritäten, da muß man sich beim Programmieren oft Knoten in die Gedanken machen. Die XMega haben sie zwar, sind aber völlig inkompatibel (Pinbelegung, Spannungen usw.). Die AVR-Preise sind extrem stark angestiegen, den ATmega8 gabs schonmal bei CSD für 0,80€. Ich hoffe mal, das geht bald wieder zurück. Mit CAN siehts mager aus. Wegen der Verfügbarkeit habe ich für neue Projekte noch den uralten AT90CAN128 vorgesehen. Peter
Bitte das jetzt nicht als eine übliche ist "FH besser als Uni?" Meckerei verstehen. > Aber einer meiner Profs. sagte mir, dass AVRs nur Spielzeug ist Manchmal hab ich das Gefühl, dass jedes Kaff sich jetzt eine Hochschule als Konjunkturmotor hinklotzt. Da wo früher das Gewerbegebiet mit Aldi gebaut worden wäre steht jetzt eine neue HS. Ob da dann immer das kompetenteste Personal ausgesucht wird, weiß ich nicht. Natürlich kann das mitten in Berlin anders sein ;-). Ich persönlich finde, dass man den Controller verwenden sollte, der am besten für die Aufgabe geeignet ist. Ein ARM mit DMA Engine und allem Schnick Schnack ist zwar schon cool, aber auch oft oversized.
moep schrieb: > Ich persönlich finde, dass man den Controller verwenden sollte, der am > besten für die Aufgabe geeignet ist. Ein ARM mit DMA Engine und allem > Schnick Schnack ist zwar schon cool, aber auch oft oversized. Klar, Du hast natürlich recht. Nur benötigt man dann säckeweise Entwicklungssysteme samt Software, Programmer etc.
> Nur benötigt man dann säckeweise Entwicklungssysteme samt Software, > Programmer etc. Ja, das stimmt. Ich wollte damit nur ausdrücken, dass es meiner Meinung nach keinen Sinn macht sich einen Controller mit tausenden komplizierten Möglichkeiten auszusuchen, wenn man nur z.B. eine kleine Zeitschaltuhr bauen will. Nur weil jemand der Meinung ist, das alles andere nur Spielzeug sei.
Als ich vom 8051er (habe früher die 51 am Atari ST/TT programmiert) wegen Nichtfunktion des Juniorprommers am Linux-PC auf etwas anderes aumsteigen wollte, habe ich beim PIC mir keine gescheite Toolchain zusammenkompilieren können während das mit AVRA und UISP beim AVR problemlos möglich war. Die ganzen zusätzlichen Tools die dabei im Laufe der Jahre entstanden sind (z.B. Codegeneratoren für bestimmte Fälle) möchte ich auch nicht mehr missen. Da ich bei ASM bleiben will (C benutze ich nur auf dem PC) erscheint für mich momentan Freescale S12(X) als sinnvollstes "Upgrade", da ASM auf dem ARM für mich nach einigen Versuchen unter "Muss ich nicht haben" fällt. Beruflich muss ich nichts mehr "entwickeln", ich betreibe das nur als Hobby und versuche da an die Grenzen des Machbaren zu kommen. Und die sind noch lange nicht erreicht auch wenn die Luft manchmal dünn wird. Aktuelles Beispiel ist eine Grafikkarte mit Mega644, 128K externem RAM und einem 74HC374. Mittlerweile schaffe ich Z-Buffering in Echtzeit und gleichzeitige Ausgabe auf VGA/TV sowie Bedienung der seriellen Schnittstelle mit max. 250Kb/s. Jörg
MCUA schrieb: >>- Es gibt für ansich alles, was man braucht, interne Peripherie. > Aber kein ExtBusInterface! Das nennt sich dort PMP - Parallel Master Port. fchk
> Leistungsmäßig mit den AVRs sind die PIC18 vergleichbar. > Ein großer Nachteil der AVRs sind die fehlenden Interruptprioritäten Diese Aussagen widersprechen sich. Bei einigen meiner letzten Projekte wurde in einem PIC18 zwei SSI-Slave-Schnittstellen plus weiteren Funktionalitäten, bzw. ein 16-Kanal Datensplitter für RS422-Signale mit 115,2 kBaud Übertragungsgeschwindigkeit realisiert. Ohne die Nutzung von Interruptprioritäten wäre das nicht gegangen. Da ich viele oft sehr zeitkritische Funktionen in Assembler programmiere, fühle ich mich bei Microchip sehr gut aufgehoben.
Simon S. schrieb: > #1 225MB nur für die IDE > #2 Es gibt keine Pakete, so dass ich das ganze auch wieder einfach los > werde wenns ist Was hättest Du denn gerne? .deb .rpm .tgz Das ist ein Linux-Problem, weil es eben so viele Distributionen gibt und Hersteller nicht für jede einzelne Pakete bauen wollen. Bei Windows gibts nen Uninstaller, beim Mac ziehe ich das Zeugs einfach in den Mülleimer, und das wars. > #3 Es gibt kein Repository damit ich automatisch Updates bekomme > #4 Es ist langsam Java halt. > #5 Vieles ist irgendwie Verschoben, halb abgeschnitten und so. Das ist > jedenfalls kein GTK oder QT Java halt. Mein Büro ist noch javafreie Zone. > #8 Und eines der größten Übel: Auf der Homepage von dem X-Teil bekommt > man nicht mal einen anständigen Compiler für 16F ohne dafür zu > blechen... Gibts überhaupt einen? Nimm doch einfach die 18F. Die sind compilerfreundlicher. Oder kleine 24Fs, die sind auch nicht viel teurer. Bzw: Der neue XC8 sollte auch die 16F können. Da nimmst DU Dir einfach die kostelose Lite-Version und gut ists. > #3 Das das ganze mit Makefiles gesteuert wird. Somit lassen sich > bestehende Projekte auch sehr leicht mit anderen Editoren/IDEs > verheiraten Na also, dann kannst Du doch diesen Weg gehen. fchk
Frank K. schrieb: > Simon S. schrieb: > >> #1 225MB nur für die IDE >> #2 Es gibt keine Pakete, so dass ich das ganze auch wieder einfach los >> werde wenns ist > Was hättest Du denn gerne? .deb .rpm .tgz Das ist ein Linux-Problem, > weil es eben so viele Distributionen gibt und Hersteller nicht für jede > einzelne Pakete bauen wollen. Bei Windows gibts nen Uninstaller, beim > Mac ziehe ich das Zeugs einfach in den Mülleimer, und das wars. Ich währ ja schon mit .deb und .rpm zufrieden, da hätte man das meiste schon abgedeckt. Nebenbei bemerkt: Wenn das alles anständig offen währe würde sich auch schnell für jede Paketart jemand finden der das regelmäßig paketiert. >> #3 Es gibt kein Repository damit ich automatisch Updates bekomme >> #4 Es ist langsam > Java halt. > >> #5 Vieles ist irgendwie Verschoben, halb abgeschnitten und so. Das ist >> jedenfalls kein GTK oder QT > Java halt. Mein Büro ist noch javafreie Zone. Besser Java als garnichts. Aber noch besser was anständiges... (Ist ja nicht so, als ob z.B. GTK nicth auch auf Windows funktionieren würde) >> #8 Und eines der größten Übel: Auf der Homepage von dem X-Teil bekommt >> man nicht mal einen anständigen Compiler für 16F ohne dafür zu >> blechen... Gibts überhaupt einen? > > Nimm doch einfach die 18F. Die sind compilerfreundlicher. Oder kleine > 24Fs, die sind auch nicht viel teurer. Bzw: Der neue XC8 sollte auch die > 16F können. Da nimmst DU Dir einfach die kostelose Lite-Version und gut > ists. Ich kann nicht einfach 18F nehmen, weil 16F887 für die Ausbildung von der IHK festgelegt wurde. Abgesehen davon sollte man nicht aufgrund der Compilerunterstützung zwischen µC aussuchen müssen, sonder aufgrund der Features. >> #3 Das das ganze mit Makefiles gesteuert wird. Somit lassen sich >> bestehende Projekte auch sehr leicht mit anderen Editoren/IDEs >> verheiraten > > Na also, dann kannst Du doch diesen Weg gehen. Naja, für jedes neue Projekt wieder maplapx starten und das erst anlegen damit ich es dann mit einem anderen Editor nutzen kann ist auch nur ne Notlösung... Naja, wie gesagt, da wos für die Schule gebraucth wird nehm ichs gern her. Bei Dingen wo kein PIC gefordert ist und auch privat bleibe ich bei AVRs. AVRStudio hab ich im übrigen nie benutzt, weil nicht für Linux verfügbar. Andererseits frage ich mich ob überhaupt Bedarf da ist. Seine Entwicklungsumgebung von Hand zusammenstöpseln tuts auch. (Ja, man muss wissen wo was im Makefile ist. Ja, man muss wissen wie man Geany sagt was es dem Makefile sagen soll. Und ja, man muss wissen was man alles braucht (Compiler, Editor, Programmer) und wie das zusammenspielt. Aber dieser Aufwand ist mir die "absolute Kontrolle" wert.)
Frank F. schrieb: >> Leistungsmäßig mit den AVRs sind die PIC18 vergleichbar. > >> Ein großer Nachteil der AVRs sind die fehlenden Interruptprioritäten > > Diese Aussagen widersprechen sich. Nein, denn "Leistung" bezieht sich ja nicht nur auf das Interrupt- verhalten, wobei natürlich der Gegenbeweis noch anzutreten wäre, dass sich deine Applikation auf einem AVR mit nur zwei Interrupt- prioritäten nicht doch auch implementieren ließe. Durch den Verzicht auf eine akkumulatorbasierte Architektur sind viele ISRs beim AVR (gerade bei reiner Assemblerprogrammierung) sehr kurz. Allerdings habe ich mit SSI noch nichts zu tun gehabt, insofern ist mir der tatsächliche Aufwand dafür (bspw. inwiefern man dafür die existierenden Hardwarefeatures wie timer capture zu Hilfe nehmen kann) nicht klar. Letztlich ging's aber bei Peters Aussage um eine grobe Einordnung, die beim Vergleich mit PIC dahingehend nicht so ganz einfach ist, dass Microchip ja letztlich jeden Controllertyp irgendwie "PIC" nennt, egal ob damit nun das rattenalte Design aus den 1970er Jahren oder ein aktueller MIPS-basierter gemeint ist.
Frank F. schrieb: > Bei einigen meiner letzten Projekte wurde in einem PIC18 zwei > SSI-Slave-Schnittstellen Wenn SSI SPI bedeutet, dann ist der AVR schlichtweg nicht geeignet. Das SPI des AVR ist als Slave völlig unbrauchbar, da ungepuffert. Im Worst-Case müßte der AVR innerhalb von 4 CPU-Zyklen in den Interrupt springen, die nötigen Register pushen und das nächste Byte in das Senderegister stellen. Frank F. schrieb: > bzw. ein > 16-Kanal Datensplitter für RS422-Signale mit 115,2 kBaud Das sind pro Byte 1280 CPU-Zyklen bei 14,7456MHz. Das ist reichlich für einen Interrupthandler, da kommt man spielend ohne Prioritäten aus. Kritisch wird es bei Interrupts schneller als etwa 100 Zyklen. Peter
Jörg Wunsch schrieb: > eine grobe Einordnung, > die beim Vergleich mit PIC dahingehend nicht so ganz einfach ist, > dass Microchip ja letztlich jeden Controllertyp irgendwie "PIC" > nennt, egal ob damit nun das rattenalte Design aus den 1970er Jahren > oder ein aktueller MIPS-basierter gemeint ist. Die Bandbreite der PIC-Familien füllt genau diesen Bereich in teils sehr feinen Abstufungen aus. Ob man darin nun einen Nachteil sehen mag, liegt im Auge des Betrachters. Für mich sieht es so aus, dass Microchip auf diese Weise die Auswahl eines Controllers, der in Leistung und Preis an die Aufgabe angepasst ist, sehr effizient erleichtert. Zum Thema alte Technologien: Die Programmiersprache C ist aus den 70ern, wird aber seitdem erweitert und angepasst. Die uC-Palette von Microchip entwickelt sich auf ähnliche Weise, nur halt innerhalb einer einzigen Firma, die ihre Hardware noch selbst fertigt. Auch darin sehe ich mehr Vorteile als Nachteile. Gruß, Edson PS: Der MIPS-Core ist nichts neues und er stellt keine Basis für 8- und 16-Bit PICs dar, sondern ausschließlich PIC32. Aktuell werden in jeder Leistungsklasse neue Derivate angeboten, auch in der 16er-Reihe.
Meister Eder schrieb: > Ob man darin nun einen Nachteil sehen mag, liegt > im Auge des Betrachters. Es ging ja dabei gar nicht um Vor- oder Nachteile, sondern nur um eine grobe Einordnung der klassischen AVRs im Vergleich zu den vielen PIC-Familien. Bei Atmel bekommt halt jede Controllerfamilie einen neuen Namen (AT89, AVR, Xmega, AVR32, SAMx für die diversen ARMs), bei Microchip heißen sie alle erstmal "PIC", und man muss dann das "Kleingedruckte" studieren um zu erkennen, welche Leistungsklasse es nun gerade ist. Jede der Marketingtruppen dieser Firmen hat sich dabei was gedacht, ohne dass man deshalb das eine oder das andere Schema per se als unbrauchbar abtun könnte.
Peter Dannegger schrieb: > Das > SPI des AVR ist als Slave völlig unbrauchbar, da ungepuffert. Das kann man auch nicht puffern. SPI mit einem Controller als Slave ist prinzipiell ein eher bescheidener Kompromiss. SPI ist als Protokoll an einem Hardware-Schieberegister orientiert, welches in der Lage ist, innerhalb eines Systemtaktes nach dem per SPI eingelaufenen Kommandobyte bereits eine Antwort bereitzustellen, die man mit dem nächsten SPI-Takt dann auslesen kann. Mit einem Controller als Slave bietet sich besser I²C an, denn da kann der Slave den Master (für eine gewisse Zeit) ausbremsen, um sich die Antwort auf die Anfrage zurecht zu legen.
Peter Dannegger schrieb: > Das sind pro Byte 1280 CPU-Zyklen bei 14,7456MHz. Vorsicht: es waren 16 Kanäle mit Auswertung der Daten.
Frank F. schrieb: > Vorsicht: es waren 16 Kanäle mit Auswertung der Daten. Die AVRs haben nur bis zu 4 UARTs. 16 mal gleichzeitg Empfangen und Senden geht also nicht. Ich hatte vermutet, daß über einen Multiplexer die 16 Kanäle nacheinander bedient werden. Peter
>>>- Es gibt für ansich alles, was man braucht, interne Peripherie. >> Aber kein ExtBusInterface! >Das nennt sich dort PMP - Parallel Master Port. Von Wegen. Der PMP ersetzt kein ExtBusInterface, da man mit PMP nicht -wie mit ExtBusIF- transparent (mittels normalem ASM-Befehl der Mem adressiert) auf den Speicher zugreifen kann (denn es sind da mehrere Befehle an den PMP nötig) PICs haben das jahrelang verpennt (geben die sogar selber zu), nur bei den allerneusten 32Bitern ist es wohl geplant.
Jörg Wunsch schrieb: >>Bei Atmel bekommt halt jede Controllerfamilie einen neuen Namen (AT89, >>AVR, Xmega, AVR32, SAMx für die diversen ARMs), bei Microchip heißen >>sie alle erstmal "PIC", und man muss dann das "Kleingedruckte" >>studieren um zu erkennen, welche Leistungsklasse es nun gerade ist. Man muss nur die nächsten beide Ziffern dazunehmen und schon weiß man im Groben Bescheid: PIC10 PIC12 PIC16 PIC18 PIC24 PIC32 dass jede dieser Familien unzählige Derivate hat, hat mich zuerst gestört aber mittlerweile finde ich das super, da ich immer genau den passenden PIC für meine Anwendung bekomme und er seltsamerweise immer lieferbar ist. Die Lieferbarkeit und die Preisstabilität sind für mich ohnehin DAS Hauptkriterium. Und genau in diesem Punkt ist ATMEL leider miserabelst, obwohl ich die AVRs einmal über alles geliebt habe und prinzipiell auch immer noch sehr gut finde.
>Der AVR hat sich dadurch sehr weit verbreitet, weil er beim Erscheinen >1997 schon per ISP programmierbar war. Da waren viele andere noch OTP >oder mit Fenster und benötigten extra Programmier- und Löschgeräte. >Lustig sahen sie ja aus, die 8-Pinner mit Fenster. Stimmt. Aber nicht nur deswegen, auch wegen der viel besseren Programmierbarkeit. >Durch den >Verzicht auf eine akkumulatorbasierte Architektur sind viele ISRs >beim AVR (gerade bei reiner Assemblerprogrammierung) sehr kurz. Quatsch. Bei einer Akku-Architekt. sind prinz. viel weniger Register zu sichern als bei RISC, mit vielen Registern, weshalb die RISC-ISR normalerweise viel länger dauert. >Das kann man auch nicht puffern. SPI mit einem Controller als Slave... Klar kann man SPI puffern. Wenns sein muss, mit beliebig vielen Bits.
Falk Brunner schrieb: > @ Jörg S. (joerg-s) > ... du bist einfach zu faul zum Datenblattlesen. Du anscheined zu faul um den verlinkten Beitrag weiter zu lesen :) Sonst hättest du gesehen das diese Fragen da alle erörtert wurden...
MCUA schrieb > Quatsch. > Bei einer Akku-Architekt. sind prinz. viel weniger Register zu sichern > als bei RISC, mit vielen Registern, weshalb die RISC-ISR normalerweise > viel länger dauert. Nicht prinzipiell. Man kann auch einen Teil der Register nur für die ISR verwenden, dann muss gar nichts gesichert werden. Was man meistens sichern muss, ist das Statusregister. Auch das kann man in ein unbenutztes Register sichern und braucht dann insgesamt nur zwei Takte zusätzlich in der ISR. Jörg
Also, diese ganze Diskussion führt zu nichts. Einer kennt sich mit dem PIC sehr gut aus, kann dafür mit dem AVR nicht umgehen und umgekehrt. Ich habe alle möglichen Plattformen schon programmiert, und die Entscheidung, warum man jetzt die eine oder andere Plattform verwendet hat, hing etweder von den Vorlieben der Entwickler oder von notwendigen Features ab. Gelernt an der FH habe ich auf dem 8085 und dem 8051. In meiner ersten Firma wurden irgendein NEC und ein Motorola DSP56000 verwendet. Der DSP hatte eine tierische Rechenleistung, war aber nicht in der Lage, ein Display oder einen Thermodrucker anzusteuern. Bei der nächsten Firma wurden parallel der 8051 (80537), Motorola 68k (68000, 68008, 68331, 68332, 68302, 68EN302, 68360), MSP430, PIC, AVR und PowerPC verwendet. Jeder einzelne hatte seine Berechtigung: Der 80537 war günstiger als ein 68k, und für die Aufgabe, Messdaten über ne SPI einzusammeln und über den UART auszugeben wäre ein 68k ziemlich oversized gewesen. Die Motorola 68k konnten dafür auch große Applikationen (hier: ein Patienten-Monitor) ausführen, da sie über einen 24-Bit Adressbus verfügten. Der MSP430 (damals der MSP430C325, ein OTP) war zu der Zeit der stromsparendste Prozessor und verfügte über einen hervorragenden 14Bit-AD-Wandler. Also wurde der als Ladecontroller für die Akkupacks verwendet, denn seine Ruhestromaufnahme war geringer als die Selbstentladung der NiCd-Zellen. Hinterher wurde er auch im Analog-Frontend verbaut, da ein vergleichbarer ADC mehr kostete als der MSP430. Der AVR wurde eingeführt, weil er neu war, im Gegensatz zum MSP430 berreits mit Flash ausgestattet war und man probieren wollte, ob er in zukünftigen Projekten eine Rolle spielen könnte. Aus dem gleichen Grund hat man den PIC ausgetestet. Den PowerPC hat man eingeführt, da die 68000er immer teurer wurden und man auch mehr Rechenleistung benötigte. Heute setzen sie den Coldfire ein, da man den Code relativ einfach vom 68k auf den Coldfire portieren konnte, da sich nur der Core geändert hat und die Peripherie gleich blieb. Bei meiner jetzigen Firma setzen wir die C166-Familie (C16x, XC16x, XE16x) und den PIC ein. Den C166 wegen der Capture Compare Unit, den PIC überall da, wo ein C166 zu teuer wäre. Es gibt jetzt natürlich auch Prozessoren von anderen Herstellern mit nem ARM-Core und entsprechenden Capture Compare Einheiten, aber das würde bedeuten, dass man alle Programmteile, die auf Peripherie zugreifen, komplett neu machen müsste. Ich habe jeden aus dieser Liste programmiert (und auch problemlos ans Laufen bekommen), und jeder hat seine spezifischen Stärken und Schwächen. Auch ich habe meine Favoriten, so sind der MSP430 und der C8051 nahezu unschlagbar, wenn es um analoge Komponenten wie hochauflösenede AD-Wandler geht. Mehr als 12 Bit kriegt man weder im PIC noch im AVR. Die vier Registerbänke im 8051 sind nett für die Abarbeitung von ISRs (Status-Register retten, Bank umschalten, fertig). Für mein nächstes Projekt suche ich einen µC im möglichst kleinen Gehäuse mit mindestens einem 12 Bit AD-Wandler. Bei der Suche sind bisher der Freescale S08, der STM8, der MSP430 und der C8051 herausgekommen. Es wird wohl entweder der STM8 (ein Eval-Board, das niemand braucht, fliegt bei uns in der Firma rum), der MSP430 (das Launchpad ist so schön billig) oder der C8051 (da hab ich schon die Entwicklungsumgebung fertig installiert, fehlt nur noch die Hardware). Außerdem habe ich gerade mir ein XMOS-Entwicklungssystem gekauft, weil die Prozessoren mal wirklich etwas völlig anderes sind als alles, was sonst so auf dem Markt ist und ich gerne neue Sachen ausprobiere.
Fabian Hoemcke schrieb: > wie der Titel erahnen lässt, geht es in diesem Thread hier um > Präferenzen für bestimmte Mikrocontrollerfamilien. Jedoch soll das hier > kein Bashing-Thread, wie viele andere, werden. Dann schlage ich vor eine Kriterienliste mit Punktesystem einzuführen mit der die einzelnen Prozessoren jeder Familie verglichen werden. Technik, Verfügbarkeit, Termintreue, Errata handling, Support etc. Sachlichkeit ist langweilig und arbeitsaufwändig, auch vermute ich das am Ende Unterschiede im Promillebereich herauskommen. Aber das wäre mal eine sinnvolle Herangehensweise statt dieser ewige sinnlose Schwanzvergleich.
MCUA schrieb: >>>>- Es gibt für ansich alles, was man braucht, interne Peripherie. >>> Aber kein ExtBusInterface! >>Das nennt sich dort PMP - Parallel Master Port. > Von Wegen. > Der PMP ersetzt kein ExtBusInterface, da man mit PMP nicht -wie mit > ExtBusIF- transparent (mittels normalem ASM-Befehl der Mem adressiert) > auf den Speicher zugreifen kann (denn es sind da mehrere Befehle an den > PMP nötig) Das ist für mich aber kein externes Bus Interface sondern eher ein externes Speicherinterface (Für Programmspeicher). Denn NUR wenn ich Programm aus einem externen Speicher ausführen will brauche ich zwingend den Zugriff mittels eines (normalen) Adressierungsbefehls. Für ALLE ANDEREN Anwendungen ist es völlig Egal ob ich nun einen, zwei oder 10 Befehle brauche. Ist höchstens noch eine Geschwindigkeitsfrage - sonst nichts! (Beim Programmieren liegt der Mehraufwand ja auch nur im schreiben einer Funktion). Bei den 8 & 16 Bit PICs ist es dasher fast völlig Sinnfrei den erhöhten Aufwand zu treiben da es überhaupt nicht zur Architektur passt und sowieso keine Befehle aus externen Speicher ausgeführt werden können (HArvard Architektur). Lediglich bei wenigen Anwendungen KÖNNTE sich ein kleiner Geschwindigkeitsvorteil einstellen wenn die externe Hardware (z.B. Flash AD Wandler) das unterstützt und das Programm dies auch ausnutzt. Aber da wo man das braucht greift man halt zu einem etwas leistungsfähigeren µC und hat dasselbe Ergebniss. Bei den 32Bitter OK, da könnte man so externen Programmspeicher anschließen und man "hätte" das implementieren können. (von Neumann design) Den Bedarf hat Microchip bisher tatsächlich nicht gesehen (und ich kann das nachvollziehen) da das ja wieder die Grenze vom normalen µControllersystem zum Mikroprozessorsystem verwischt. Wie du schreibst wollen sie es evtl. bei einigen 32Bittern jetzt doch einführen. In von mir allein betreuten Projekten hatte ich auch noch nie Bedarf an diesen zusätzlichen Speicher zu nutzen. Einzig Projekte an denen ich Mitgerarbeitet habe waren teilweise so Umfangreich das es nicht in einen Controller alleine gepasst hätte. Aber in diesen Fällen währen die PIC32 sowieso hoffnungslos verloren gewesen und die für zentrale Datenverarbeitung zuständigen Kollegen haben da eh auf ARM9 setzen müssen. (Mein Gebiet war die Sensorik incl. Eigenintelligenz die dann schon fertig aufbereitete Messwerte an die zentrale Mikrocomputereinheit gesendet haben, habe daher nur am Rande etwas vom Kern mitbekommen) Das ist halt die Frage was braucht man und wo kann man Abstriche machen. Wenn ich soetwas zwingend brauche ist im Moment Microchip die Falsche Wahl. Dafür haben andere Controller wo anders Schwachpunkte wo PIC dann wieder die bessere Wahl ist. Wie gesagt, den PERFEKTEN Controller gibt es nicht. Peter Dannegger schrieb: > Der AVR hat sich dadurch sehr weit verbreitet, weil er beim Erscheinen > 1997 schon per ISP programmierbar war. Da waren viele andere noch OTP > oder mit Fenster und benötigten extra Programmier- und Löschgeräte. > Lustig sahen sie ja aus, die 8-Pinner mit Fenster. Nee, das würde ich nicht als den Grund ansehen. 1997 waren auch von Microchip schon einige F (Flash) Typen verfügbar die man Problemlos mittels ICSP programmieren konnte. Ein paar Widerstände und Dioden an der Seriellen Schnittstelle reichten. (Und VIEL Früher gab es ja schon den 16C84 mit EEPROM Programmspeicher dr ebnfalls in Circuit Programmierbar war) Der Grund für die schnelle Verbreitung liegt meiner Ansicht nach darin das beim Erscheinen die AVR deutlich günstiger waren als die PIC und dabei noch einige mehr an Leistung (Geschwindigkeit, Speicher) boten. Das es sehr früh einen freien C Compiler gab tat dann sein übriges. Damals hatte Microchip tatsächlich etwas gepennt und war aus Bastlersicht ins hintertreffen geraten! Seit dem haben die aber mächtig aufgeholt. Falk Brunner schrieb: > Über das unsägliche durch 4 Teilen des Oszillatortakts der kleinen PICs > reden wir mal nicht weiter. Dazu hatte ich ja weiter oben schon etwas geschrieben... Das ist nur ein Argument was immer wieder Reflexhaft vorgebracht wird von Leuten die nur irgendetwas gehörtes NAchplappern ohne sich selbst ein Bild zu machen. Ja - der Befehlstakt ist 1/4 des Oszillatortaktes. Das stimmt schon. Aber dafür laufen die aktuellen 8Bit Pics auch alle intern mit 48 bis zu 64Mhz wenn man es denn will. Das ganze mittels PLL aus einem 4...16Mhz Quarz generiert bzw. aus dem internen Oszillator abgeleitet. Und ob ich nun einen µC habe der mit 16MHz Quarz läuft, sich daraus dann 64MHz macht und dann aufgrund seiner Verarbeitungsstruktur wieder einen 16Mhz Befehlstakt macht - Oder ob ich einen µC habe der mit maximal 16Mhz (ok einige AVR können auch 20Mhz) arbeiten kann, an dem ein 16Mhz Quarz angeschlossen ist und wo ich dann einen Befehlstakt von 16Mhz habe, das ist doch selbst für einen Laien schon bei erster Betrachtung völlig egal. Aber das war es ja nicht nur: Denn die PIC Entwickler haben die /4 Teilung ja nicht aus Spass an der Freud eingeführt sondern damit etwas bezweckt. Jeder einzelne Taktzyklus des PICs besteht aus vier Phasen (Jede Phase ein Osillatortakt) in denen verschiedene Abarbeitungsstände erreicht werden. Dadurch ist der Großteil der Befehle des PICs in einem einzelnen Befehlstaktzyklus abgearbeitet wohingegen sehr viele AVR Befehle deutlich mehr als als einen Takt brauchen (2-3 Takte). Es ist also mitnichten so das ein AVR der mit derselben Oszillatorgeschwindigkeit arbeite wie ein 8Bit PIC vier mal schneller ist. Tatsächlich beträgt der Geschwindigkeitsvorteile (je nach Programm) im Schnitt eher so Faktor 2 (1,5 -3). Da bei den PICs aber die höheren Taktraten verfügbar sind wenn ich die Brauche ist bei Bedarf durch den Einsatz von PICs sogar eine höhere Geschwindigkeit erreichbar. (Wobei das ganze wie gesagt nur ein Akademisches Argument ist. Wenn ich in Regionen komme wo es auf das letzte Quentchen ankommt nehme ich einfach direkt einen größeren µC! - Bei Massenproduzenten sieht es natürlich anders aus, da zählt jeder 1/10 ct. Aber bei den Stückzahlen in denen die meisten Auftragsentwicklungen Später laufen und gar erst bei Hobbyprojekten ist das einfach deutlich günstiger als wenn ich dann kurz vor ende feststelle das die Reserven NICHT reichen) Aber wie gesagt: Das alles ist jetzt nicht so Absolut wie es klingt. Es sind halt alles einzelne Stichpunkte die zwar eine Rolle spielen aber keineswegs die einzig alleingültigen Meinungen sind. Ausser vielleicht bei der Lieferzuverlässigkeit von ATMEL die für den kommerziellen Einsatz ein gewichtiges Argument ist und wo ich hier sehe das ich bei weitem nicht der einzige bin der damit echte Probleme hatte und daraus dann die Konsequenzen gezogen hat. Es ist halt einfach nicht möglich alle Meinungen unter einen Hut zu bekommen und das Muss auch gar nicht sein. Genau deshalb haben wir ja eine Typenvielfalt die ja wohl für den Großteil absolut Wünschenswert ist und nicht einen einzelnen µC hersteller. Und das gewisse Anforderungen einfach gegensätzlich sind sieht man hier ja auch sehr gut. Da beschwert sich ein TEil darüber das es bei PIC nicht alles Open SOurce ist man nur begrenz Eingriffsmöglichkeiten in die Software hat, während andererseits Leute wie ich sagen das sie GENAU DAS nicht wollen. Ich will keine Open Source Geschichte die ständig durch eine nicht genau definierte Anzahl dritter Personen verändert wird wo ich vielleicht selbst noch Hand anlegen muss oder zumindest schauen muss welche VErsion nun für mich in Frage kommt - Für mich sollte es einfach Out of the Box uverlässig funktionieren. Der Chef bezahlt mich fürs entwicklen von Mikrocontrollerfirmware und nicht fürs frickeln an der Entwicklugnsumgebung. Gruß Carsten Wo liegt für den Anwender der Unterschied zwischen einem PIC an einem 16MHz Quarz der Intern
Carsten Sch. schrieb: > Ja - der Befehlstakt ist 1/4 des Oszillatortaktes. Das stimmt schon. Der Vollständigkeit halber: es stimmt für PIC10/12/16/18 Gruß, Edson
Carsten Sch. schrieb: > Dadurch ist der > Großteil der Befehle des PICs in einem einzelnen Befehlstaktzyklus > abgearbeitet wohingegen sehr viele AVR Befehle deutlich mehr als als > einen Takt brauchen (2-3 Takte). Laut Atmel "Most Single Clock Cycle Execution" und damit "1.0 MIPS/MHz".
@GB (Gast) >>Also, diese ganze Diskussion führt zu nichts. >>Einer kennt sich mit dem PIC sehr gut aus, kann dafür mit dem AVR nicht >>umgehen und umgekehrt. >>Ich habe alle möglichen Plattformen schon programmiert Interessant dass Du der Superheld bist und alle anderen disqualifizierst! Jetzt sehe ich es auch so, dass diese Diskussion zu nichts führt...
Carsten Sch. schrieb: > (ok einige AVR können > auch 20Mhz) Aktuelle (Xmega) mit 32 MHz (und du hast mit aktuellen PICs verglichen). Ob man immer unbedingt so schnell will (schneller Takt heißt auch mehr direkter Stromverbrauch, d. h. man muss sich dann mehr Gedanken um Schlaf-Konzepte machen), ist natürlich 'ne andere Frage. Du solltest aber nicht den Fehler, den manch einer macht, indem er beim Stichwort PIC nur an die unsägliche 12-bit-Architektur denkt und diese gegen moderne Controller vergleicht, wiederholen, indem du aktuelle PICs gegen die AVRs von vor 10...12 Jahren hälst. Letztlich ist da ständig eine Weiterentwicklung, und die Präferenzen sind größtenteils kaum durch die zu Grunde liegende Technik begründet (nur in seltenen Fällen), sondern meist woanders. Das sollte der Thread ja nun gezeigt haben (und im Großen und Ganzen ist er ja recht sachlich geblieben, schön). > Ich will keine Open Source Geschichte die ständig durch eine nicht genau > definierte Anzahl dritter Personen verändert wird Ach?! Bei Closed Source hast du eine genau definierte Anzahl, oder es sind nicht dritte Personen? Welchen Unterschied ergibt das genau für dich? Wenn Closed-Source-Software nicht funktioniert, musst du auf den Hersteller hoffen, dass er es repariert. Wenn Open-Source- Software nicht funktioniert, kannst du auf den Hersteller hoffen (dann ist deine Situation erstmal die gleiche), oder aber du kannst es selbst versuchen (wenn es dir wichtig ist) oder jemanden anders damit beauftragen (wenn es dir noch wichtiger ist). Die letzten beiden Möglichkeiten hast du bei closed source einfach nicht, sie können (müssen aber natürlich nicht) dir jedoch zum Vorteil gereichen. Das Getue "bei open source frickelt jeder irgendwie dran herum" ist einfach albern und kommt in aller Regel von Leuten, die das nur vom Hörensagen kennen und als Ausrede benutzen müssen, damit sie sich mental gar nicht erst mit opensource-Software befassen müssen. Keiner zwingt dich natürlich dazu, aber dann lass' die unsinnige Polemik stecken. Opensource hat im 3. Jahrtausend hinreichend bewiesen, dass es trotz aller Anfeindungen ein tragfähiges Konzept ist. (Beispiels- weise wäre es fraglich, ob es dieses Forum ohne Opensource überhaupt gäbe.)
was? schrieb: > Laut Atmel "Most Single Clock Cycle Execution" und damit "1.0 MIPS/MHz". Und abseits von Atmel real wohl zwischen 1,2 und 1,5 Takte pro Befehl als Durchschnitt für typische Applikationen.
Jörg Wunsch schrieb: > Und abseits von Atmel real wohl zwischen 1,2 und 1,5 Takte pro > Befehl als Durchschnitt für typische Applikationen. Dafür haben die AVR auch um den Faktor 1,2 bis 1,5 mehr Instruktionen. Nimmt sich also gar nichts. ;)
@Frau Holle (Gast) 1. Ich bin kein Superheld. 2. Ich qualifiziere hier niemanden ab. Ich habe nur gesagt, dass die Auswahl eines Prozessors von vielen verschiedenen Faktoren abhängt, z.B. von - der Applikation, - dem Preis, - der Peripherie, - dem was man bereits kennt, - dem, was beim Eintritt in eine Firma bereits verwendet wird usw. Ich hätte auch lieber eine einzige Architektur gehabt, die alles erschlägt, dann würde ich mich jetzt mit dieser schlafwandlerisch auskennen. Aus den diversen angeführten Gründen musste ich jede dieser aufgezählten Plattformen programmieren. Ich bin bestimmt kein Meister, aber ich habe noch immer alles zum Laufen bekommen. Viele Leute, die sich besser ausgekannt hätten, wären wesentlich schneller gewesen, aber ich bin nie gefragt worden. Da es aber bisher immer irgendwie doch funktioniert hat, habe ich kein Problem, auch mal wieder etwas neues anzufangen.
>> Quatsch. >> Bei einer Akku-Architekt. sind prinz. viel weniger Register zu sichern >> als bei RISC, mit vielen Registern, weshalb die RISC-ISR normalerweise >> viel länger dauert. >Nicht prinzipiell. Man kann auch einen Teil der Register nur für die ISR >verwenden, dann muss gar nichts gesichert werden. Was man meistens >sichern muss, ist das Statusregister. Klar kann man bei RISC nur einen Teil der Register sichern (was die ISR etwas schneller macht). Aber wozu sind Register da? Um benutzt zu werden. Also kann man mal davon ausgehen dass jedenfalls ein grosser Teil auch für die ISR benutzt wird. Ausserdem, was machst du wenn du 30 (oder mehr) INT-Routinen hast? Benutzt du dann 30x4=120 Register nur für diese INTs? Es ist paradox, ein RISC mit vielen Registern zu benutzten, weil man ja (gerade wegen RISC) auch viele Register benötigt, um dann bei ner ISR das genaue Gegenteil zu machen, und sehr wenige Register benutzen zu wollen. Bei einer Akku-Architekt. ist das Problem prinz. gar nicht da. Wo keine zig Register da sind, muss man sie auch nicht sichern. Aber davon abgesehen, jede ISR brauch -egal wie viel gesichert wird- min mal ca 2x 5..8 Takte (manche brauchen noch viel länger). Also ist diese Zeit schonmal verschwendet, was heisst, man sollte INTs, soweit möglich, von der CPU fernhalten; was geradezu mehrprioris. INTs erfordert. ---------------------- >Das ist für mich aber kein externes Bus Interface sondern eher ein >externes Speicherinterface (Für Programmspeicher). Wenn vorhanden, ExtSpeicherInterface meist für Data. Aber, gibts (bei manchen CPUs) auch zus für Programmspeicher.(wobei da aber die Konkurenz mitlesen kann!) >Denn NUR wenn ich >Programm aus einem externen Speicher ausführen will brauche ich zwingend >den Zugriff mittels eines (normalen) Adressierungsbefehls. Nein, gemeint ist ein 'stinknormaler' ASM-Befehl, der auf Data zugreift, wobei es (wenn richtiges ExtSpeicherInterface vorhanden) egal ist, ob das Data intern uC oder extern liegt. Genau das geht aber mit PMP nicht! Es sind darüber immer mehrere Befehle nötig, was viel umständlicher ist und länger (zu lange) dauert.
MCUA schrieb: > Es ist paradox, ein RISC mit vielen Registern zu benutzten, weil man > ja (gerade wegen RISC) auch viele Register benötigt Ach ja... hast du überhaupt schon mal einen AVR aus der Nähe gesehen? Der ist ungefähr so sehr "RISC", wie das auch ein PIC (12 ... 18) ist. Auch dessen Befehlssatz ist recht spartanisch, und typische CISC-Befehle wie komplette Schleifen (Z80 DJNZ, LDIR) oder sowas gibt's bei beiden nicht. Man benötigt also keinesfalls ...zig Register für einfache Aufgaben, sondern die Register sind einfach da und verfügbar. Sieh's anders: während die einfachen PICs einen Akkumulator haben, hat der AVR mindestens 10 Akkumulatoren, aus denen man sich seinen "Lieblings- Akku" aussuchen kann. Ich hätte übrigens früher (bevor ich AVRs kannte) auch nicht erwartet, dass man ohne Interruptpriorisierung so gut arbeiten kann. Doch, es geht. Davon abgesehen, wer AVRs mit echter Interruptpriorisierung haben will, kann sie ja nun auch schon seit einigen Jahren bekommen (Xmega), insofern ist das gar kein Thema mehr.
Carsten Sch. schrieb: > Hans schrieb: >> Also nur durch Bastler ist Atmel nicht knapp vor Microchip >> gelandet. >> Aber schenken tun die sich fast nichts. > http://www.elektroniknet.de/bauelemente/news/artic... > > Wobei du aber nicht vergessen darfst das diese Liste auf Basis der > gesamten µC Verkäufe zustande kommen ist und atmel bei weitem nicht nur > AVR herstellt. Da sind auch noch die ARM Familie und die 8051. Zudem > sind die im Smartcardbereich recht stark. Was für ein Halbwissen hier herumschwirrt, im SmartCard Business hat Atmel gar nichts mehr zu tun, eher NXP. Das SmartCard Business wurde schon 2010 an InsideSecure verkauft: http://www.eetimes.com/electronics-news/4208993/Atmel-closes-sale-of-smartcard-business Frank K.: >Anderes Thema: Abkündigung der AVR32AP7000'er Serie. Das >hat etliche Leute kalt erwischt. Atmel hatte einfach nicht die >personellen und finanziellen Kapazitäten, um AVR32 und ARM Cortex M3 >gleichermaßen zu supporten, und haben bei AVR32 die Axt angesetzt. >Autsch. Ein weiterer Grund, die Finger davon zu lassen. Auch falsch, der AP7000 ist immer noch in Produktion - lediglich nicht für neue Designs empfohlen. Soweit ich kürzlich gesehen habe wurde der AVR32 permanent weiterentwickelt (komplett neue lowcost D Serie, L Serie, etc.). Ich nutze den UC3C aufgrund FPU, CAN und Ethernet, und das ist schon längst in Produktion während ich noch keinen CortexM4 mit FPU, Can und Ethernet nicht mal als Sample bekommen konnte. Preislich liegen die UC3C recht günstig (UC3C mit 2x CAN, Ethernet, FPU, DSP und 64K flash für 2.2Euro bei 5000Stück Abnahmemenge im Jahr über dt. Distributor).
Wer die Register eines AVRs nur wie Akkumulatoren nutzt hat irgendwas nicht ganz verstanden. Die xmega haben übrigens nur 3 unterschiedliche Prioritäten. Das ist immer noch ziemlich spärlich
Hi >Wer die Register eines AVRs nur wie Akkumulatoren nutzt hat irgendwas >nicht ganz verstanden. ?????? MfG Spess
Hallo Fabian. Wenn Du das liest lächle doch bitte einmal nach rechts rüber. VG, der von rechts
Sebastian schrieb: > Carsten Sch. schrieb: >> Hans schrieb: >>> Also nur durch Bastler ist Atmel nicht knapp vor Microchip >>> gelandet. >>> Aber schenken tun die sich fast nichts. >> http://www.elektroniknet.de/bauelemente/news/artic... >> >> Wobei du aber nicht vergessen darfst das diese Liste auf Basis der >> gesamten µC Verkäufe zustande kommen ist und atmel bei weitem nicht nur >> AVR herstellt. Da sind auch noch die ARM Familie und die 8051. Zudem >> sind die im Smartcardbereich recht stark. > > Was für ein Halbwissen hier herumschwirrt, im SmartCard Business hat > Atmel gar nichts mehr zu tun, eher NXP. Das SmartCard Business wurde > schon 2010 an InsideSecure verkauft: > http://www.eetimes.com/electronics-news/4208993/Atmel-closes-sale-of-smartcard-business Ja - Toll... Und was hat das für Auswirkungen wenn man die Wirtschaftzahlen von 05-10 betrachtet? Genau KEINE! Davon abgesehen ist Halbwissen etwas völlig anderes als ein nicht genaues Wissen über jeden Ausverkauf der vor 1 1/2 Jahren stattfand. Aber ich gebe gerne zu das ich mich eher für die tEchnischen Möglichkeiten als für irgendwelche neuen Verkaufsideen der AtmelBosse interessiere. Zumal ja wie bereits mehrfach geschrieben Atmel seit geraumer Zeit für mich in so fern gestorben ist das ein Bautein der nur über Atmel verfügbar ist nur dann in das Produkt kommt wenn es keine annähernd gleichwertige Alternative gibt. Eben wegen der Folgen genau dieser rein auf Börsenwerte ausgelegten "ich verkaufe alles" Politik unter dem Aspekt: Fixkosten in Variable Kosten umwandeln und dann Variable Kosten senken. ISt zwar schon oft nach hinten los gegangen aber dann sind diejenigen die es verzapft haben schonmit dicken Boni verabschiedet, weil der Verkauf ja so viel Geld eingebracht hat... Gruß Carsten
Danke, um Beleidigungen ging's in diesem Thread nicht, und er ist bislang ohne sowas ausgekommen.
Die Sache hat zwei Seiten. Vom Ansatz her ist das schon richtig, was die Register bei RISC und CISC angeht. Aber leider nur vom Ansatz... Bei größeren CISC braucht man dagegen wenige Register, denn die meisten Befehle sind halt komplex und können direkt vom Speicher lesen und das Ergebnis wieder zurückschreiben, also ohne Umweg über Register. Da braucht man dann auch keine oder nur wenige Arbeitsregister sichern. Die alten PIC aber kombinieren leider beides maximal ineffizient: Es gibt wenige Register und die arithmetischen Befehle können nicht im Speicher arbeiten. Daher muss halt alles durch das W-Register gequetscht werden und man kann nicht einfach mal ein paar Register für die ISR reservieren, wenns wirklich schnell gehen muss. Unterm Strich kommt dann durch die ganze Schieberei zwischen RAM und W-Register doch wieder viel Text zusammen.
>Daher muss halt alles durch das W-Register gequetscht werden Ja, und bei ner Akku-Maschine muss auch alles durch A gequetscht werden. Trotzdem kann die als Source (machmal auch als Destin.) aber eine RAM-Zelle (innerhalb einer bestimmt grossen Bereichs) adressieren. Bei LD/ST-Archit., wie AVR, geht das eben nicht. Natürlich könnte man auch beim AVR alles nur über 2 Register machen, aber dann wärs schnarch-langsam.
MCUA schrieb: > Bei einer Akku-Architekt. sind prinz. viel weniger Register zu sichern > als bei RISC, mit vielen Registern, weshalb die RISC-ISR normalerweise > viel länger dauert. Haha, aber nur wenn man nicht programmieren kann... Wenn man sich die Register sinnvoll aufteilt, muss man nur das SREG sichern, allenfalls ein paar temporäre Register. Und mit Int-Prios hatte ich auch noch kein Problem, muss man halt die Ints entsprechend kurz halten. Also z.B. Serielle: RxD-Interrupt => Byte lesen => Byte in Ringbuffer => Buffer hochzählen => fertig, die ganze Auswertung macht man wenn man Zeit hat, das sind vielleicht 30 Takte im Interrupt plus 7 für rein und wieder raus
>MCUA schrieb: >> LD/ST-Archit. >Heißt was genau? Das heist, dass die ALU befehle nur auf Registern arbeiten können und nicht aufn RAM zugreifen. MIPS gehört auch dazu.
>> Bei einer Akku-Architekt. sind prinz. viel weniger Register zu sichern >> als bei RISC, mit vielen Registern, weshalb die RISC-ISR normalerweise >> viel länger dauert. >Haha, aber nur wenn man nicht programmieren kann... >Wenn man sich die Register sinnvoll aufteilt, muss man nur das SREG >sichern, allenfalls ein paar temporäre Register. Haha, aber dann bist du schnarch-langsam, denn >Natürlich könnte man auch beim AVR alles nur über 2 Register machen, >aber dann wärs schnarch-langsam.
MCUA schrieb: >>> Bei einer Akku-Architekt. sind prinz. viel weniger Register zu sichern >>> als bei RISC, mit vielen Registern, weshalb die RISC-ISR normalerweise >>> viel länger dauert. >>Haha, aber nur wenn man nicht programmieren kann... >>Wenn man sich die Register sinnvoll aufteilt, muss man nur das SREG >>sichern, allenfalls ein paar temporäre Register. > Haha, aber dann bist du schnarch-langsam, denn >>Natürlich könnte man auch beim AVR alles nur über 2 Register machen, >>aber dann wärs schnarch-langsam. Nein, denn man hat ja "genug" Register, sodass man mal 2 oder 3 für eine schnelle ISR reservieren kann und sie nicht sichern muss.
>Nein, denn man hat ja "genug" Register
Nicht, wenn man auch nur ein paar komlexere ISRs hat.
Hey Jungs, kommt runter. Nachdem der Thread durchaus sachlich begonnen hatte und ich sogar das eine oder andere z.B. über PICs gelernt habe wird jetzt wieder nur noch die 'meiner ist länger'-Fraktion bedient. Muß das sein? Es gibt Leute und auch Anwendungen denen egal ist wie toll die verwendete Architektur ist, die schauen halt wie schon erwähnt nach Verfügbarkeit, Preis oder auch spezieller Peripherie. Dann gibt es halt auch die Fälle wo eine tolle Architektur einen positiven Unterschied macht. Am Ende ist das aber s...egal, irgendjemand entscheidet was genommen wird und derjenige hat dafür irgendwelche Gründe (hoffentlich gute).
Was ist denn das für eine Diskussion? Entweder man optimiert die ISRs oder den Rest - gleichzeitig geht es halt nicht so gut (wobei ich noch keine "komplexen ISRs" hatte, meistens reichen 3-4 Register. Code, der alle 32 Register brauchte hatte ich dagegen schon).
Hi
>Nicht, wenn man auch nur ein paar komlexere ISRs hat.
Dann hat man etwas falsch gemacht.
MfG Spess
Frank K. schrieb: > Für mich liegen die eigentlichen Kritikpunkte woanders: ... Du sprichst mir aus dem Herzen. Dein sachlicher und gründlicher Beitrag war gut und hat eigentlich alles Wichtige gesagt. Es gibt aber von meiner Seite noch einen kleinen Blick in die Glaskugel: Auf der diesjährigen Embedded hat man es ja schon sehen können: Der Cortex in seinen diversen Spielarten hat bereits begonnen, die anderen aufzufressen. Deshalb wage ich mal die Behauptung, daß die Zeit der Atmel AVR's so langsam vorbei ist. Sie sind in Bastlerkreisen zwar noch vorrätig und sehr beliebt, aber sie müssen sich mit den Cortexen messen und da sehen sie in fast allen Disziplinen alt aus. Wenn der Cortex M0+ oder "Cortex M-1" :-) kommt, dann wird es noch enger. Da bleiben als potentielle Anwender für AVR nur Bastler oder Entwickler übrig, denen ein Cortex zu kompliziert ist. Das sieht bei MicroChip ein bissel ähnlich aus, aber nicht ganz. Die größeren PIC's (PIC24, dsPIC, PIC32) werden sich ebenfalls am Cortex messen lassen müssen. Bei den kleinen PIC's (12, 16) sieht das aber ganz anders aus. Die waren schon immer eine Domäne von Leuten, die ganz tief Embedded Hardware gemacht haben. In diese Nische von IC's mit 18 oder gar nur 8 oder 5 Beinen wird der Cortex wohl nicht vordringen. W.S.
>>Nicht, wenn man auch nur ein paar komlexere ISRs hat. >Dann hat man etwas falsch gemacht. ..oder einfach die Anforderung noch nie gehabt.
>Der Cortex in seinen diversen Spielarten hat bereits begonnen, die anderen >aufzufressen. Er wird mit Sicherheit nicht alle auffressen, denn es gibt (für fast das gleiche Geld) bessere CPUs als den.
>Also z.B. Serielle: RxD-Interrupt => Byte lesen => Byte in Ringbuffer => >Buffer hochzählen => fertig, die ganze Auswertung macht man wenn man >Zeit hat, das sind vielleicht 30 Takte im Interrupt plus 7 für rein und >wieder raus Son Kikifacks macht man mit DMA (wenn man den hat), kostet 0 CPU-Takte.
Martin Wende schrieb: >>MCUA schrieb: >>> LD/ST-Archit. >>Heißt was genau? > > Das heist, dass die ALU befehle nur auf Registern arbeiten können und > nicht aufn RAM zugreifen. > MIPS gehört auch dazu. Danke! Wirklich! Aber ich meinte den Terminus. Wofür stehen die Akronyme LD und ST. Damit ich mich etwas genauer belesen kann.
W.S. schrieb: > Da bleiben als potentielle Anwender für AVR nur Bastler oder > Entwickler übrig, denen ein Cortex zu kompliziert ist. Hast du dir auch schon einmal angesehen, wie viel Strom so'n ARM im Schlaf braucht? Die kleinen Strukturgrößen kosten halt. Der Tiefschlaf beim ARM schaltet den ganzen RAM ab, weil der Leckstrom bereits solche enormen Werte annimmt. Für den Leckstrom, den der RAM des ARM kostet, kannst du einen MSP430 oder AVR bereits mit 1 MHz rechnen lassen. Nein, es ist nicht nur eine Frage für "zu kompliziert" (zu kompliziert ist ein ARM auch für Bastler nicht).
Jörg Wunsch schrieb: > Fabian Hoemcke schrieb: >> Wofür stehen die Akronyme LD und ST. > > load and store. Alles klar! Danke! http://de.wikipedia.org/wiki/Load/Store-Architektur Solcher Background und auch das über Harvard/Neumann-Architekturen und Co. ist sehr interessant. Bin ohnehin gerade dabei mich darüber zu belesen. Aber so den richtigen Durchblick über das ganze Thema habe ich leider noch nicht. Angefangen von der Turing-Maschine (Turing und Turing-Test usw. ist soweit klar) bishin zu den MIPS. Wenn da jemand eine richtig gute Webseite kennt wäre das super. Zurück zum Thema. Danke erstmal für diese interessante und spannende Diskussion. Ich bin jetzt soweit, dass ich mir einfach preiswert einen PIC samt Programmer (Pickit3?) und einen MSP430 samt Programmer (LaunchPad?) besorgen und sie ausprobieren und einige Tutorials durcharbeiten werde. Aber ich weiß dann schon mal worauf ich mich bei dem jeweiligen Stein einlasse. Zum Beispiel dass beim PIC nicht an allen Port PullUps zur Verfügung stehen (warum?), was man ja aber leicht nachbauen kann. Oder, wenn auch alle gut für Sensorik geeignet zu sein scheinen, so sind es die MSP wohl noch ein Stück besser. Aber hier gilt es die Datasheets zu vergleichen. Was mich aber mal noch interessieren würde, wie habt Ihr es geschafft, günstig an Samples ranzukommen? Ich meine jetzt eher das Geschick mit den Firmen. Denn nicht immer, so habe ich hier gelesen, hatte man eine Firma im Hintergrund. ;) Ich meine, auch wenn das alles nicht so teuer ist, so bin ich doch froh über jeden Euro den ich nicht ausgeben muss. Gruß und einen schönen Abend noch Fabian
Hi >Was mich aber mal noch interessieren würde, wie habt Ihr es geschafft, >günstig an Samples ranzukommen? Gar nicht. Ich empfinde diese Schnorrerei als schamlose Frechheit. Vielleicht bin ich auch nur zu alt für diese 'Geiz ist geil'-Mentalität. MfG Spess
Fabian Hoemcke schrieb: > günstig an Samples ranzukommen? Samples sind dafür da, dass man Bauteile testen kann, die man sich (noch) nicht kaufen kann, oder zumindest nicht auf einfachem Wege. Sich einem MAX232 bei Maxim als Sample zu bestellen (nur weil sie ein günstiges Sample-Programm haben) ist genauso verpönt, wie einen x-beliebigen Controller, den man aus voll laufender Serienproduktion im Laden kaufen kann, beim Hersteller "schnorren" zu gehen.
W.S. schrieb: > Atmel AVR's so langsam vorbei ist. Sie sind in Bastlerkreisen zwar noch > vorrätig und sehr beliebt, aber sie müssen sich mit den Cortexen messen > und da sehen sie in fast allen Disziplinen alt aus. W.S. schrieb: > Da bleiben als potentielle Anwender für AVR nur Bastler oder > Entwickler übrig, denen ein Cortex zu kompliziert ist. W.S. schrieb: > Bei den kleinen PIC's (12, 16) sieht das aber ganz > anders aus. Die waren schon immer eine Domäne von Leuten, die ganz tief > Embedded Hardware gemacht haben. Äpfel und Bananen. Ein PIC12 oder ATtiny konkurriert doch nicht mit einem Cortex M0+.
@Jörg: Kleiner, schneller, sicher nicht ganz fair/objektiv/... Vergleich M3/AVR mit PicoPower Vergleich bei 3V. Der Cortex tut laut Datenblatt: EM0 current. No prescal- ing. Running prime num- ber calculation code from Flash. Beim AVR steht da nix genaues... EFM32TG110: 150 μA/MHz @ 28Mhz=>4.2mA Tiny44A sagen wir gnädiger Weise 13Mhz 3.5mA => ca 270uA/MHz! Naja, da "gewinnt" der Tiny... Gut und wie schaut's bei sagen wir 1Mhz aus: EFM32TG110: 210uA/MHz Tiny44A: dito! (wobei der dann bei 1.8V und nicht bei 3V rennt!) Also für mich zieht bei den AVRs nur mehr der Preis... und wenn ich mir anschaue was wir da für Preise bei Volumen rauskommen... naja... 73
Hans schrieb: > sagen wir gnädiger Weise 13Mhz 3.5mA => ca 270uA/MHz! Darum ging's ja nicht. Mir ging es um den Leckstrom des RAMs, allerdings ist der beim von dir genannten Controller wirklich extrem klein (0,6 µA). Viele andere ARMs haben Leckströme im Bereich von 10 ... 20 µA. Für eine Applikation, die wenig zu tun hat, aber sparsam mit der Batterie sein muss, ist das einfach zu viel.
Daher ja "nicht ganz fair/objektiv/..." ;) Aber wie andere schon festgestellt haben: Man sollte den Controller nehmen den man (für die Anwendung) braucht. 73
W.S. schrieb: > Wenn der Cortex M0+ oder "Cortex M-1" :-) kommt, dann wird es noch > enger. Cortex-M1 gibt es schon lange, nur wirst du den nie als Chip kaufen können. Das ist ein Design für FPGAs.
Fabian Hoemcke schrieb: > Schnorren? > Hatte sich hier aber anders gelesen. Naja, es kommt darauf an wie und was. In vielen Fällen IST es aber leider von einigen ein Schamloses Schnorren das dazu geführt hat das einige HErsteller ihre SampleProgramme eingeschränkt haben. Interessant ist dabei das teilweise gerade "GERMANY" von einigen besonders mit Argwohn betrachtet wird. Es ist so, das -je nach Abwicklung des HErstellers- eine SampleOrder viel höhere Kosten (Im Sinne von AUfwand und Porto) verursacht als der Kauf eines Bausteins. Wenn man TI als einen der HErsteller mit dem aus Sicht des "jedermanns" noch großzügigsten Sampleprogramm betrachtet der "JEDES" Sample noch PER EXPRESSVERSAND aus den USA um die Welt schickt so das es drei Tage später vor Ort ist, kann man sich in etwas vorstellen. Wenn nun - da es FÜR SIE SELBST ja kostenlos ist einige dann massiv die Möglichkeit der kostenlosen Samples Missbrauchen, ja es sogar einige gibt die MASSIVST die "teuersten Bausteine" Samplen und die Bausteine dann teuer bei Ebay oder selbst hier in den Kleinanzeigen VERKAUFEN wollen, dann führt das dazu das es für alle SChlechter wird. Sowohl für Unternehmen die für neue oder nicht ganz kurzfristig beschaffbare Bauteilmuster darauf angewiesen sind als auch für den Bastler der mal im AUSNAHMEFALL den Weg über die Sampleorder geht weil er das betreffende Bauteil nicht (in kleinen Stückzahlen) über die ihm offenstehenden Kanäle beziehen kann. Ich hatte oben ja z.B. den Fall mit den AT90USB geschrieben. DA waren Sample ja nur im gespräch weil ich KEINE CHANCE hatte irgendwie an kleine Stückzahlen im benötigten Gehäuse auf "normalen" Weg, also durch KAuf, in der benötigten Gehäuseform heranzukommen. (da waren die noch recht frisch...)Es war ja ursprünglich eine KAUFANFRAGE. Lediglich die Abnahme ganzer VE war möglich, aber ich lege mir doch keine dreistellige Stückzahl auf LAger nur weil ich eine Handvoll als Muster möchte. (10, oder auch 20 stück hätte ich ja noch genommen, wenn bei >10 auch Zähneknirschend) Es wird von den Firmen immer noch meist sehr positiv darauf reagiert wenn auch ein Hobbyist oder auch Student bei ihnen EHRLICH nach einem schwer verfügbaren oder (im Fall von Schülern/Studenten auch )wirklich teuren Baustein fragt wo eine Beschaffung auf anderen Wege nicht möglich ist. Aber EHRLICH: Ein Sampleversuch zu machen um dabei z.B. drei PIC18F25K20 in DIP abzustauben ist dann wirklich völlig überflüssig denn mir kann auch KEIN SCHÜLER erzählen das die 2,10 Euro/Baustein, also 6,30 Euro gesamt wirklich ZU TEUER sind. Und in den Fällen wo noch mal jemand händisch auf die Sampleorder drauf schaut -was einige jetzt eingeführt haben- oder wo später automatisiert die Sampleorder analysiert werden um festzustellen ob sich die Fortführung des "bequemen" Sampleprogramm lohnt wird es wohl von den meisten Firmen und auch USern hier ähnlich gesehen. Verständniss hatte ich aber z.B. dafür wenn ein Schüler/Studienanfänger mit noch wenig Erfahrung zwar einen PIC18F25K20 braucht, aber dieser nicht DIP sondern UQFN sein soll - warum auch immer. Diese kosten zwar auch nicht mehr, sind aber für Schüler nun wirklich nicht einfach zu beziehen da im Privatkundenmarkt ungebräuchlich. Wenn überhaupt dann nur mit horrenden Versandkosten! Wenn dann im Einzelfall eine entsprechende Anfrage gestellt wird... Aber als ehrlicher Tip: Wenn du mit den PIC anfangen willst so ist das PK3 keine Schlechte Wahl. Hier im normalen Privatkundenmarkt aber nur als SET unter dem Namen DEBUG Express verfügbar. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en538340&redirects=pickit3 (Downloads auf der SEite) Da ist neben dem PK3 noch ein Demoboard dabei, welches aber nur aus einem 18F45K20, einem Poti und ein paar LED incl. Vorwiderständen besteht. Der Schaltplan davon ist im "UserGuide" mit drin. Dieses Set kostet gut 20Euro mehr als der PK3 Einzeln. Diese 20Euro kannst du dir sparen. Das Board in verbindung mit den LessonFiles zur Einführung ist für einen Anfänger nicht verkehrt, kann aber mit Bauteilen für unter 5Euro selbst in wenigen Minuten auf Lochraster aufgebaut werden. (Pic1f45K20 in Dip holen) Was du versuchen KÖNNTEST ist mal ganz EHRLICH bei MC anzufragen besser Email vielleicht Telefon, und Fragen ob die dir -z.B. im Rahmen des UniversityProgramms- als Student der sich aus Eigenregie mit den PIC beschäftigen will- evtl. auch als einzelnen Studenten günstigere Konditionen oder zumindest den Kauf eines einzelnen PK3 hier bei einem Distri in DL einräumen können (ggf. auch bei Bauteilen ein wenig...) Deutsche Kontaktadressen findest du auf deren Seite. Oder du machst dich einfach Schlau ob an eurer HS vielleicht schon jemand Kontakte hat und du über die HS einkaufen kannst. Wie du hier lesen kanst waren die meistens ja recht kooperativ. Gruß Carsten
Andreas B. schrieb: >> Wenn der Cortex M0+ oder "Cortex M-1" :-) kommt, dann wird es noch >> enger. > > Cortex-M1 gibt es schon lange Er schrieb aber "Cortex M-1", also "Cortex Emm Minus Eins". :-)
MCUA schrieb: >>>Nicht, wenn man auch nur ein paar komlexere ISRs hat. >>Dann hat man etwas falsch gemacht. > ..oder einfach die Anforderung noch nie gehabt. Was denn zum Bleistift? Würde mich wirklich ma interessieren, mit welchen Anforderungen man eine ISR so vollbekommt, dass man a) ernsthaft timing-Probleme hat und b) ernsthaft mit den Registern an die Grenzen kommt Ok, ich hatte letztens auch eine kaskadierte 8-Kanal-Software-PWM, die bei 12MHz schon arg an die Grenzen des Timing kam, aber da war trotzdem noch Bedienung der Seriellen und bißchen Rechnerei nebenbei möglich.
Timm Thaler schrieb: > Was denn zum Bleistift? Würde mich wirklich ma interessieren, mit > welchen Anforderungen man eine ISR so vollbekommt, dass man a) ernsthaft > timing-Probleme hat und b) ernsthaft mit den Registern an die Grenzen > kommt Z.B. beim Power Cube: http://stage-kinetik.de/ Die Antriebe der einzelnen Segmente mußten absolut synchron arbeiten.
Timm Thaler schrieb: > Gibts auch funktionierende Links? Ich weiß nicht was Du hast, aber bei mir funktioniert es!
>Danke erstmal für diese interessante und spannende Diskussion.
Nur, der "Moderator" löscht Beiträge, weil er total dummes Zeug redet.
:
Wiederhergestellt durch Moderator
Hi >Nur, der "Moderator" löscht Beiträge, weil er total dummes Zeug redet. Dann würden ganz andere Beiträge gelöscht werden. Deine Sprüche hier sind wohl auf dem gleichen fachlichem Niveau wie dieser: Beitrag "Re: SRAM bei RTC" MfG Spess
>Deine Sprüche hier sind wohl auf dem gleichen fachlichem Niveau wie >dieser: >Beitrag "Re: SRAM bei RTC" Ja, mehr war da auch nicht zu sagen. Aber dafür kannst du, wenn es um CPUs geht >??????
Jörg Wunsch schrieb: > Für den Leckstrom, den der > RAM des ARM kostet, kannst du einen MSP430 oder AVR bereits mit > 1 MHz rechnen lassen. Nanana. Hab auf der letzten Embedded bei Nuvoton Cortex-M0 gesehen, die bei vollem RAM-Erhalt ca. 1.5 uA ziehen. Dabei sind die nicht mal die sparsamsten, den die von Energy Micro können das z.T. noch besser. Aber ich meine, daß das ein Nebenschauplatz ist. Die Veränderungen auf der Messe im Vergleich zu den Vorjahren war deutlich spürbar. Man kann das ignorieren, wenn man will - oder eben zur Kenntnis nehmen. und nochwas: Fabian Hoemcke schrieb: > Denn nicht immer, so habe ich hier gelesen, hatte man eine > Firma im Hintergrund. ;) Ja. das ist ein wirklich ernstes Problem - jedenfalls hier in Deutschland. Es gibt ne Menge Bastler (rein privat bin ich ja auch einer..) und als solcher an neuere Bauteile zu kommen, ist ein Krampf. Entweder geht garnix oder man muß sowas von Firmen kaufen, wo das Zeug unsäglich überteuert ist. Ich sehe das Problem, kann es aber nicht lösen. Da kann ich sehr wohl verstehen, wenn Leute sagen "ich mach's mit dem uC, den ich in meiner Bastelkiste habe". Auf der anderen Seite frage ich mich, was es denn für einen Zweck hat, wenn unsereiner ne Bastelanleitung postet, wenn kaum einer sie nachbauen kann - mangels Bauteilen. Manchmal hilft das Schnorren von Mustern. Habe das selber schon versucht mit recht gutem Erfolg, weil ich es ausprobieren wollte, ob man das einem Leser zumuten kann. Hab dadurch inzwischen nen privaten Account bei Analog Devices, den ich aber nur ganz piano strapazieren möchte. Bei Firmen wie TME kann man jedoch ganz offiziell als Privater einkaufen. Man zahlt zwar polnische MwSt und Transport, aber es geht. nochwas: spess53 schrieb: > Ich empfinde diese Schnorrerei als schamlose Frechheit. Ich nicht. Für die Firma mach ich sowas nicht, da wird ganz normal gekauft, aber für mein hier mal vorgestelltes Frequenzzähler-Projekt hab ich das ganz bewußt gemacht. Weil es mir schäbig vorkommen würde, mit Bauteilen zu protzen, die man nur per Firma bekommt und damit all die Leser auszugrenzen, die sich sowas basteln wollen, weil sie eben nicht in den wohlgefüllten Meßgerätepark der Firma greifen können. Es gibt auch die Kehrseite: Gelegentlich bekommen wir in der Fa. nennenswerte Mengen IC's vom Bestücker zurück, weil eben nicht mehr maschinell verarbeitbar da Luft gezogen oder weil Produktion ausgelaufen usw. Da sind massiv IC's dabei, die man als Bastler noch prima verwenden könnte, aber das Zeug geht den "bestimmungsgemäßen" Weg in die kostenpflichtige Verschrottung. Sowas hier für 10 Euro / Pfund wäre ne echte Hilfe für viele Bastler, aber es geht eben nicht. W.S.
spess53 schrieb: > Deine Sprüche hier sind wohl auf dem gleichen fachlichem Niveau wie > dieser: Das fachliche Niveau wäre völlig egal. Wenn der Herr den rein fachlichen Kram nochmal posten würde, bliebe es stehen. Fachliche Inkorrektheiten werden von anderen Forenteilnehmern richtig gestellt, die muss man nicht löschen. Aber er postet mit permanenter Bosheit sein hämisch-beleidigendes Getue und komplette Polemik mit, die hier einfach nicht her gehören. Gemessen an der erwartungsgemäß kontrovers diskutierten Fragestellung des TE war der Thread bis zum Auftauchen dieses Herrn insgesamt recht vernünftig verlaufen, da müssen wir uns sowas nicht antun.
W.S. schrieb: > Hab auf der letzten Embedded bei Nuvoton Cortex-M0 gesehen, die bei > vollem RAM-Erhalt ca. 1.5 uA ziehen. Dabei sind die nicht mal die > sparsamsten, den die von Energy Micro können das z.T. noch besser. Ja, hatten wir ja oben schon diskutiert. Ich hatte bislang nur mit anderen ARMs zu tun, und die ziehen halt einige 10 µA bei RAM-Datenerhalt. OK, der AVR mit 1 MHz bei gleichem Strom ist natürlich etwas übertrieben ;-) Generell ist aber bei kleiner werdenden Strukturen ein Ansteigen des Leckstroms normal, weshalb eben bei einfachen Aufgaben (die die Rechnleistung eines ARM hinten und vorn nicht auslasten würden) u. U. nicht der höchst integrierteste Controller der beste für den Job.
>Aber er postet mit permanenter Bosheit >sein hämisch-beleidigendes Getue und komplette Polemik mit.... ..lachhaft, das denkt der, der mit seinen Aussagen Mehrfach Total Daneben gelegen hat (und dazu auch noch ganz schön frech geworden ist)
Jörg Wunsch schrieb: > nicht der höchst integrierteste Controller der beste für den Job. Ja das ist ja klar: Für eine bestimmte Aufgabe ist nicht der allerdickste, sondern der am besten passende IC die optimale Lösung. Aber das hat auch mit eher nichttechnischen Konditionen zu tun: - mit welchen Teilen sich der/die Entwickler auskennen, - wie sich das in Stückzahlen rechnet, - was und wie gut verfügbar ist - ob man vielleicht was vermeiden will - was und wie an Entwicklungstools greifbar ist und so weiter. So, und nun Schluß für heute, ist ohnehin schon zu spät.. Frohe Ostern W.S.
Guten Abend! So, zum Thema schnorren. Klar, daran, dass man das ausnutzen kann, habe ich jetzt so nicht daran gedacht. Weiterverkauf von teuren Samples usw.. Ich bin eher davon ausgegangen, dass sie ein Interesse daran haben, Nachwuchskonsumenten zu generieren, und dafür „liebend gern” Standardteile springen lassen. So nach dem Motto, fragen kostet nichts. Aber Ihr habt recht. Beim Schnorren ist das auch nicht anders. Und wenn es wirklich nur 2€-3€ für ein Stein sind, ist es vielleicht auch etwas verfehlt. Ich rechnete eher so mit 5€-10€. Zu mindest kosten so die Atmegas (32-1284) bei meinem Haus- und Hoflieferanten. Keine Ahnung welches jetzt vergleichbare PICs sind. Mir ging es aber mehr um die Boards. Zum Beispiel das LaunchPad, dass gibt es bei Farnell für 3,83€ bei Segor kostet es 9,70€ und da ist das touchpad (egal ob man es brauch oder nicht, es ist verdammt cool) noch nicht dabei. Das PICKIT3 ist zwar cool, kostet aber mindestens 25€ ohne Porto http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,739,974&Prod=PG164130 . Sonst geht es erst bei rund 50€ weiter. Aber Carsten Sch. schrieb: > über die HS einkaufen ist eine gar nicht so schlechte Idee! Danke, daran hatte ich bisher gar nicht gedacht. Beim PICKIT3 ist kein Board dabei. Was ich bisher am STK500 sehr praktisch fand. Rauf stecken, Taster und LEDs sind schon dran und die Ports nach außen geführt. Denke mir aber, dass kann man gut nachbauen. (http://www.mikrocontroller.net/articles/PIC18f4550_Experimentier_Platine) Was ist gegen das oben genannte Board einzuwenden http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=200382626290&clk_rvr_id=329846163557 ? OK, ist jetzt auch nicht so viel drauf und kann nur PIC10-PIC18 programmieren, aber es ist preiswerter. ^^ Habe es irgendwo noch etwas billiger gesehen. Hat jemand mit dergleichen schon Erfahrung gesammelt? Würde das reichen? Zum Thema vergleichbar... ... ich habe per Zufall auf Ebay das chipKit UNO32 gefunden. Auch auf der Seite Digilent werden sie als Arduino kompatibel beschrieben: http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,892,893&Prod=CHIPKIT-UNO32 Compatible with many existing Arduino™ code... Das many existing code nicht nur arithmetische Operationen heißt, was sich leicht durch neues compilieren portieren ließe, sondern sich auch ansprechen von Peripherie, vermute ich mal ganz stark. Wie stark gleichen sich die Mikrocontroller-Familien? Oder zu mindest die PIC32 mit den AVR32? (Ich glaube nicht, dass sich der PIC32 vom chipKit Uno32 mit dem Atmega328 von Ardunio gut zu vergleichen ist. ^^) Einen AVR32 habe ich noch nicht programmiert. Aber wenn ich mir ansehe, wie exakt ich die Register für die Peripherie nutzen muss, kann ich mir kaum vorstellen, dass die Peripherie bei einem PIC genauso angesprochen wird. Bei den 32ern kenne ich mich halt noch nicht aus. Schade dass wegen meinem Schnorren die Frage nach den Basics für die Architektur untergegangen ist. Ich lese zwar gerade was darüber, aber es ist nur sekundäres Thema in dem Buch. Kennt einer von euch gute Seiten, in dem das ganze schön aufgearbeitet ist? Mir hat hier jemand Vorlesungsfolien angeboten. Mal sehen wie gut die sein werden. Frohe Ostern Fabian
Nach zwei, knapp drei, Jahrzehnten Elektronik-Bastel-Abstinenz hat es mich erwischt und ich wollte wieder mal was mit Mikrocontrollern machen. So hab ich mich denn im Internet umgesehen und bin zur Erkenntnis gelangt, dass 8-Bit-µCs reichen und AVRs und PICs in die nähere Auswahl kommen. Schließlich fiel meine Wahl auf die AVRs. Die Gründe: * gcc-basierte Toolchain Mit dem gcc bin ich seit - ich glaube - Version 2.2.2 auf unterschiedlichen Unix-Plattformen vertraut. Zuhause mache ich alles mit Linux. Windows XP gibt es zwar in einer virtuellen Maschine, aber nur um mal eben einen FTDI- oder MCP-USB-Chip zu konfigurieren oder die Doku aus dem AVR-Studio zu extrahieren. <frotzel>"wine" ist etwas, das man mit Genuss trinken sollte, nicht um Viren unter Linux lauffähig zu machen.</frotzel> Meine "Entwicklungsumgebung" ist seit rund zwanzig Jahren - privat und in der Arbeit - unverändert: vi und make. Es ist sauschnell und es tut, was ich will. Und das Beste ist, dass es keine Probleme wegen Updates gibt. * http://www.mikrocontroller.net Ein deutschsprachiges Forum liest sich für mich einfach schneller. Mein Englisch taugt ganz gut für Datenblätter und Fachliteratur. Beim zuweilen blumenreichen Englisch der Muttersprachler muss ich zuviel bei Leo nachschlagen und beim manchmal radebrecherischen Englisch der Anderen bleibt dann oft nichts Verwertbares übrig. Ist ja hier im Forum schon nicht immer einfach zu erraten, was die eine Verstümmelung oder andere schnoddrige Ausdrucksweise ("Jugendsprache" trifft es nur teilweise) bedeuten soll. Die AVR-Lastigkeit des Forums (im positiven Sinn) trägt sicher auch zu meiner Entscheidung bei. Preisunterschiede spielen für mich als Hobbybastler ganz sicher keine Rolle, zumal ich bei meinen Stückzahlen eher Handling-Kosten und Porto zahle. Eine weitere µC-Architektur/-Familie werde ich mir nicht antun, weil das einfach zuviel Zeit von der eh immer zu knappen Freizeit kostet. Ich schaue aber schon mal in ein "artfremdes" Datenblatt oder Projekt, wenn ein interessanter Beitrag das nahelegt.
Konrad S. schrieb: > ... mal eben einen FTDI- oder MCP-USB-Chip zu konfigurieren Mit libftdi-1 kannst Du FTDI Bausteine auch unter Linux konfigurieren
Jörg Wunsch schrieb: >Generell ist aber bei kleiner werdenden Strukturen ein Ansteigen des >Leckstroms normal, weshalb eben bei einfachen Aufgaben (die die >Rechnleistung eines ARM hinten und vorn nicht auslasten würden) u. U. >nicht der höchst integrierteste Controller der beste für den Job. Je kleiner der Prozess gefertigt werden kann, desto sparsamer im Stromverbrauch ist das Produkt. Das ist neben der besseren Ausbeute des Siliziums der zweitbeste Nebeneffekt einer Umstellung auf kleinere Strukturgrößen. So dachte jedenfalls ich bislang und habe noch kein widerlegendes Beispiel unter die Krallen bekommen.
Stimmt teilweise. Dynamisch wird's sparsamer, statisch nicht unbedingt! Gates kleiner => CU^2/2 kleiner => Umladen braucht weniger Energie => Verbrauch geringer Im statischen (also sagen wir einmal unter 1-10Mhz) spielen die Gate-Ladungen nicht die entscheide Rolle. Du kannst bei gröberen Technologien einfach dickere Oxid-Schichten einziehen => weniger Leckströme. Man kann auch bei kleinen Strukturbreiten da was machen, aber HighK-Oxide sind einfach teurer. 73
Uwe Bonnes schrieb: > Mit libftdi-1 kannst Du FTDI Bausteine auch unter Linux konfigurieren Danke für den Tipp. Seh ich mir mal an.
ich habe mit den AVRs in .ASM angefangen und hatte noch kein Bedürfnis zu wechseln. Von Atmel gibt ein kostenloses Entwicklungstudio und funktionierende Programmer, verfusen hatte ich bisher nur mit Ponyprog. STK500 bzw. Dragon konnten das wieder richten. Zum Studio ich arbeite mit der letzten 4er Version weil ich noch eine Single Core CPU nutze, der mir für alle Aufgaben bisher ausreicht und ich so ein Resources fressende Software auch nicht unterstütze. Mit der festen INT Prio hatte ich bisher noch keine Probleme, wenn ich diese aber ändern will kann ich jedem INT auf die gleiche gemeinsame Routine umleiten wo ich dann die INT-Flags selber auswerten kann. Ich sichere mir Ergebnisse z.B. immer mittels STS/LDS in definierte/reservierte RAM-Bereichen ab, auf die 2-3 Takte ist doch geschi**en. Nutze dagegen sehr wenige Register, wenn diese dann doch mal in einer INT-Routine genutzt werden pushe und pope ich Sie eben. Da ich eigentlich nur gängige Typen wie ATM16, ATT26/1...nutze habe ich noch keine Lieferschwierigkeiten mitbekommen, also für den Bastler auch unerheblich gibt ja nur sehr wenige Typen die so spezielle Hardware wie CAN.
Fabian Hoemcke schrieb: > So, zum Thema schnorren. > Klar, daran, dass man das ausnutzen kann, habe ich jetzt so nicht daran > gedacht. Weiterverkauf von teuren Samples usw.. > Ich bin eher davon ausgegangen, dass sie ein Interesse daran haben, > Nachwuchskonsumenten zu generieren, und dafür „liebend gern” > Standardteile springen lassen. So nach dem Motto, fragen kostet nichts. Im Prinzip stimmt deine Annahme ja schon. Zum einen sitzen am anderen Ende auch Menschen die nich tselten auch über das Hobby Elektronik zum Beruf gekommen sind und gerne auch mal unterstützen. Zum anderen ist natürlich der Effekt das man so früh eine positive Einstellung zu deren Produkten schafft auch nicht unwillkommen. ICh sehe es ja selber bei mir: Es gibt viele Designs wo ich verschiedene Alternativen habe und frei Wählen kann welche Serie ich einsetze. Und da kommen bei gleicher Eignung -nur durch meine persöhnliche Einstellung- bestimmte HErsteller halt besser Weg als andere. So eine Entscheidung hat manchmal dann nur Auswirkungen auf die eine Serie, in anderen Fällen legt es den Grundstein für eine lange Zeit des Einsatzes dieser Serie in vielen Folgeprodukten der Firma. (Kein Typenzoo gewollt) Aber den Effekt darf man natürlich auch nicht überschätzen und auf 100 Bastler/Einsteiger kommen vielleicht 10 die später im Beruf entsprechende Entscheidungen treffen könnten, wobei von diesen 10 vielleicht auch nur 1 oder 2 in Ihrer Wahl völlig frei sind. Aber wie gesagt, die Firmen reagieren unterschiedlich, meist aber aufgeschlossen. Zumindest wenn nachvollziehbar ist warum angefragt wird und erkennbar sit das der Hintergrund stimmig ist. Es war alles aber auch schon mal VIEL großzügiger, aber das wurde dann von einigen Leuten halt dermaßen Ausgenutzt das viele Firmen da kritischer sind. > Mir ging es aber mehr um die Boards. Zum Beispiel das LaunchPad, dass > gibt es bei Farnell für 3,83€ bei Segor kostet es 9,70€ und da ist das > touchpad (egal ob man es brauch oder nicht, es ist verdammt cool) noch > nicht dabei. Als Student kannst du ja bei Farnell bestellen! ist ja kein Problem und du bekommst auch noch Prozente (Das war mal in höhe der MwSt, damals 16%. Ob es jetzt 19% Nachlass sind oder immer noch 16, oder vielleicht doch ein anderer Wert, das weiß ich aber nicht) Alternativ kannst du diese TEile auch direkt bei TI in den USA Bestellen. (TiStore) Bei diesen TEilen ist -wie bei vielen Entwicklungskits in dem Store- der Versand im Artikelpreis enthalten (ACHTUNG: SCHEINBAR ABER NICHT BEI ALLEN)! Das TI Launchpad kostet $4,30 und das "MSP430 Capacitive Touch BoosterPack" $10. Also $14,30 ~ 11 Euro incl. Express Shipping! Und das ist auch für einen Studenten nicht zu viel. Braucht aber entweder PayPal Konto ODER Kreditkarte. Ansosnten veranstaltet gerade TI immer verschiedene Aktionen, so war jetzt kürzlich Anmeldeschluss für einen DesignWettbewerb für Studenten. Jedes angemeldete Team bekam da einen $100 Gutschein für den TI Store und besondere Samplebedingungen (mehr und teurere Bausteine). Im Rahmen einer Solchen aktion isch beteiligen... > Das PICKIT3 ist zwar cool, kostet aber mindestens 25€ ohne Porto > http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,739,974&Prod=PG164130 > . Sonst geht es erst bei rund 50€ weiter. Ist hier natürlich jetzt eine Frage des Versands! Wenn die Versandkosten niedrig sind könnte sich die Bestellung in den USA lohnen... Aber ich vermute mal die übersteigen die Preisdifferenz doch etwas. Ausserdem fällt noch 19% EUSt an wenn der Zoll das PAket in die Finger bekommt. (Man kann Glück haben, aber drauf vertrauen würde ich nicht) Die PK3 haben etwas im Preis angezogen... Alternative Beschaffungsmöglichkeiten (für dich) sind für 35Euro bei Farnell wo allerdings hier dann auch Versand und MwSt draufkommt (aber wahrscheinlich wieder Studentenrabatt runter) oder auch für jedermann der Kauf über MicrochipDirekt. Da kostet der PK3 auch 34Euro, es kommen noch 11 Euro Versand dazu. (Evtl. auch EUSt, da müsste ich selber jetzt auf meine REchnungen schauen...) Aber auch hier gibt/gab es in der Vergangenheit immer mal diverse Aktionen wo Schüler / Studenten /Auszubildende Rabatt bekommen haben und/oder keine Versandkosten zu zahlen hatten. Oder es hat -glaube hier im Forum- mal jemand berichtet das er auf eine Anfrage hin ausserhalb einer solchen Aktion einen Code bekommen hat mit dem er deutlich weniger im Shop zahlen musste. Das SET MIT BOARD kostet bei Reichelt mittlerweile 80Euro! Das lag mal bei nur knapp über 50Euro. Das ist nun wirklich schon teuer. Wenn du es nicht Eilig hast und es günstig sein soll kommt evtl. auch ein Clone in Betracht. Die beiden unteren SOLLEN ANGEBLICH 100% Baugleich mit den Original PK3 von Microchip sein, so das hier eine Ausnahme von der REgel -WILL MAN ES STRESSFREI -NUR ORIGINALPROGRAMMER FÜR PIC & AVR- gelten könnte. Da Microchip die Schaltpläne usw. für den PK3 offengelegt hat ist das durchaus nicht unwahrscheinlich das die Elektronisch Identisch sind. (Wohingegen Clones der AVR JTAGICE xxx mal mehr, mal weniger vom Original abweichen und da dann auch öfter mal Probleme machen) Für 21 Euro ein Clone des PK3 solo. http://www.ebay.de/itm/Clone-Microchip-Development-Programmer-Mini-PICKIT-3-/220990307991?pt=Wissenschaftliche_Ger%C3%A4te&hash=item33740c7e97 Oder für 27Euro incl. ZIF Adapter wenn man wirklich mal umstecken will oder muss. (Z.B. weil die PINS für ICSP nicht mehr frei sind) http://www.ebay.de/itm/PICKIT-3-MCU-Universal-ZIF-socket-for-PICkit-2-or-3-/230764695604?pt=Wissenschaftliche_Ger%C3%A4te&hash=item35baa5d034 > Beim PICKIT3 ist kein Board dabei. Was ich bisher am STK500 sehr > praktisch fand. Rauf stecken, Taster und LEDs sind schon dran und die > Ports nach außen geführt. Denke mir aber, dass kann man gut nachbauen. Ich bin zwar geteilter Meinung über solch "universalBoards" Es gibt ja das von mir erwähnte Set PICKIT3 DEBUG EXPRESS das aus dem PK3 und einem DEMO BOARD besteht. Zudem sind dabei noch Lesson Files incl. Beispielprogramme die in glaube neun Abschnitten einen Einstieg bieten! (Das haben z.B. Reichelt und Conrad für viel Geld im Angebot wohingegen die EinzelPK3 nicht im Angebot sind.) Dazu zitiere ich mich aber noch einmal selbst: Carsten Sch. schrieb: > Da ist neben dem PK3 noch ein Demoboard dabei, welches aber nur aus > einem 18F45K20, einem Poti und ein paar LED incl. Vorwiderständen > besteht. > Der Schaltplan davon ist im "UserGuide" mit drin. > Dieses Set kostet gut 20Euro mehr als der PK3 Einzeln. Diese 20Euro > kannst du dir sparen. Das Board in verbindung mit den LessonFiles zur > Einführung ist für einen Anfänger nicht verkehrt, kann aber mit > Bauteilen für unter 5Euro selbst in wenigen Minuten auf Lochraster > aufgebaut werden. (Pic18f45K20 in Dip holen) Daher noch einmal zusammengefasst: Wenn du kein verbilligtes Studentenangebot für dieses Set bekommst das dann so günstig ist das sich der Selbstbau nich lohnt empfehle ich folgendes 1. EINZELNEN PK3 besorgen (Notfalls Clone von Ebay) 2. Auf diese Seite gehen: > http://www.microchip.com/stellent/idcplg?IdcServic... > (Downloads auf der SEite) 3. Benutzeranleiteung und Anleitung für sie "LessonFIles" sowie die Zip Datei mit den Lesson Files herunterladen. 4. Einen PIC18F45K20 in DIP sowie einen IC Sockel besorgen und das Übungsboard nachbauen. Ausser dem PIC brauchst du dann noch ein POTI, ein Taster und ein paar LEDs (sowie einige Widerstände). Der Aufbau auf Lochraster würde mir am Sinnvollsten erscheinen, Notfalls geht aber sicher auch auf Steckbrett, wobei ich das wegen der Wackelkontaktgefahr immer etwas zweigeteilt sehe. DER SCHALTPLAN IST IM HANDBUCH DRINN! 5. Die Lesson Files durchgehen. Es gibt zwar nicht wirklich viel selbst zu machen, dafür ist Ausführlich vom kleinen Blinken bis hin zu ADC, TIMER und Interrupt alles Einsteigerverstänbdlich mit DEMO Programmen erklärt. 6. Eigene Programme angehen... später dann eigene HArdware bauen. Fabian Hoemcke schrieb: >(http://www.mikrocontroller.net/articles/PIC18f4550_Experimentier_Platine) > Was ist gegen das oben genannte Board einzuwenden Gegen dieses BOard ist Prinzipiell NICHTS einzuwenden. Damit kann man auch so einiges machen. Aber ich würde es doch, wenn denn so gewollt, erst im späteren Verlauf benutzen. Zuerst mal mit dem EINFACHST Board aus dem Nutzerhandbuch anfangen, darauf ist auch alles Abgestimmt. Später wenn schon etwas Grundlagen der PIC Besonderheiten vorhanden sind dann weitermachen wie du es für richtig hälst. Im Fall das sich jemand im Rahmen der beruflichen Tätigkeit mit den PIC auseinandersetzen soll würde ich hingegen für den Einstieg von allen EigenStarterboards die nicht von MC kommen abraten, da es ja auch sehr gute komplexe Boards von MC gibt die ready to use mit den sehr umfangreichen Beispielen und Frameworks ohne jede Anpassung laufen. Für die private Beschäftigung aber sehe ich ein das man diese Ausgaben oft lieber sparen will und dafür dann etwas mehr Zeit investiert bis es läuft. Komplexe Designs mit z.B. Ethernet mache ich nach 15Jahren Beschäftigung immer noch EVA-Boards als Ausgangsbasis wo ich mir dann den Teil rausziehe den ich brauche und in die eigene HArdware gieße. So kommt man am schnellsten zum Ziel. > http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=200382626290&clk_rvr_id=329846163557 > ? OK, ist jetzt auch nicht so viel drauf und kann nur PIC10-PIC18 > programmieren, aber es ist preiswerter. ^^ Habe es irgendwo noch etwas > billiger gesehen. Hat jemand mit dergleichen schon Erfahrung gesammelt? > Würde das reichen? Preiswerter? NEIN! SICHER NICHT! Es ist BILLIGER, aber das war es schon. LAss es mit solchen Dingern sein. Die Zeit dafür ist lange abgelaufen! Diese Einfachen Programmer waren damals für die ersten PICs mit EEPROM- bzw Flash Programmspeicher für viele der Ausgangspunkt. ICh selbst habe mit so einem Adapter auch angefangen. Die waren ja einfach Selbstzubauen: http://www.jdm.homepage.dk/newpic.htm (Welche PIC unterstützt werden ist nur eine Frage der Software, die Hardwareanforderungen sind immer gleich , man muss nur auf die Anschlüsse achten) Ich bin ECHT FROH das diese Zeiten vorbei sind und man für 30Euro Programmer bekommt. (Zu meiner Anfangszeit kostete der kleinste, damals PicstartPlus, um die 500DM) Diese JDM Programmer(und Ähnliche) programmieren den PIC durch einfaches Bit Wackeln MIT DEN STEUERLEITUNGEN der Seriellen Schnittstelle. Das ist Langsam -wobei das das kleinste Problem ist. Schlimmer ist: Das war unzuverlässig, immer mal wieder brach es ab und irgenetwas funktionierte nicht. Mal konnte ich eine Woche ohne Fehler arbeiten, dann musste ich 5x Programmieren bevor er einmal bis zum ende durchlief. Dies lief damals schon nicht mit ALLEN RS232 schnittstellen. Am DesktopPC ging es meist. Viele Notebook/Laptops hatten Probleme weil bei denen ja schon damals das SPannungsniveau nicht immer ausreichte. Gefühlt ist es bei den Geräten, sofoern die überhaupt noch RS232 haben, eher schlechter geworden. ICh hatte in der Vergangenheit auch schon DesktopPC die beim Bitwackeln Probleme hatten oder die Spannung auf RS232 zu gering war. Und bei Laptops erst recht. Die Zeiten der Robusten Technik sind vorbei und RS232 ist nur noch ein Anhängsel. ZUDEM: Viele RS232 USB Umsetzer funktionieren mit so einem teil gar nicht. Man braucht also unbedingt noch einen PC mit echter RS232, die aber auch noch den Standarts entsprechen muss. Und das aus meiner Sicht größte Problem ist die Softwareunterstützung! Alle diese Programmer brauchen wie die meisten Selbstbaubrenner eine Eigene Brennsoftware. Man kann also nicht wie bei den Originalprogrammern einfach mit einem Tastenklick das Programm Compilieren und direkt in den PIC schreiben, sondern man schreibt das Programm und Kompiliert dieses mit dem EINEN Programm - Dann beendet man dieses Programm und ruft das Brennprogramm auf, hier muss man die Files die der Compiler erstellt hat wieder einzeln reinladen, bei einigen muss man noch händisch jedesmal die ConfigFuses setzen (und das sind bei den neueren Chips eine Menge) und man kann dann erst brennen. Nach dem brennen geht man wieder aus dem Brennprogramm raus und ruft MPLAB wieder auf. ICSP geht wenn überhaupt nur wenn man glück hat und höllisch aufpasst, Debuggen keine Chance. Die Software wird oft schon seit JAhren nicht mehr weiterentwickelt so das neuere PICs gar nicht Programmiert werden können. Die 16 & 32 Bit PICs sind sowieso nicht enthalten. Und das alles um 20 Euro zu sparen ? (Bzw. sogar nur 5 wenn man den PK3 Clone nimmt) DAHER: WEnn mit PIC einsteigen, dann nimm einen PICKIT3 damit bis du gut bedient. Wenn du weisst das du VIEL mit Pic machen willst könnte man noch über einen ICD3 nachdenken, aber ganz ehrlich: Mit dem PK3 geht auch ALLES und für den Hobbyisten reicht der selbst bei 32Bit µC locker! Lasse die Finger vonn ALLEN FREMDPRODUKTEN die nicht in MPLAB selbst unsterstützt werden, wodurch dann ja nur 100% Clones noch in Frage kommen... Ach ja: Und es sollte wirklich ein PK3 bzw ICD3 sein. Das uralte PK(1) bzw. der ICD(1) -1 in Klammern weil ursprünglich ja ohne Nummer- können zwar in MPLAB verwendet werden, aber nur mit sehr wenigen Bausteinen! Selbst Geschenkt machen die heute kaum noch Sinn. Das PK2 / ICD2 wird noch öfter angeboten, aber auch hier werden viele Bausteine nicht mehr Unterstützt. Insbesondere sind hier die Spannungen wohl ein Problem da die wohl nicht weit genug nach unten geregelt werden können. Insbesondere bei den 32Bit sieht es sehr mau aus! Diese würde ich also nur dann in Betracht ziehen wenn die WIRKLICH sehr billig sind, also fast geschenkt! Zumal ja ab 20Euro was aktuelles zu bekommen ist. Zum ARDUINO/PINGUINO usw: Hier habe ich nicht wirklich viel Erfahrung. Dieses ganze System ist eher für "nichttechnsiche" Einsteiger die schnell bestimmte Erfolge in einzelnen Anwendungsgebieten haben wollen ohne tiefer einsteigen zu müssen. Es wird hier eine weitere Zwischenschicht eingeführt die das ganze noch HArdwareunabhängiger macht und noch weiter vereinfachen soll. Das ganze könnte man als geschlossene Benutzeroberfläche (die Tools gehören ja dazu) die mit einem C Dialekt und speziellen Libs arbeitet und dafür bestimmte festgelegte HArdware nach dem Baukastenprinzip verwendet beschreiben. Für eine berufliche Anwendung ist die nähere Beschäftigung nicht Sinnvoll. (Die Ausgangsidee war "Künstlern" eine Möglichkeit zu geben einfach in ihrem Kunstwerk mit wenig Aufwand etwas Blinken oder bewegen zu lassen) Natürlich ist es möglich EINFACH NUR die HArdware zu verwenden und damit mit den normalen Tools (AVRSTUDIO bzw. MPLAB) und dem normalen C Sprachumfang für diese µC zu arbeiten. Dagegen würde für Lötfaule auch nichts sprechen, aber wenn man den wirklich als ARDUINO mit der ARDUINO Oberfläche einsetzt lernt man halt den Umgang ARDUINO und NICHT die Besonderheiten von Pic bzw. AVR! Gruß Carsten
>Schade dass ... die Frage nach den Basics für die >Architektur untergegangen ist. Betr CPU-Architektur(en) ist das hier der Kindergarten.
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.