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.
@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.
