Hallo, ich bin relativ neu in der MC-Materie, (die Suchfunktion hat übrigens nichts ausgeworfen) und möchte gerne Wissen was überhaupt die unterschiede zwischen einem "PIC" und den ATMEL AVR MCs ist. Ich habe bereits einen 4bit 12c508 von Microchip Arizona programmiert (gebrannt) und mache im Moment einen Kurs für den AT90S4433 , ich sehe schon das es da Leistungsunterschiede gibt, 4bit vs. 8bit CPU, Befehlssatz , Tiefe des Stacks... aber was heisst zB PIC?
Dann Antworte ich mir jetzt mal selber - PIC scheinen eine µC Familie von Microchip Arizona zu sein, Harvard Architektur, RISC und mit unterschiedlich viel Bit verfügbar die AVR sind ja ATMEL Risc Controller... und wie ich gehört habe gibt es noch m68k - erinnert mich verdammt an M 68000 von Motorola. Dieser hat ja damals Amiga, Atari, MACs und andere Rechner befeuert.
Ich würde Dir gern weiterhelfen - aber ich hatte bislang nur 8051-Derivate und den Atmel unter meinem Lötkolben. Ich hatte auch mal vor, mit PIC anzufangen; nachdem ich dann allerdings die Preise von den Löschbaren Eprom-Typen gesehen habe und ich just in diesem Moment die wesentlich preiswerteren Atmel entdeckt habe, hatte PIC keine Chance mehr bei mir. Dies ist schon einige Jahre her, inzwischen gibts auch einige PIC-Typen mit Flash. Ich habe irgendwann mal aufgeschnappt, daß der PIC eine relativ alte Struktur hat, wo man (wie beim 8086) mit Speicher-Segmenten arbeiten müsse, da der Adressraum nicht reicht. Ist aber ohne Gewähr.
Der PIC12C508 ist auch ein 8-Bitter und nicht 4. Am bekanntesten sind natürlich die 8051-er. Und mit über 30 Herstellern auch die Familie mit den meisten Varianten (interne ADC, DAC, PCA, UART, I2C, CAN, USB, MP3, Ethernet). Zum 8051 kann ich Dir ne Menge sagen. Die PICs habe ich mir auch mal angesehen, aber wenn man erstmal 8051 gemacht hat, will man sich mit sowas nicht mehr abquälen. Dann gibts noch den sehr neuen MSP430, aber der scheint recht verschwenderisch mit Speicher umzugehen. Ein Herr Nobody klagt hier öfters darüber. Als 8-Pinner gibts noch den ACE1202 aber da hat man keine Möglichkeit bei größeren Programmen zu upgraden, ist also keine Familie. Und mit Google findet man einen Haufen Seiten, wo sie allen verglichen werden. Aber man sollte sie alle lesen, da manchmal die Sicht etwas subjektiv ist. Was mir an den 8051-er besonders gefällt, ist, daß man einen weiten Bereich von Anwendungen mit den gleichen Tools erstellen kann. Für kleine Sachen ist der preiswerte AT89C2051 gut geeignet. Was nach oben hin möglich ist, zeigt z.B. das: http://www.ibutton.com/TINI/hardware/index.html mit 512kB Flash, 512kB SRAM, Ethernet, Java usw. Und der Witz ist, auf diesem Board läuft auch ein kleines Programm, geschrieben für den kleinen AT89C2051, völlig ohne Änderungen. Die Befehle sind auf jedem 8051 die gleichen. Ich kann also z.B. mit meinem uralten Keil C-Compiler Programme für den neuesten Cygnal-8051 schreiben, ohne ein Compilerupdate zu benötigen. Ihn interessiert schlichtweg nicht, welches Derivat ich einsetze, es ist ein 8051-kompatibler, das reicht ihm völlig. Peter
Bin zwar eigentlich immer noch ein Newbie bzg. der µC-Materie, aber vielicht kann ich ja doch helfen. Im Folgenden sind unter Garantie ein paar inhaltliche Fehler, bitte korrigieren wenn nötig. Ich verstehe deine fage ein wenig im Sinne : "Welchen der beiden µC soll ich nehmen?" Hatte vor ca. 1 Jahr mit AVRs begonnen, bin aber aus heute nicht mehr nachvollziehbaren Gründen auf den PIC umgestiegen, bin nun aber wieder bei den AVRs gelandet. Gleich vorweg MEINE Meinung bzg. PIC vs. AVR : AVR sind besser. ***************************** EIGNUNG FÜR DEN HOBBYBEREICH ****************************** Zahl der "Modelle" ------------------ Die Familie der PICs ist recht gross, es gibt so ca. 100 verschiedende PICs in jeweils unterschiedlicher Ausführungen (im Farnell-Katalog sind fast 1000 veschiedende PICs aufgeführt) Für den "Hobbyanwender" kommen von diesen vielen PICs aber nur eine Handvoll in Frage, und zwar diejenigen mit einem Flash als Programmspeicher. Die meisten der PICs sind mit einem EPROM versehen und nur ein mal zu programmieren, idR. steht dann irgendwo <OTP>, OneTimeProgramable. Ich glaube es gibt nur ca. 5 PICs mit Flash, von diesen hatte ich nur mit dem PIC16F84 gearbeitet. Im Folgenden beziehe ich mich nur auf PICs mit Flash. Im Gegensatz dazu sind die AVRs alle mit einem Flash ausgestattet, für den Hobbyanwender sind also alle AVRs der BasicLine interessant (mit den Megas habe ich noch nichts gemacht). Austattung ---------------- Im allgemeinen sind die Flash der AVRs grösser, BasicLine bis 8kB, die PICs scheinen nur max. 2kB Flash zu haben. Der Rest, also Anzahl Timer,PWM,UART,ADC/Comparator usw. ist vom jeweiligen µC abhängig, im allgemeinen bekommt man bein AVR "mehr". Programmierbarkeit -------------------- Bei den AVRs geht das extrem einfach, Stichwort ISP. Steht alles auf den Seiten von Andreas im Tutor. Hervorzuheben ist,daß keine extra Programmierspannung nötig ist, also die optionalen 5V ausreichen. Die PICs können auch per ISP programmiert werden, im Prinzip genau wie bei den AVRs, nur braucht man zum Brennen des Flash eine eigene Programmierspannung von +12V, die über den ISP-Progger erzeugt wird (kann sein das es auch einfacher geht), der bauliche aufwand ist grösser. Software -------------------- Sowohl von AVR als auch MicoChip werden kostenlose Assembler und Simutatoren zum Download angebten. Bei AVR ist es das AVR-Studio, bei MicroChip das MPLAB. Sind beide mehr oder weniger als gleichwertig anzusehen. Für beide µC gibt es dann noch verschiedene Compiler. Hier also kein nenenswerter Unterschied. Preise -------------- Über den Daumen gepeilt haben der PIC16F84 und der A90s1200 in etwa die gleiche Ausstattung, die Preise der beiden µC kann ja jeder selber nachschauen und sein Urteil dann bilden. *************************************** LEISTUNG der µC *************************************** Preise und Hardwareaustattung hin und her, aber wie sieht es mit der Leistung aus ? Bit-Breite der ALU ----------------- beide 8 Bit Takt vs. Zyklus --------------- AVR der BasicLine laufen mit max. 8MHz (1200er bis max 10MHz), der PIC mit max.10MHz. Bei einem AVR entspricht ein Ausführungszyklus einem Takt, bei dem PIC jedoch entspricht ein Zyklus 4 Takte. Ein PIC hat also einen max.Zyklustakt von 10/4 MHz =2,5MHz. Befehlsumfang ------------- Beide haben einen RISC Befehlssatz, der AVR ca. 120 verschiedene Befehle, der PIC "nur" 35 Befehle. Das der PIC weniger Befehle hat als der AVR ist nicht unbedingt ein Manko, aber bei den 120 Befehlen des AVRs sind einige dabei welche das Programmieren sehr erleichtern und die man beim PIC sich mühsamm "zusammen bauen" muß. Stack --------- Der PIC hat nur einen Hardware Stack welcher max. 8 Adressen enthalten kann. Der AVR hat dagegen die Möglichkeit den Stack auf das SRAM auszudehnen, wodurch man sich über die Anzahl der Sprünge/Interrupts idR. keine Gedanken machen muß. Interrupts ---------- Handhabung mehr oder weniger bei beiden gleich (über Vektoren) I/O Register ------------- Bei beiden vergleichbar, in speziellen Registern werden zB. Hardware des µC eingestellt oder Interrupts freigegeben usw. Unterschied: Bei den AVR sind die I/O Register alle "übereinander" im RAM, bei dem PIC sind die I/O Register in zwei Blöcke zu je 128 Adressen aufgeteilt, Bänke genannt, man muß deshalb zwischen beiden Bänken (Registerblöcken) hin und her schalten, welches über ein eigenes I/O Register erfolgt. Habe vergessen warum das so war, glaube es liegt daran das die Bitbreite der indirekten Addresierung beim PIC nur 7Bit breit ist Arbeitsregister -------------- Hier grosser Unterschied. Bei dem PIC hat man nur ein einziges Register welches sich direkt beschreiben lässt, bei den AVRs dagegen 31 (bzw.16 wenn man es genauer nimmt). Bei den AVRs vermeidet man so viele unnütze Schiebebefehle zw. den Registern. Sehr Praktisch bei den AVRs sind die drei jeweils aus zwei Registern bestehnden Pointer-Register um 16-Bit Zahlen oder 16-Bit adressen bequem zu verarbeiten. Ich denke es gibt noch eine Menge weitere Unterschiede. Ich halte die AVRs wie gesagt für besser, muß aber sagen daß ich Assembler erst mit dem PIC (halbwegs) verstanden habe, der PIC ist etwas übersichtlicher. gruss markus
das ist ja wirklich umfangreich, interessant. Wäre nur noch interessant wie die m86k Serie da hinein passt. Wenn sie wirklich auf dem 68000er basieren hat man da einen schnellen 12/32 bit prozessor ...
Zum Thema PIC-Nachteile: Ein gravierender Nachteil der PICs ist, daß zumindest bei den kleineren Typen nur ein Interruptvector für alle Interrupts verwendet wird. Dadurch ist es schwierig bis unmöglich, die Interruptquelle zu erkennen, wenn mehrere Interrupts verwendet werden müssen. Den Hardwarestack sehe ich auch als großen Nachteil an, da somit der Stack zur Parameterübergabe ausfällt. Wie vorteilhaft es ist, wenn man auf den Stack zugreifen kann, zeigt das Beispiel im Anhang (8051-Code). Da wird die Returnadresse der aufrufenden Funktion als Zeiger auf die Daten verwendet. Das ist bequem, übersichtlich, schnell und speichersparend. Beim AVR ist sowas auch möglich, aber viel aufwendiger, da die Adresse noch mit 2 multipliziert werden muß, bzw. bei Rückkehr wieder durch 2 geteilt werden muß. Peter
Hallo, um hier mal etwas Licht reinzubringen. Also die M68K derie sid 16/32 Bit Controller. Hier gibt es sicher eine Verwechslung mit den M68HC Controllern. Ich habe mich da mal für die 68HC08 entschieden. Die HC11er sind etwas knapp an Speicher, haben aber ein externes Speicherinterface. Die bestückung des externen Speicherinterfaces macht aber die Schaltung wieder Aufwendigen und es gehen einem eine Menge I/O´s verloren. die HC08er haben alles On-Board und sind mit Flash ausgestattet. Verfügen über ISP und auch über In-System Debugging, man muß also ncht immer mit sonem blöden Simulator rumspielen and sich wundern, warum das dann auf dem wirklichen System nicht läuft. Zur Architectur : Von neumann Architektur, alles läuft über einen zentralen Akkumulator. Man muß sich also keinen kopf machen wo man seine Daten oder sin Programm hinpackt und wie man das dann adressieren kann. Was CISC und RISC betrifft würden die meisten hier wohl sagen, das ist CISC. Die diskussion über RISC kam aber eigentlich sowieso erst mit den 16 Bittern auf. Die Ausführung der Befehle dauert in der Regel 1-5 Takte, was sich aber durch die Speicherzugriffe erklärt und durch das nur einfach vorhandene Speicherinterface. Da kann man keinen Opcode Fetch auf den Programmspeciher Parallel zum Datenspeicher ausführen, eil es nur einen Adressbus gibt. Die Dinger lassen sich bis zu 8,2 MHz Bustakt hochtreiben, was einer Zykluszeit von 125 ns entspricht. Das läßt sich über einen Oszillator regeln, die lassen sich aber auch mit einem 32 kHz Quarz betreiben und dann wirde die Takfrequenz über die Programmierbare PLL variabel gesteuert. Manche haben auch einen Internen Oszillator. Die relativ einfache Architektur macht auch die Assembler Programmierung sehr überschaubar. Wenn man sowieso in einer Hochsprache programmiert dann kümmert sich der Compiler um die Eigenheiten der MCU. Desweiteren braucht man die Maximalgeschwindigkeit sowieso nur in den seltensten fällen. Eckhard
Hallo Herr Schumann, ich benutze den PIC16F84 für einfache Steuerungen und den 68HC811E2 für komplexere Anwendungen. Angefangen habe ich mit dem HC11 (CICC Controller, complex instruction set)weil er sehr comfortable Befehle besitzt und incircuit programmierbar ist. Daraus hat sich ein kleiner Steuerrechner ergeben mit 4*4 Tastatur und HEX Anzeige den ich nun überall zur Steuerung von anderer Hardware einsetze. Den PIC habe ich mir noch ausgesucht weil er wesentlich schneller ist als der HC11 (allerdings bei Mehrfachverzweigung machen ihn die Schleifendurchläufe ebenfalls langsam) und mit 18 Pin preiswert und einfach auf Platinen unterzubringen ist. Es gibt fast für jedes Problem den passenden Controller aber wer kann schon danach entscheiden. In diesem Forum habe ich mal eine Anwendung für den PIC dargestellt, der Schaltplan sollte mal eine komplette Anwendung (läuft auch im Einsatz) zeigen. Möglicherweise als Anregung für andere Projekte. Ich persönlich vermisse nachvollziehbare und nachbaufähige Schaltungen inclusive der Programme dazu. MfG Manfred Glahe
@Manfred, diese Art Beispiele sehen nur für den Entwickler einfach und nachvollziehbar aus. Jeder andere hat da mächtige Schwierigkeiten. Besonders wenn man nicht so PIC-bewandert ist, vermißt man doch sehr eine strukturierte Programmierung. Das Programm enthält eine Menge GOTOs und springt kreuz und quer, das ist absolut nicht einfach nachvollziehbar. Aber das ist wohl die typische Struktur aller PIC-Programme und dem limitierten Hardwarestack geschuldet. Auf anderen µC mit Stack im RAM kann man richtige Funktionen schreiben mit CALL und RET. Dann kann man auch jede Unterfunktion erklären, d.h. was reingeht, was rauskommt, welche Ressourcen verwendet werden. In großen Projekten mit mehreren Entwicklern wird es sogar gefordert, jeder Funktion einen derartigen Kommentarkopf voranzustellen. Und nur diese Art Programme ist dann auch von anderen nachvollziehbar. Dann ist es auch hilfreich, nur die interessierende Unterfunktion auf eine Problemfrage zu posten und nicht das gesamte Programm. Solche Unterfunktionen lassen sich leicht isolieren und in andere Projekte einfügen. Die Codesammlung ist ein gutes Beispiel dafür. Kann natürlich sein, daß dann solche strukturierten Programme von einem nur PIC-Style gewöhnten einiges an Umdenken erfordern, um sie zu verstehen. Peter
Hallo Herr Dannegger, für größere Programme oder aber Teile solcher welche mit anderen verknüpft werden müssen haben Sie natürlich Recht, aber das ist hier nicht der Fall. Mit dem MPLab z.B. ist das Schrittweise duchgehen des Programmes keine Hürde. Relevante Variablen und Registerinhalte sind nach jedem Schritt sichtbar und können an Hand des Schaltplanes gewichtet werden. Das ganze ist eben sehr Hardware orientiert. Wer Schwierigkeiten hat, Verzweigungen nachzuvollziehen, bekommt dann auch mit einem strukturierten Programm ab einer bestimmten Komplexität die gleichen Probleme. Diese Art von Programmen hat viel mit Schach oder Entflechten gemeinsam. Es braucht halt viel Übung und Übersicht,ist dann aber auch mit wenig Speicher zufrieden.Und sehr schnell im Ablauf. MfG Manfred Glahe
So, das sind jetzt erstmal genug verwertbare Informationen, evtl. könnte man dies doch noch etwas genauer ausführen (zu jedem Typ gleichviel) und es dann in die FAQ von Mikrocontroller.net übernehmen. Ich denke es ist nämlich so, das jemand der schon (hardwarenahe) Programmierung für 680x0 gemacht hat, mit der m68k Serie wohl besser klar kommt, als jemand, welcher vorher zB. MIPS R3000A Assembler oder x86 ASM gelernt hat. Ich habe mir die ATMEL AVRs mal angesehen, wahrscheimlich nehm ich so einen, beim 12c508 hab ich mich vertan, er hat 8 bit, aber 12 bit wortbreite (darum auch nur 30 Befehle), und ja - die EPROM-Varianten sind teuer, aber wenn man sich 3 OTPs verbraten hat, lohnt es sich dann doch.
@Manfed, ja wenn ich dazu erstmal eine komplett neue Entwicklungsumgebung installieren muß und dann noch deren Bedienung lernen muß, ist das ja alles noch viel komplizierter, als ich dachte. Ich hatte es auf die übliche Methode versucht, also einfach Lesen des Quelltextes und da hatte ich spätestens nach dem 10. GOTO den Faden komplett verloren. Aber ich hab auch noch alte 8051-Programme aus meinen Anfängen, die bestimmt genau so unübersichtlich sind. Und obwohl ich sie selbst geschrieben habe, ist es nach Jahren äußerst schwer, sie wieder zu verstehen. Der monolithische Stil, die Programme aus einem Stück zu meißeln sieht ja auch erstmal einfacher aus. Und die Einsicht in die modulare Programmierung kommte eben erst mit zunehmender Praxis, wenn man merkt, man hat ähnliches doch schon mehrmals gemacht und will nicht immer wieder bei jedem neuen Projekt vollständig von vorne anfangen. Peter
Hallo Herr Dannegger, die Entwicklungsumgebung von MPlab kostet wirklich nicht viel und ohne gutes Werkzeug meist auch keine gute Arbeit. Ein Unterprogramm mit CALL aufzurufen ist nun wirklich nicht umständlich sondern übersichtlich. Aber ich lasse mich auch von Ihrer Sicht überzeugen.Liefern Sie mir doch mal ein passendes Beispiel! Aber bitte keine Lösung bei welcher das Problem der Lösung angepaßt wird. Das einfachste ist, Ihre Version zur Steuerung eines Verbrauchers an dem beschriebenen Generator, dann ist ein Vergleich einfach.Es geht ja nur darum eine Abweichung von einer vorgegebenen Frequenz festzustellen und darauf entsprechend mit Abschalten zu reagieren. Wiederanlaufschutz nach dem erneuten Erreichen der 50HZ ist notwendig. Bin auf Ihre Lösung gespannt. Frohes Fest! MfG Manfred Glahe
Ab einer gewissen Größe führen aus einem Stück gemeißelte Hin-und-her-spring-Programme unweigerlich dazu, dass man den Überblick verliert. Die einzige Möglichkeit den Überblick zu behalten sehe ich darin, dass man die Programmbestandteile in Funktionen oder sogar Objekte kapselt, die von außen als "black boxes" betrachtet werden können. Extrembeispiel dafür ist der Gegensatz "goto"-Basic <-> Lisp. Aber wie sind wir eigentlich auf dieses Thema gekommen? ;-) @Holger S: Ich werde (falls keiner hier was dagegen hat) die Antworten auf einer eigenen Seite zusammenfassen.
Ein paar Stichpunkte zu PICs und AVRs: http://www.mikrocontroller.net/articles/controllervergleich.htm @Peter: Möchtest du vielleicht eine ähnliche Auflistung für den 8051 machen?
@Andreas: Ich hab hier mal was dazu geschrieben: http://www.specs.de/~danni/tutorial/microg.htm http://www.specs.de/~danni/avr/compars.htm http://www.specs.de/~danni/avr/pitfalls.htm Hab grad gesehen, Motorola macht jetzt auch in Flash: http://e-www.motorola.com/webapp/sps/site/taxonomy.jsp?nodeId=03t3ZGpnLn84498634 Ein 8-Pinner mit 4kB Flash klingt gar nicht schlecht. Peter
Schaut euch mal die PIC-Reihe 18FXX20 an. Ich finde, diese Typen sind durchaus mit den ATMegas vergleichbar.
@Peter: Das mit den fehlenden Interruptprioritäten finde ich nicht so tragisch, meistens gibt es ja im Int. nicht mehr zu tun als z.B. irgendeine Variable zu inkrementieren oder sowas. Und wenn man mal eine Interruptroutine hat die etwas länger ausfällt, dann kann man während dieser die Interrupts mit sei wieder einschalten und damit den anderen den Vortritt lassen. Ob es besonders elegant ist dass das Status-Register nicht automatisch gesichert wird, darüber kann man streiten, ich jedenfalls finde dass 8 Bytes mehr oder weniger wirklich nichts ausmachen. Die HC08 sind zwar interessant, aber leider gibt es immer noch keinen kostenlosen Compiler. Der SDCC für die 8051er scheint auch nicht so berauschend zu sein, wer in C programmieren möchte ohne viel Geld auszugeben wird also wohl um den AVR nicht herumkommen. Andreas
Eine Sache noch, die ich hier vermisse und die ich schon von einigen Leuten hören bzw. lesen konnte, ist der "physikalisch-elektrische" Unterschied zwischen AVRs und PICs, wenn ich es mal so nennen darf. PICs sind elektrisch um einiges robuster und stabiler als AVRs. Das bezieht sich sowohl auf die Robustheit im Bezug auf ESD, als auch auf die Empfindlichkeit gegenüber elektromagnetischen/-statischen Einstreuungen während des Betriebes. Ich habe zwar mit PICs noch nicht viel anfangen können, alledings bei AVRs schon einiges an negativen Erfahrungen mit deren Empfindlichkeit gemacht. Bei AVRs muss man im Bezug auf ESD schon sehr aufpassen, ein schiefer Blick genügt und das Teil ist im Eimer bzw. hat einen Knacks weg. Dies finde ich umso mehr ärgerlich, da es anderen Herstellern wohl keine Mühe bereitet, ihre Produkte durch interne Schutzbeschaltung zumindest so unempfindlich zu machen, dass sie der Ladung eines menschlichen Körpers ziemlich mühelos und unbeschadet widerstehen können. Sowas ist aber sehrwahrscheinlich auch eine Kostenfrage. Desweiteren habe ich die Erfahrung gemacht, dass man, wenn man bei AVRs nicht peinlichst genau auf die Einstellungen der unbeschalteten Ports acht gibt (Pull-ups einschalten!!!), dann spinnen die internen Timer und Zähler herum, dass es eine wahre Freude ist! Hier geschehen wohl im Chip Beeinflussungen, die man sich durch die physikalische Konstruktion des AVRs nicht erklären kann, die aber da sind. Und dann noch eine negative Sache, die mir unlängst auch ziemlich Kopfzerbrechen bereitet hat, ist der Umstand, dass man bei AVRs nie davon ausgehen darf, dass bestimmte Bits in Statusregistern einen bestimmten Wert haben, wenn die betroffene Funktionalität nicht genutzt wird! Dabei kann man böse auf die Nase fallen und sucht Fehler, die man laut Handbuch nicht erklären kann und im AVR Studio auch nicht in Erscheinung treten. Desweiteren hatte ich auch andere seltsame Erscheinungen, die ich bis heute nicht klären konnte und die mir sehr seltsam vorkamen. Ich würde mir wirklich wünschen, dass die AVRs robuster und unempfindlicher gebaut werden, dann macht es nämlich wirklich uneingeschränkt Spass, mit diesen Teilen zu arbeiten. Diese Umstände sollten meiner Meinung nach in einem Umfassenden Vergleich zwischen PICs und AVRs auch erwähnt werden. Vielleicht kann ja jemand, der sich nur oder hauptsächlich mit PICs beschäftigt, auch noch etwas aus seiner Sicht zu dieser Thematik hier beitragen. Frohe Weihnacht, Notker
Hallo Herr Notker, Ihre Erfahrungen im Umgang mit Mikrokontrollern und deren Emfpindlichkeit gegenüber statischer Aufladung oder induktiver Störfelder sind mir vom PIC (wie auch Sie festgestellt haben) und dem 68HC11 nicht bekannt. Ich selbst setzte den PIC zur Steuerung von Motoren (Wasserwerk, 6KVA Generator) ein und habe bei diesen beiden Typen noch nichts derartiges feststellen können. Aber z.B. ein Vergleich von zwei 4049 CMOS Bausteinen (Treiber) von verschiedenen Herstellern zeigte, daß es wohl in dem Herstellungsprozeß erhebliche Unterschiede gibt. Diese sind offenbar so groß, daß ein Auswechseln dieses 4049 zu Problemen führt obwohl beide brandneu waren. Das solche Erkenntnisse nicht im Forum behandelt werden liegt wohl auch daran, daß viele mP Benutzer solche Anwendungen nicht aufbauen sondern sich alles im ohmschen Niederspannungsbereich abspielt. Es ist auch schwer solch eine Störung hinreichend genau zu beschreiben um sie vorstellen zu können. Das setzt doch einen guten Meßgerätepark voraus. Aber ich halte es auch für wichtig darüber zu berichten, denn man muß nicht mehr unbedingt die Ursache in der eigenen Schaltung suchen,sondern kann dann auch mal andere Möglichkeiten erwägen die man sonst vielleicht nicht in Betracht gezogen hätte. Frohes Fest! MfG Manfred Glahe
Auch ich habe beruflich mit PICs und AVRs zu tun. Beide haben Vor- und Nachteile. Aber bezüglich Robustheit ist der PIC den AVRs um Längen voraus! Es kostet erheblich mehr Mühe (und Geld), eine AVR-Schaltung EMV-gerecht zu designen als mit einem PIC. Dieser Umstand ist sogar Atmel bekannt (wenn auch nicht offiziell zugegeben) und man arbeitet schwer an dieser Thematik. Frohe Weihnachten.
Bitte 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.