Eine Frage: Was ist besser für Anfänger. PIC oder AVR Prozessoren? Drei Sachen sind mir wichtig: 1. Einfacher Einstieg und leicht erlernbar 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten. 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit der gleichen Programmiersprache und 100% gleiche Syntax.
Hallo, hiermit eröffnest du die x-te Diskusssion über Gut und Böse. Jeder hat dazu eine eigene Meinung und nutzt den Controller der für seine Anwendung am besten geeignet ist. Datenblätter lesen und ein Programmiersprache lernen mußt du bei beiden. Jochen
schau dir mal das MSP430 Launchpad oder die Einsteigersets von STMicroelectronics an. Da bekommst du für 5 oder 10 Euro Programmer und Hardware für den Einstieg. Eigentlich hast du die Frage falsch gestellt. Es kommt darauf an, was du damit machen willst. Jens
Was ich machen will? Erst mal generell Erfahrung sammeln. Kleine, einfachere Projekte, bevorzugt mit bedrahteten Bauteilen. Die Leistungsklasse von 8Bit AVR/PIC wird mir noch einige Zeit reichen. MPS430 / 16 Bit wäre dann die nächste Stufe. Oder gibts die MSP430 auch in DIL und als Billig-uC für einfache Sachen? Wenn ich mal mehr brauche, dann nehme ich ARM, mit Linux. Oder AVR32 mit Linux. Das ist klar. Mit tcp/ip Stack, Dateisystem und solche Sachen auf AVR/PIC 8 Bit oder MSP430 werde ich mich nicht befassen. Wenn ich das mal brauche, gehe ich auf eine gut linuxtaugliche uC Plattform. Linux kann das alles sehr gut und es ist ein einfacher Weg.
Pat schrieb: > Eine Frage: Was ist besser für Anfänger. > PIC oder AVR Prozessoren? > Drei Sachen sind mir wichtig: > 1. Einfacher Einstieg und leicht erlernbar > 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten. > 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit > der gleichen Programmiersprache und 100% gleiche Syntax. Die Forderungen werden zumindest von den ATmegas problemlos erfüllt. Mehr kann ich Dir mangels Erfahrung mit PICs nicht dazu sagen.
zur Frage, welche uC ist besser gibt es nur eine Antwort: der uC mit dem DU dich am Besten auskennst ist der Beste. Denn nur mir Erfahrung kannst du aus einem uC die Funktionen rauskitzeln, die du implementieren willst. Zu 1.: wenn es einfach wäre würde es jeder machen. Die Einarbeitung kostet Zeit und Fleiss. Es gibt keinen bequemen Weg, aber der Weg lohnt sich. Zu 2.: Die IDE ist umsonst ( AVR Studio/ MPLab), Programmer ( AVRISP MKII/ Pickit 2/3 ) sind günstig. zu 3.: Wie wäre es mit C als Sprache ? Sollte von den meisten Prozessoren /Compilern verstanden werden. Das Betriebssystem, auf dem man entwickelt solle keinen Einfluss auf die Entscheidung pro oder contra für einen uC sein. Das OS, auf dem die IDE läuft ist nur ein notwendiges Werkzeug genau so wie ein Lötkolben. Habe mich noch nie davon leiten lassen ob ein Bauteil besser mit Weller oder Ersa zu löten ist. Am besten eine Münze werfen, Kopf -> Microchip, Zahl -> Atmel. Diese Entscheidung wird dir hinterher keiner kaputtdiskutieren. Und eine bessere Begründung gibt es nicht, denke ich. Gruß, dasrotemopped.
Pat schrieb: > PIC oder AVR Prozessoren? Schau mal links oben, was da steht. # Home # AVR Die PIC-Anwender sind also hier mit Sicherheit in der Minderzahl. Pat schrieb: > 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows Folgt man dem Link, findet man z.B.: AVR Eclipse: Win, Linux, Mac Peter
Hallo, eindeutig AVR. Vor allem, wenn man interessehalber Assembler programmieren will, sind die AVRs wirklich einfach erlernbar. PICs in Assembler programmieren? Nur für Masochisten. Die PICs, die ich mal gekauft habe, liegen ungenutzt in der Ecke, seitdem ich die AVRs entdeckt habe.
Pat schrieb: > Eine Frage: Was ist besser für Anfänger. > PIC oder AVR Prozessoren? > Drei Sachen sind mir wichtig: > 1. Einfacher Einstieg und leicht erlernbar > 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten. > 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit > der gleichen Programmiersprache und 100% gleiche Syntax. Nummer 3 erzwingt AVR. Für den gibts einen freien GCC-Port, und der ist unter Linux und Windows identisch. Bei PIC ist das anders. Die 8-Bit PICs (also bis PIC18) haben ein sehr C unfreundliches Design. Vollständig ANSI-kompatible C-Compiler gibts von Microchip (MPLAB C18) und von Microchip (Hitech C, Microchip hat die Firma gekauft), und hier hast Du die Wahl zwischen Windows und Windows. Man kann damit auch gut arbeiten, aber nicht unter Linux. Ab PIC24 basieren die C-Compiler von Microchip auch auf dem GCC. Microchip bietet die nur für Windows an. Technisch könntest Du den auf Linux portieren (und dabei den Lizenzmanager rauswerfen), aber die Lizenz der Bibliotheken (kein GNU) verbietet Dir das. (*) Das Debugging ist von Microchip meiner Meinung nach besser gelöst, die Tools billiger; und Du kannst z.B. MPLAB und ICD3 von PIC10 (6-Pinner) bis PIC32MX (80 MHz 32Bit MIPS-Kern) benutzen. Architekturmäßig sind PIC24 und AVR relativ ähnlich, mit dem Unterschied, dass PIC24 eben 16-bittig intern ist. Die kleineren PICs haben eine sehr spartanische Architektur, die 35 Jahre alt ist und ein architekturbedingtes RAM-Maximum von 4k-128 Bytes hat, auch noch schön mit Bankswitching und so. Den Strass sparst Du dir beim AVR. Wenn Du einen mit externem Adress/Datenbus hast, kannst Du extern problemlos 64KB RAM anschließen, mit Bankswitching auch noch viel mehr. fchk (*) Ich bin kein Anwalt, daher keine Rechtsberatung!
Hi, Marvin M. schrieb: > Hallo, > eindeutig AVR. > > Vor allem, wenn man interessehalber Assembler programmieren will, sind > die AVRs wirklich einfach erlernbar. PICs in Assembler programmieren? > Nur für Masochisten. > Die PICs, die ich mal gekauft habe, liegen ungenutzt in der Ecke, > seitdem ich die AVRs entdeckt habe. IMMER wenn jemand bei einer solchen Frage: Pic oder AVR sagt das EINER der beiden EINDEUTIG besser ist, dann ist die Aussage schon mal mit großer Vorsicht zu genießen - (Ich wollte jetzt nicht schreiben: HAt der keine Ahnung...) Beide Plattformen haben ihre Vor- und Nachteile und sind in der Summe für den Hobbybastler gleichwertig! Als ein Beispiel: Die Pics, auch exoten, bekommst du in DL fast ALLE Problemos -und das recht günstig. Bei dem was nicht 08/15 Bastlerware ist wird es bei Atmel dafür deutlich teurer und/oder schwieriger. Geht schon bei den Typen mit integrierten CAN oder USB los... Ausserdem bietet Microchip auch sehr Leistungsfähige Varianten noch in DIP an, also auch noch fürs Steckbrett oder den Grobmotoriker geeignet. Atmel nicht! Andererseits ist die deutschsprachige ATMEL AVR Community sicherlich einiges Größer als die ebenfalls nicht kleine PIC Commuunity. (International sieht es wieder anders aus) Und auch bei Tutorials, Frameworks usw. Für PIC gibt es eine Menge hervorragender Tools, Frameworks Beispielcodes direkt gut verständlich aufbereitet kostenlos von Microchip selbst. Aus der Community gibt es da natürlich auch noch was dazu. Bei ATMEL ist das Angebot von Atmel selbst bei weiten nicht so gut, das wird aber durch die Community wieder super wettgemacht! In der Summe kommt es wieder auf ein ähnliches Niveau heraus. Wem nun was lieber ist, das ist jedem Selbst überlassen. Ist auch eine Glaubensfrage Gibt PRO und CONTRA Argumente zu beiden Philosophien! Und es gibt noch viele andere Punkte mehr, Suche benutzen... Aber da die obige Meldung sich auf Assembler bezog: Wenn man zwischen PIC und AVR in Assembler vergleicht, dann gibt es Unterschiede. PIC hat einige Eigenheiten die Gewöhnungsbedürftig sind, keine Frage. Aber da reden wir von Dingen die ein normal begabter Mensch nach einer Stunde verstanden haben sollte. Dafür ist der Befehlsumfang beim Pic wesentlich kompakter als beim AVR, der auch so seine Tücken hat. Dem einen liegt daher eher der AVR Assembler, dem anderen die PIC Variante, der Dritte kapiert von beiden nichts... (Ausserdem sind auch die Vorerfahrungen entscheidend, wenn jemand vorher mit einem Controller gearbeitet hat dessen Assemblerprogrammierung eher der des AVRs glich, dann kommt er nun einmal anfangs mit PIC nicht so gut zurecht... Daher: Beides anschauen und dir deine eigene Meinung bilden! Frank K. schrieb: > Die kleineren PICs haben eine sehr spartanische Architektur, die 35 > Jahre alt ist und ein architekturbedingtes RAM-Maximum von 4k-128 Bytes > hat, auch noch schön mit Bankswitching und so. Den Strass sparst Du dir > beim AVR. Wenn Du einen mit externem Adress/Datenbus hast, kannst Du > extern problemlos 64KB RAM anschließen, mit Bankswitching auch noch viel > mehr. In dem Beistrag (gesamt) von Frank stehen viele richtige Sachen. Einer der (leder zu wenigen) AVR Freunde (so scheint es zumindest) der sachliche Argumente bringt. Wobei ich die Compilerfrage unter Linux nicht beurteilen kann. Ich akzeptiere das geschriebene mal so als Tatsache. (Will hier nicht den nächsten Krieg anzetteln, aber DAS was ICH mit MEINEM PC machen will und muss, das bekomme ICH mit Windows einfach mit deutlich weniger Aufwand und Ärger hin...) Zu dem oben zitierten Textabschnitt aber muss ich sagen: Stimmt, die alten PICs beruhen auf einem sehr alten, aber doch imemr weiterentwickeltem Design, erfüllen ihren Zweck sehr sicher, sind aber sicher alles ander als hochperformante Controller. Allerdings zieht man ja wenn man Mercedes und BMW vergleicht ja auch nicht auf der einen Seite einen 20Jahre alten Dreier und auf der anderen eine drei Monate alte S Klasse heran. Fakt ist: Microchip hat noch Controller mit den obigen Einschränkungen im Programm und wird die auch weiter noch vertreiben, zur Freude vieler Anwender - im gegensatz zu vielen anderen Herstellern die Rücksichtslose Abkündigungspolitik betreiben, aber es sind seit jahren andere Generationen Standart! Wenn man heute Anfängt, dann sicher nicht mehr mit einem 16C54, auch nicht mit einem 16F84, beides Fälle fürs Museum, sondern mit einem halbwegs modernen µC wie zum beispiel dem 18F4550 der auch gleich noch eine integrierte USB Schnittstelle (die man ja nicht benutzen muss) und universelle Takterzeugung mit PLL mitbringt, sowie sowohl in Assembler als auch in C Programmiert werden kann. (Wobei die Optimierung ganz klar in richtung C geht. Und wenn man dann die USB Schnittstelle nutzen möchte, dann ist ausser für den HArdcore Masochichsten alles andere als C eh ausgeschlossen, wo dann auch gleich ein super USB Stack von Microchip zur Verfügung gestellt wird. DAHER: Es gibt keine EINDEUTIG richtige Wahl. Mal ganz davon abgesehen das es noch deutlich mehr unter der Sonne gibt als PIC und AVR. (Wobei einer der beidne für den Anfang schon wohl das beste ist) Schaue dir beide mal genauer an, überdenke deiner Liste der Anforderungen noch einmal wie wichtig jetzt alles für sich genommen ist und ob vieleicht noch etwas dazu kommt, dann triff deine Wahl und fange mit dem dann an. Wenn jetzt die Frage nach der Toolgleichheit zwischen Windows und Linux (ohne Anwendung von virtuellen Maschinen) bei dir eine hohe Priorität hat, dann könnte es durchaus ja der AVR sein... Wobei mir das erst einmal zweitrangig wäre, denn in der virtuellen Umgebung läuft auch die PIC Windows Software unter linux - aber das muss jeder für sich wissen! Willst du aber später wirklich sinnvoll Arbeiten, solltest du unbedingt auch den anderen und noch weitere Controller nach deinen ersten erfolgreichen Schritten kennelernen wollen. Gruß Carsten (PIC und AVR Verwender (neben einigen anderen), allerdings mit einer Vorliebe für die Pics bei gleicher Eignung fürs jeweilige Projekt...)
ich habe mich für die PICs entschieden, und bin bis heute mit der wahl glücklich (ich musste auch mal AVRs programmieren). der ratschlag, eine münze zu werfen, wenn man nicht weiss, was man will, finde ich die beste lösung.
Wäre eine der beiden Architekturen der anderen wirklich größtenteils unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser". ;-) Einem Anfänger würde ich immer raten, mit C anzufangen und nicht mit Assembler. Sich mit der Hardware auseinander zu setzen ist auch so schon schwer genug. Details der Architektur wie "nur wenige, leicht erlernbare Assemblerbefehle" etc. sind da nicht mehr relevant. Und das spricht aus meiner Sicht dann am Ende für die AVRs als Einsteiger-Familie. Denn im Gegensatz zum PIC kann man hier die ganze 8-Bit-Familie - vom Acht-Beiner bis zum Tausendfüßler - mit ein und demselben Compiler (GCC) programmieren. Die Hardware ist in der Regel sehr konservativ und konsequent realisiert, so dass man sich bei einem neuen Stein sehr schnell zurecht findet. Das ist im Vergleich zu den PICs dem einen oder anderen vielleicht etwas langweilig ;-), ist für mich aber eher positiv zu werten.
Schau auch mal in die Errata der Bausteine. Mit PIC bist du tendenziell flexibler, da es eine aberwitzige Typenvielfalt für alle erdenklichen Spezialfälle gibt. Vorallem kriegst du die zu Spottpreisen nachgeworfen, das es schon fast wehtut. Die Kehrseite ist, dass Microchip ziemlich großzügig mit Bugs um sich wirft, selbst bei den kleinen 8-Bittern. Du wirst Mühe haben, irgendeinen Baustein zu finden, der keine Fehler im Silizium hat oder hatte. Leider sind das meistens nicht Fehler der Art, die man mit zwei Kondensatoren mehr am Quarz (ATmega8..) oder einem gescheiten Programmer (Signaturbytes gehen flöten bei einigen AVR) umgehen kann. Typische Fehler bei den PIC sind kaputte Instruktionen, die ungewollte Nebenwirkungen haben (löscht irgendwelche Bits) oder verbaute SRF: Der AD-Wandler hält nicht automatisch an, ein Timer-Modus ist kaputt, eine (erlaubte) Konfiguration des Timers löst einen Reset aus (der alte 12F635), um ein paar Beispiele zu nennen. Das kann ganz schön an die Nerven gehen. Als Hobby-Mensch ist das erst Recht frustrierend: Microchip flickt zwar auch Fehler, aber wenn du -- wie etwa bei Reichelt -- nicht erkennen kannst, welche Silizium-Revision du bekommst, ist das doof. Da ist der Fehler vielleicht schon drei Jahre behoben und du kriegst alte Lagerware. Schau für Spaß mal ins Errata des ENC28J60 (dieser Ethernet-PHY) rein. Verglichen damit sind die 8-Bit-AVR quasi 'perfekt'.
Hi, Detlev T. schrieb: > Wäre eine der beiden Architekturen der anderen wirklich größtenteils > unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser". > ;-) Full Ack > Einem Anfänger würde ich immer raten, mit C anzufangen und nicht mit > Assembler. Sich mit der Hardware auseinander zu setzen ist auch so schon > schwer genug. Details der Architektur wie "nur wenige, leicht erlernbare > Assemblerbefehle" etc. sind da nicht mehr relevant. Sehe ich etwas gespalten... Also die ALLERERSTEN Schritte mit einem Mikrokontroller würde ich immer in Assembler machen! Wenn man ein Programm vernünftige entwickeln möchte, dann braucht man einfach ein gewisses Grundverständniss für die Plattform auf der es läuft. Erst recht wenn man nur die extrem eingeschränkten DebugMöglichkeiten eines µC Anfängers hat, der die sowieso schon eingeschränkten Möglichkeiten mangels teurer Ausstattung nicht mal ansatzweise ausschöpfen kann. Aber klar! Alles was über einen LED Blinkschaltung mit Tastenabfrage hinausgeht braucht für einen Anfänger nicht merh in Assembler sein. Ich sage immer: Sobald die LED auf Tastendruck -anders- Blinkt gehe nach C! Allerdings hat der TE ja explizit nahc Assembler gefragt! Und dann gehören sowohl der Vorteil der nur wenigen Befehle wie auch der Nachteil -zumindest bei den ALTEN Modellen- der Bankumschaltung bei den 16F Pics genannt. (Auf AVR verzichte ich jetzt mal) > Und das spricht aus meiner Sicht dann am Ende für die AVRs als > Einsteiger-Familie. Denn im Gegensatz zum PIC kann man hier die ganze > 8-Bit-Familie - vom Acht-Beiner bis zum Tausendfüßler - mit ein und > demselben Compiler (GCC) programmieren. Die Hardware ist in der Regel > sehr konservativ und konsequent realisiert, so dass man sich bei einem > neuen Stein sehr schnell zurecht findet. Das ist im Vergleich zu den > PICs dem einen oder anderen vielleicht etwas langweilig ;-), ist für > mich aber eher positiv zu werten. Das ist aber bei den PICs auch der Fall wenn man möchte... Verwendet man statt des Microchip C Compilers nun den Hi-TEch Compiler, der ja ebenfalls, wenn auch mit für Hobbyisten völlig irrelevanter eingeschränkter Codeoptimierung, frei von Microchip Verfügbar ist. Dann hat du auch vom 6Pinner bis zum "großen Brummer" alles mit demselben Compiler. Die gesamte 8Bit Familie!!! Oder du entscheidest dich für den Microchip C-Compiler, weil du sagst OK, 6 und 8 Pinner brauche ich momentan nicht, wenn dann kann ich mich da auch noch kurz einarbeiten (SO Unterschiedlich sind die beiden Compiler ja nicht) dann hast du sowohl den modernen Teil der 8Bit Familie, die 16Bit Familie und die 32Bit Familie grundsätzlich mit demselben Compiler (auch wenn sich die interne Struktur natürlich ändert, aber das merkt man nicht) Darüberhinaus hast du hier vom 8Bit 6 beinigem Käfer bis zum 32Bit High End Controller mit DSP eigenschaften dieselbe Programmierhardware welche schon in der Grundversion für 30 Eur. umfangreiche Debuggingeigenschaften bietet. Das hast du bei AVR wiederrum nicht, Ach ja, der 32Bit µC von Microchip hat einen MIPS kern welches von der technologie eine der beiden großen Architekturen ist (neben ARM). 32 Bit MIPS µC werden auch von anderen Herstellern angeboten! 32BIT AVR haben etwas völlig eigenes welches in der Verbeitung um welten kleiner ist... Hat man aber gar nicht vor irgendwann auch auf 32Bit zu gehen -natürlich völlig irrelevant. DAHER: Die Münze ist manchmal ein echt guter Rat... (Ich würde ja PIC sagen, aber das ist rein meine eigene Sichtweise) Gruß Carsten P.S.: Ein echtes pro PIC Argument fällt mir aber gerade noch ein, mit dem Anfänger oft echt bei AVR zu kämpfen haben - Und mir fällt da bei leibe kein Gegenargument ein wo die Vorteile davon liegen könnten: Diese dämliche Eigenschaft der FuseBits beim AVR! Man kann sich beim AVR selbst aussperren, so das man über ISP nicht mehr in den IC reinkommt. Dies kann passieren wenn man einen Fehler beim setzen der FuseBits macht oder aber auch einfach wenn der Programmiervorgang gestörtt wird. Hat man keinen HV Programmen, dann kann man den IC wegwerfen... Hat man einen HV Programmer, geht das natürlich meist, manchmal muss man aber trotzdem den µC aus der Schaltung ausbauen und in einen eigenen Sockel setzen. Sehr toll bei SMD oder ungesockelten µC! Bei PICs kann dir das niemals passieren. Eine andere, aber hier nicht wirklkich tragische, Falle ist dann noch das JTAG Bit - denke aber das man hier mit leben kann. Für Anfänger nur manchmal ein Grund zum Stutzen...
Detlev T. schrieb: > Wäre eine der beiden Architekturen der anderen wirklich größtenteils > unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser". > ;-) In den 90ern entschied sich, welche Architektur den Server-, Workstation- und Desktop-Markt dominieren wird. Es war letztlich die unter diesem Aspekt unstrittig schlechteste von allen verfügbaren Alternativen. Das ist also kein Argument. Die Enscheidungen fallen anhand anderer Kriterien.
Sven P. schrieb: > Die Kehrseite ist, dass Microchip ziemlich großzügig mit Bugs um sich > wirft, selbst bei den kleinen 8-Bittern. Du wirst Mühe haben, > irgendeinen Baustein zu finden, der keine Fehler im Silizium hat oder > hatte. > Leider sind das meistens nicht Fehler der Art, die man mit zwei > Kondensatoren mehr am Quarz (ATmega8..) oder einem gescheiten Programmer > (Signaturbytes gehen flöten bei einigen AVR) umgehen kann. > > Typische Fehler bei den PIC sind kaputte Instruktionen, die ungewollte > Nebenwirkungen haben (löscht irgendwelche Bits) oder verbaute SRF: Der > AD-Wandler hält nicht automatisch an, ein Timer-Modus ist kaputt, eine > (erlaubte) Konfiguration des Timers löst einen Reset aus (der alte > 12F635), um ein paar Beispiele zu nennen. Naja, ganz so tragisch ist das aber nicht! Bausteine die auf dem Markt sind und solche gravierenden Fehler haben, die musst du aber wirklich suchen. Und die gibt es auch bei AVR! Da tun die sich nicht wirklich viel... Natürlich, bei Microchip hast du in der Summer mehr µC mit Bugs, einfach weil es deutlich mehr Bausteine gibt! Und auch weil die fast nicht vollständig abkündigen sondern Bausteine für die es keinen Baustein gibt der garantiert fast ohne Codeänderung 100% kompatibel ist im Programm lassen. Da bleiebn halt auch die BUgs mit drin. In der Beschreibeung der Bausteine steht dann aber auch eindeutig das die nicht mehr für stand der technik sind. Ob der Durchschnitt aber so viel schlimmer ist... Da gibt es bei AVR, wenn ich das jetzt noch richtig im Kopf habe, auch heute noch µCs wo zum beispiel das PWM Modul so buggy ist das es nicht zu nutzen ist. > Das kann ganz schön an die Nerven gehen. Als Hobby-Mensch ist das erst > Recht frustrierend: Microchip flickt zwar auch Fehler, aber wenn du -- > wie etwa bei Reichelt -- nicht erkennen kannst, welche Silizium-Revision > du bekommst, ist das doof. Da ist der Fehler vielleicht schon drei Jahre > behoben und du kriegst alte Lagerware. Naja, normalerweise erkennt man es schon, wenn es nämlich bedeutende Fehler sind, dann schlägt sich die änderung im Namen nieder. Dann heist der URbaustein zum Beispiel 16Fxx0 und die bearbeitete Version 16Fxx0-A. Das stht auch drauf. Davon abgesehen: Ich entwickle seit über 10 Jahren privat und beruflich Schaltungen mit µC. Und hatte erst -gerade extra noch nachgeschaut- drei mal den fall das ich bei Microchip wirklich im Errata Sheet nachschlagen musste warum der PIC nicht das macht was ich will und wie ich das zu umgehen habe. Bei AVR war es zwei mal der Fall. (Und ich nehme häufiger den PIC) Wenn man ehrlich ist, dann sind fast alle Fehler ja solcher aRt das die bei extrem speziellen Konstellationen erst auftreten! > Schau für Spaß mal ins Errata des ENC28J60 (dieser Ethernet-PHY) rein. Naja, wirkt erschreckend, aber das ist nun auch einer der ersten für Hobbyisten überhaupt verfügbaren Ethernet Controller gewesen. Und eine sehr Komplexe Funktion verbunden mit früher einführung ist nun einmal immer ein Fall für BUGs, KEIN Hersteller schaft das BUG-Frei. Aber gerade der ENC28J60 ist ein schlechtes Beispiel, weil der ja eigendlich der Baustein ist den die ganze AVR Welt verwendet. Die PICler nehmen einfach einen der PICs mit integriertem Ethernetkern und sparen so Platz, Kosten und Bestückungsaufwand. Ausserdem bleibt die SPI schnittstelle frei ;-) > > Verglichen damit sind die 8-Bit-AVR quasi 'perfekt'. Da wage ich zu wiedersprechen! Gruß Carsten
Detlev T. schrieb: > Wäre eine der beiden Architekturen der anderen wirklich größtenteils > unterlegen, gäbe es sie sicher nicht mehr. Soviel zum Thema "besser". > ;-) Fortsetzung: Wäre die Architektur wirklich ein Thema, die PICs wären aufgrund der Dominanz von Programmierung in C längst weg vom Fenster (und die übrigen Harvard-Biester einschliesslich AVR und i51 hätten auch einen schlechten Stand). Die PIC10/12/16 sind eine Katastrophe für einen C Compiler und die PIC18 sind in der Hinsicht auch erst in der zweiten Architektur-Revision erträglich - das ist diejenige, die im kostenlosen C18 nicht genutzt werden kann ;-). Statt dessen halten sich im 8-Bit Markt standhaft jene Architekturen, bei denen der C-Programmierer gezwungen ist, um Absonderlichkeiten der Hardware herumzuprogrammieren, wie getrennte Adressräume für ROM und RAM und ggf. gleich mehrere für RAM, Besonderheiten im Umgang mit Daten und Unterprogrammen in Interrupt-Handlern, ... Tatsächlich aber kann man auch Architekturen sehr wohl nutzen, die einem in mancher Hinsicht das Leben schwer machen. Eben weil es auch andere Gründe gibt. Die Funktionalität der I/O-Module der PICs wurde schon genannt. Andere wie i51 haben der Vorteil, dass sie irgendwie immer schon da waren und fast jeder Hersteller mit dazu beiträgt. Und ein bischen auch, weil man es so gewohnt ist, schon immer so gemacht hat, da könnte ja jeder kommen ;-). Das Gegenmodell wäre z.B. MSP430. Blitzsaubere Architektur, aber die Funktionalität hält sich verglichen mit PIC18, PIC24, AVR, ... sehr in Grenzen. Und die Interessen der Massenkunden sind sowieso gänzlich anders. Anders als Atmel und Microchip schert sich Freescale einen feuchten Dreck um Bastler und Krämer und überlebt dennoch. Denn in deren Markt steckt das Geld, nicht im Kleinkram.
A. K. schrieb: > Die PIC10/12/16 sind eine Katastrophe für einen C Compiler und > die PIC18 sind in der Hinsicht auch erst in der zweiten > Architektur-Revision einigermassen brauchbar - das ist diejenige, die im > kostenlosen C18 nicht genutzt werden kann ;-). Welche µCs können den im kostenlosen Compiler nicht genutzt werden... Das ist mir neu das es da welche gibt... ausser der schlechteren Codeoptimierung gibt es keine Einschränkung beim Compiler - und die ist für den Hobbyisten völlig irrelevant das diese in 95% der Fälle eh keinen Code schreiben der den Speicher selbst völlig ohne Optimierung auch nur Ansatzweise füllen würde. Und in den restlichen 5% der Fälle investiert man einfach die 10-20ct für den Bautein mit dem nächsthöheren Speicher. Bei der Massenproduktion mit Stückzahlen im 1000er -oder auch schon nur 100er- Bereich pro Tag sind die 10ct Baustein auf den Monat oder gar das Jahr gerechnet aber richtig Asche! Das die PIC10-16 Architektur für C einen Katastrophe sind würde ich jetzt nicht so sagen. Schwierig in der Umsetzung des Compilers - Ja auf jeden Fall! Aber wenn man sich nicht selbst eine Compiler schreiben will dann spielt das ja keine Rolle, den Kopf haben sich andere bereits lange vorher Erfolgreich zerbrochen ;-) Davon abgesehen waren die ja lange vor den AVR schon da, als von C als Standart-Programmiersprache für µC noch keine Rede war, die µC Welt fast Ausschließlich nur ASM Sprach! Dem Recht deines Beitrages könnte ich aber Bedenkenlos unterschreiben! Gruß Carsten
Carsten Sch. schrieb: > Bausteine die auf dem Markt sind und solche gravierenden Fehler haben, > die musst du aber wirklich suchen. Schon mal den CAN Controller der PIC18Fxx8 bewundert? Klar, es gibt längst die PIC18Fxx8x, die den urigen Adressierungsfehler nicht haben. Dafür einen anderen Bug. Nur dass der Adressierungsfehler leichter umgehbar ist. Überhaupt die CAN Controller. Mindestens die Hälfte aller integrierten CAN Controller von Microchip haben einen Bug drin, der bei Störungen auf dem Bus oder weglaufender Takterzeugung zu defekten aber nicht als solches erkennbaren Messages führen kann. Trösten tut einen allenfalls, dass es anderen nicht besser ergeht. Philips/NXP hatte sich in der ersten Generation der LPC2000 auch nicht grad mit Ruhm bekleckert.
A. K. schrieb: > Denn in deren Markt steckt das > Geld, nicht im Kleinkram. Das kann schon sein, der junge Entwickler, der nach dem Studium sein erstes eigenes Projekt hat, nimmt dann vermutlich eher eine vertraute Architektur, einfach um schnell ein Ergebnis zu erzielen und vor dem Chef gut dazustehen. Das dürfte in den meisten Fällen PIC oder AVR sein. Mir fällt auf die Schnelle keine Anwendung ein, für die ein PIC im Gegensatz zu 430, 8051, etc nicht geeignet ist. Bei den AVRs dürfte das ähnlich sein.
Carsten Sch. schrieb: > Welche µCs können den im kostenlosen Compiler nicht genutzt werden... Sie können durchaus genutzt werden. Aber nicht in dem Modus, der für C-Compiler eminent interessant ist. Die erste Architektur-Revision hatte noch auf die klassische statische Adressierung aller lokaler Daten abgezielt, erst im zweiten Anlauf schwenkte Microchip bei den Chips auf die umgänglichere Datenadressierung über einen Stack um (ich habe grad nicht in parat wie die das nennen). Der kostenlose Modus des C18 unterstützt diese zweite Revision jedoch nicht, verwendet daher die alte Methode. Wahlweise statisch oder auch als Stack, letzteres dann aber eher ineffizent. Übrigens war das Ziel meines Sermons oben gerade nicht, Architekturen, die für C Compiler weniger geeignet sind, zu verdammen. Sondern im Gegenteil, ich schrieb ja, dass sie trotzdem verwendet werden können und verwendet werden. Was ich schrieb war nur: Die zweite Revision der PIC18 Architektur ist für C Compiler deutlich besser geeignet als die erste. > Das die PIC10-16 Architektur für C einen Katastrophe sind würde ich > jetzt nicht so sagen. Schwierig in der Umsetzung des Compilers - Ja auf > jeden Fall! Eben, genau das war gemeint. Ich bin da ein bischen vorbelastet, weil ich sowas schon gemacht habe. Sowohl was geeignete wie auch was ungeeignete Architekturen angeht. Zeig mit eine ISA (Instruction Set Architecture) und ich sage dir, wieviel Flüche derjenige ablässt, der den Compiler dafür stricken darf ;-). Dass eine Architektur für C weniger geeignet ist, heisst nicht, dass man damit nicht in C arbeiten kann. Es heisst nur, dass der entstehende Code oft etwas krampfig aussieht. Das kann und wird vielen Anwendern egal sein. Wer da nicht öfter mal reinschaut, den interessiert das allenfalls beim evtl. etwas gedrosselten Tempo oder irgendwann beim Platz im ROM. Letzteres ist jedoch selten ein Thema, weil Microchip den vergleichbaren Teilen traditionell wohlweislich erheblich mehr ROM gönnt als beispielsweise Atmel oder TI.
Carsten Sch. schrieb: > Das ist aber bei den PICs auch der Fall wenn man möchte... Verwendet man > statt des Microchip C Compilers nun den Hi-TEch Compiler, der ja > ebenfalls, wenn auch mit für Hobbyisten völlig irrelevanter > eingeschränkter Codeoptimierung, frei von Microchip Verfügbar ist. Na gut, aber wenn ich als Hobby-Fummler auf der anderen Seite auch Optimierung haben kann, dann gehe ich doch da hin, oder?
Jens schrieb: > Mir fällt auf die Schnelle keine Anwendung ein, für die ein PIC im > Gegensatz zu 430, 8051, etc nicht geeignet ist. Bei den AVRs dürfte das > ähnlich sein. Versuch mal, Bendikts Text-Ansteuerung eines controllerlosen QVGA-LCDs mit einem 8-Bit PIC an Stelle eines Mega8 zu machen. ;-)
Carsten Sch. schrieb: > Davon abgesehen waren die ja lange vor den AVR schon da, als von C als > Standart-Programmiersprache für µC noch keine Rede war, die µC Welt fast > Ausschließlich nur ASM Sprach! Keine Frage. Es ist massgeblich das Verdienst von Microchip, den Markt von kleinen günstigen Controllern mit damals noch EPROM erkannt zu haben. Die waren davor in Form von 8751 oder Huckepack-Versionen prohibitiv teuer. Und die wurden meist in Assembler programmiert. Viele altgedienten PIC-Fans tun das noch heute - es gibt wenige Controller, bei denen sich das so hartnäckig hält.
Hallo, also ich benutze beruflich AVR, AVR32, Infineon, PIC und TI. Und ich muss sagen mir gefällt von allen die AVRs egal ob 32bit oder 8 bit am aller besten. Einer der Gründe ist der gute Support von Atmeleinem Man schreibt via E-Mail ein request und bekommt innerhalb von 1 Arbeitstag eine Antwort. Infineon ist da zum Beispiel das aller letzte. Ich finde auch die Programmiertools von Atmel (AVR ISP mk2 oder JTAG ice MK2 oder AVR Dragon) besser, da diese den besseren Connector haben. Bei PIC z.B so ein komische 6 polige Telefonbuchse. Da muss man immer irgendwelche Adpater basteln. Zwar hat PIC die größere Auswahl wie Atmel das ist ganz klar, dass macht es aber auch schwerer sich sinvoller zu Entscheiden welchen µC ich nun einsetze. Mit den BUGs ist das so ne sache. Bis jetzt musste ich einemal ein Workaround für den AVR32 machen. Ich bin froh das ich am meisten mit den Atmel µCs arbeiten kann. Aber letztendlich muss das jeder für sich selbst entscheiden.
Pat schrieb: > PIC oder AVR Prozessoren? > Drei Sachen sind mir wichtig: > 1. Einfacher Einstieg und leicht erlernbar Nimm Picbasic, einfacher geht es wohl nicht > 2. Preisgünstiger Einstieg mit möglichst niedrigen Kosten. Kannst ja alles bei ebay kaufen und hinterher verkaufen. Dann sind deine Kosten nahe 0 (Versand ist eh gleich teuer) > 3. Komfortables Arbeiten mit dem Prozessor unter Linux UND Windows mit > der gleichen Programmiersprache und 100% gleiche Syntax. Interessantes Kriterium Nimm ein Fernwartungsmodul unter Linux zu einem Windwos PC (ist nun mal Standard). Dann sieht alles fast gleich aus. Achte darauf das man deine beiden Monitore (natürlich mit gleicher Auflösung) Farbkalibrieren kann sonst sind Unterschiede nicht ausgeschlossen. Auch würde ich bei den Tastaturen Wert auf min. 5 Jahre Verfügbarkeit legen, sonst must du bei defekt gleich mehrere kaufen ;-).
Jens schrieb: > Das kann schon sein, der junge Entwickler, der nach dem Studium sein > erstes eigenes Projekt hat, nimmt dann vermutlich eher eine vertraute > Architektur, Aber nur wenn dieser junge Entwickler in einem eher kleinen Unternehmen steckt, in dem das Projekt massgeblich sein eigenes Kind ist. Ist er aber beispielsweise in einer Schublade eines grösseren Unternehmens mit Ziel Massenproduktion untergebracht, dann hält sich seine Entscheidungskompetenz über solche Fragen wohl in Grenzen.
Ts, ts. Ein Glaubenskrieg zu Weihnachten. Kann das nicht bis morgen warten?
Verglichen mit dem schon seit Tagen laufenden AC/DC-Krieg ist das hier doch harmlos, gesittet und sogar sachlich. Und anderswo streitet man sich grad drum, ob man Leuten überhaupt frohe Weihnachten wünschen darf, ohne sich als Religionsfanatiker zu outen.
micro1 schrieb: > Ich finde auch die Programmiertools von Atmel (AVR ISP mk2 oder JTAG ice > MK2 oder AVR Dragon) besser, da diese den besseren Connector haben. > Bei PIC z.B so ein komische 6 polige Telefonbuchse. Da muss man immer > irgendwelche Adpater basteln. Nö, musst Du nicht. Einfach AC164110 ordern, dann hast Du das passende. http://www.microchipdirect.com/productsearch.aspx?Keywords=AC164110 Auch das PICkit3 benutzt den Pfostenstecker. fchk
Warum geht es hier denn immer nur um AVR vs. PIC? Die MSP430 sind IMHO auch eine alternative, insb. weil es mit MSPGCC und mspdebug eine brauchbare Toolchain für Linux gibt. Damit, dass es die nur in SMD gibt, muss man sich abfinden.
Luk4s K. schrieb: > Damit, dass es die nur in SMD gibt, > muss man sich abfinden. Nun ja, die MSP430 Value Line gibt's auch in DIP. Siehe LaunchPad.
Intel Freak schrieb: >Intel MCS-48 Familie is the best! ;-) Das ist auf Grund der geringen Komplexität der µC zum Einstieg gar nicht so abwegig. Ebenso wie die anderen alten Gurken aus den 1970-er Jahren, wie z.B. 8085, Z80, 6502, 6809. Der 8048 ist auch noch nicht ausgestorben, befindet sich z.B. immer noch in neueren Massenprodukten wie PC-Tastaturen. Im Grunde kommt aber alles in Frage, was sich an Kleincontrollern am Markt befindet. Selbst beschäftige ich mich gelegentlich mit alten 8051-Derivaten. Irgendwas in Richtung Freeware gibt es im Netz immer. Verwende den vollwertigen und unlimitierten SDCC-Compiler erfolgreich, und als IDE einfach nur für den Project-Tree mißbrauche ich eine alte Keil-Demo. Den EPROMMER habe ich noch aus alten Zeiten, aber sowas wäre auch mal schnell selbst gebaut. Statt EPROMs brennen, machte ich mir ein Monitor-EPROM. Das erspart neues Brennen für Testsoftware, geht so gut wie Flash. Bloß flasht man nichts auf Dauer oder durch einen Softwareirrtum kaputt. Für den 8051 gibt es auch Flash-Versionen, Demo-Boards mit USB, SiLabs ist sehr modern. Ich fand an diesen Dingern immer den Befehlssatz und die Architektur sehr klar und schön. Einen ARM7, z.B. LPC2xxx von NXP, ist schön, halte ich zum Einstieg aber schon etwas oversized. Mit dem PIC-Assembler kann man sich auch anfreunden, hat er doch nur 35 Befehle. Habe da letztens ein wenig mit dem PICkit1 experimentiert, ein paar Basteleien auf Assembler gemacht, und sie dann auf C portiert. Das sind alles nur meine persönlichen Meinungen.
zum adapter: ich hab da ein 10-poliges flachbandkabel an das telefonsteckerkabel gemacht, wobei jede 2. ader des flachbandkabels GND ist und vorne den stecker deiner wahl. wenn jede 2. ader GND ist, kann das kabel ohne weiteres 50cm lang sein, was ich sehr praktisch finde :-) ...und btw: so ein adapter bastelst du dir genau ein mal ;-)
Intel Freak schrieb: > Intel MCS-48 Familie is the best! ;-) Genau! endlich sagt das mal einer! mfg.
Mir fehlt dann aber unbedingt noch der 3850 (F8). Der Mikrocontroller der ersten Jahre. Der 8048 war doch bloss ein Abklatsch davon.
Frank K. schrieb: > Nummer 3 erzwingt AVR. Für den gibts einen freien GCC-Port, und der ist > unter Linux und Windows identisch. > > Bei PIC ist das anders. Die 8-Bit PICs (also bis PIC18) haben ein sehr C > unfreundliches Design. Vollständig ANSI-kompatible C-Compiler gibts von > Microchip (MPLAB C18) und von Microchip (Hitech C, Microchip hat die > Firma gekauft), und hier hast Du die Wahl zwischen Windows und Windows. > Man kann damit auch gut arbeiten, aber nicht unter Linux. Kleine Ergänzung: Auf http://ww1.microchip.com/downloads/MPLAB/X_Beta/installer.html Linux x86 auswählen... > Ab PIC24 basieren die C-Compiler von Microchip auch auf dem GCC. > Microchip bietet die nur für Windows an. Technisch könntest Du den auf > Linux portieren (und dabei den Lizenzmanager rauswerfen), aber die > Lizenz der Bibliotheken (kein GNU) verbietet Dir das. (*) > > Das Debugging ist von Microchip meiner Meinung nach besser gelöst, die > Tools billiger; und Du kannst z.B. MPLAB und ICD3 von PIC10 (6-Pinner) > bis PIC32MX (80 MHz 32Bit MIPS-Kern) benutzen. > > Architekturmäßig sind PIC24 und AVR relativ ähnlich, mit dem > Unterschied, dass PIC24 eben 16-bittig intern ist. Wobei die PIC24/dsPICs wesentlich besser in Maschinensprache programmierbar sind...
Master Snowman schrieb: > zum adapter: ich hab da ein 10-poliges flachbandkabel an das > > telefonsteckerkabel gemacht, wobei jede 2. ader des flachbandkabels GND > > ist und vorne den stecker deiner wahl. wenn jede 2. ader GND ist, kann > > das kabel ohne weiteres 50cm lang sein, was ich sehr praktisch finde :-) > > ...und btw: so ein adapter bastelst du dir genau ein mal ;-)Beitrag melden | Bearbeiten | Löschen | Ja klar im Hobbybereich vielleicht. Aber ich sag mal wenn mehrere Entwickler mit einem Tool arbeiten müssen, oder auch eine kleine Produktion damit arbeiten muss geht so ein Basteladapter sehr schnell kaputt. Da bevorzuge ich doch den einfachen 6 oder 10 poligen von Atmel. Der Connector kann dann direkt auf der Leiterplatte sein
A. K. schrieb: > Mir fehlt dann aber unbedingt noch der 3850 (F8). Der Mikrocontroller > > der ersten Jahre. Der 8048 war doch bloss ein Abklatsch davon. Aber ich arbeite nur mit modernen Systemen. Immer auf der Höhe der Zeit! mfg.
Also während meiner Ausbildung habe ich ausschließlich mit Pic und Assembler gearbeitet. Nun Arbeite ich mit dem ATmega32 und C als Sprache. Ich schließe mich Grundsätzlich den Antwortern an die sagen, das du selbst rausfinden musst welcher Baustein für deine Anwendung der geeignetste ist. DU brauchst auf jedenfall, egal welcher baustein das Datenblatt. Das ist Esenziell. ICh steh zwar auch noch am Anfang mit den AVR´s, aber das sind eben erfahrungen die man bereits am Anfang sammelt, und es ist auch eine Verständiss sache. Nimm aber am Bestenm gleich einen Baustein, der dir nicht zu bald zu schwach oder zu klein wird. Ich hab mich für den ATmega32 entschieden weil der für später Einiges Parat hält und wenn ich den von der Pike auf benutze und damit Groß werde, verstehe ich diesen vllt auch richtig. Aber auf jedenfall steht fest Ohne Fleiß kein Preis
Dass die alten PIC so eine Katastrophe für Assembler und C waren, lag ja nicht an der geringen Zahl von Befehlen. Es lag und liegt daran, dass die Architektur 'alt' und aus heutiger Sicht total verkorkst ist. Alles irgendwie durch ein Arbeitsregister zu quetschen ist nervig, die Bank-Umschalterei selbst bei so wenig RAM ist für Compiler eine Zumutung. Z80 wäre auch noch da.
@micro1: adern auftrennen, die richtigen miteinander verlöten, schrumpfschlauch und fertig - sieht sauber aus und ist kein gebastel: aufwand 15min und kosten 2.- (zumindest meiner sieht sauber aus und hat schon viele strapazen überlebt) wenn entwickler nicht fähig sind einen robusten adapter zu entwickeln, sind die entwickler das grössere problem für die firma als der suboptimale adapter ;-) ..aber wir reden hier ja sowieso von privat-hobby-entwicklern.
A. K. schrieb: >Der 8048 war doch bloss ein Abklatsch davon. Immerhin war das olle Ding damals (tm) gut genug, damit die Entwickler noch jeweils 20 HW- und SW-Fehler in die Geräte hinein produzierten. Und zwar baute ich als TK-Techniker damals (tm) bei Kunden 1981 die ersten Familientelefonanlagen auf, die etwas intelligenter waren als alles zuvor. Manchmal fielen die Dinger reihenweise aus, und ich war bei manchen Kunden 3 mal zum Auswechseln. Aus Neugier, meine Kollegen taten das nicht, schaute ich auch mal in so eine Anlage hinein. Nur 8035, 2k EPROM, 2k RAM. Industrielle und frei gegebene Geräte. Trotzdem hatte man das nicht im Griff. Und da fangen heute manche mit einem ARM-Board an, je größer desto besser, besser ARM9 als ARM7, und wissen oft nicht mal, was ein CMOS-Prozess ist, oder gar ein Spannungsteiler aus 2 Widerständen. Genau da sträuben sich mir die Haare, aber extrem. Die Fragen ließt man ja hier in der Threadliste immer wieder.
Sven P. schrieb: >Z80 wäre auch noch da. Die Z80 und 8085 fand ich mal interessant, weil sie einfach einen gigantischen Stack bis zu 64kByte im von-Neumann-Adressraum hatten... Da kann man die Software demnach gestalten, daß Speicherinhalte schon mal auf den Stack gepusht werden, anstatt in Registern abgelegt. Bei 8048, 8051, PIC, ist das völlig unmöglich. Ich experimentierte gelegentlich mal mit einer so selbst gebauten 8085-Schaltung, allerdings in Assembler, das war ganz nett.
Wilhelm Ferkes schrieb: > Und da fangen heute manche mit einem ARM-Board an, je größer desto > > besser, besser ARM9 als ARM7, und wissen oft nicht mal, was ein > > CMOS-Prozess ist, oder gar ein Spannungsteiler aus 2 Widerständen. Genau > > da sträuben sich mir die Haare, aber extrem. Die Fragen ließt man ja > > hier in der Threadliste immer wieder. Richtig! Wer mal mit 8085 oder 8048 oder so angefangen hat, hat nicht nur rund 30 Jahre Erfahrung auf dem Buckel, sondern die ganze Materie zumeist auch wirklich verstanden. Wenn dann ein neuer Controller ran muß, nimmt man sich das Datenblatt... mfg.
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.