www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PIC oder AVR Microcontroller - Unterschiede?


Autor: Holger Schumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Holger Schumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: thkaiser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PIC heißt programmable interrupt controller

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Gäbel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger Schumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Holger Schumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Stichpunkte zu PICs und AVRs:
http://www.mikrocontroller.net/articles/controller...

@Peter: Möchtest du vielleicht eine ähnliche Auflistung für den 8051 
machen?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Ein 8-Pinner mit 4kB Flash klingt gar nicht schlecht.


Peter

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut euch mal die PIC-Reihe 18FXX20 an.
Ich finde, diese Typen sind durchaus mit den ATMegas vergleichbar.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Notker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jangomat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.