Hallo,
in Verbindung mit Atmels AVRs wird ja meinst beworben/betont, dass dort
die meisten Befehle in einem Takt ausgeführt werden. Also 4MHz ->
4Millionen Befehle pro Sekunde.
Wie ist das bei den PIC18F? Lt. Datenblatt gibt es eine Menge Befehle,
die auch nur ein Cycle benötigen. Kann ein PIC18F also auch bei 4MHz
auch 4 Millionenen Befehle abarbeiten?
Sind also die PIC18F mit max. 40MHz etwa doppelt so schnell wie die AVRs
mit max. 20MHz? Ich weiss, dass man den Vergleich nicht ganz ziehen
kann, aber mir geht es um das Prinzip.
Steffen.
Immer diese nutzlosen Fragen.
Ich kann 8051 und AVR und wüßte keinerlei Aufgabe, wo ein PIC18F besser
geeignet wäre.
Also werde ich mich nicht mit dem PIC18F beschäftigen.
Wenn Du aber so ein MIPS-Fetischist bist, nimm doch nen Silabs 8051, die
gehen bis 100MIPS (interne PLL = 100MHz).
Peter
Naja,bei der Mehrzahl aller Anwendungen,wo 10-20 MIPS nicht reichen,ist
auch eine 8-BIt ALU nicht mehr ausreichend.Dann ist es egal,wie hoch man
seinen 8-Bitter treibt,es wird nie so gut wie z.B. auf einem ARM oder
gar einem DSP laufen.Häufig gibt´s bei den kleinen Controllern auch
keine Division in Hardware was dann bei komplexen Berechnungen stark ins
Gewicht fällt.
Allerdings kann man mit den AVRs (und meinetwegen auch PICs) schon eine
ganze Menge anfangen.Von der flinken Motorsteuerung über ein
SD-Karteninterface bis zum Webserver ist da schon einiges möglich.Als
Anfänger wird man wahrscheinlich eher ein Problem mit dem "knappen" RAM
haben.
In Details sind die doch sehr unterschiedlich.
Der PIC kann z.B. 2 Moden, einmal einen, der
(explizit) für C gedacht ist.
Daneben gibt es da auch etwas wie eine Totzeit (Bezeichung = ?)
bei der PWM, wenn der eine Kanal abgeschaltet wird,
wird der andere erst nach einer Zeit eingeschaltet -
damit durch Rest-C kein Kurzschluß entstecht.
Atmel hat das nicht bei der PWM - bin mir da aber nicht ganz sicher !
USB haben einige PIC18f.
(Hier ggf. PIC16, und nicht 18:)
Der lineare Addressraum - bzw.
das banking der PIC
Die Verwaltung der Interruptadressen und deren "Lage"
(ATMEL im RAM, PIC separat - und damit deren Anzahl)
Mir scheint es so, dass der PIC18F
entweder per C oder per Assembler programmiert werden
sollte - wegen der Moden haben die Assemblerbefehle sonst andere
Wirkungen.
Preis = ?
Nur ein paar Tipps/Hinweise zu schauen - aber bitte kontrollieren,
PICs habe ich lange nicht mehr angesehen bzw. vertausche ich ggf. PIC16
mit PIC18.
Gruß, c.
@Peter
"Immer diese nutzlosen Fragen."
Dann beantworte sie doch nicht und gehe zum nächsten Post... Ich möchte
das rein aus Interesse wissen.
"Wenn Du aber so ein MIPS-Fetischist bist, nimm doch nen Silabs 8051,
die
gehen bis 100MIPS (interne PLL = 100MHz)."
Ich hab ja nie geschrieben, dass es mir auf die MIPS ankommt. Ich habe
momentan gar kein aktuelles Projekt, an dem ich arbeite.
Die Frage ist aus der Diskussion mit nem Kumpel entstanden. Und ich kann
mir schon vorstellen, dass es Aufgaben gibt, wo man an die Grenzen der
Leistungsfähigkeit kommt. Und da ist es dann doch interessant zu wissen,
ob ich mit nem Controller A der 40MHz kann, wirklich schneller bin als
mit Controller B der "nur" 20MHz kann. Und ja, ich weiss, dass da noch
viele andere Faktoren eine Rolle spielen (angefangen, vom C-Compiler, so
ich einen verwende, bis hin zum konkreten Befehlssatz des Controllers).
Achja, die Frage hat mich auch ein wenig dazu angesp ornt, mal zu
schauen, was denn nun die Geschwindigkeit wirklich beeinflusst und
ausmacht.
@Marco
Danke! Das ist doch mal ein Anhaltspunkt. Vielleicht finde ich ja was im
Datenblatt dazu.
Steffen.
Hallo,
ich hab im Datenblatt zum PIC18Firgendwas die Lösung gefunden, die ich
beim ersten durchblättern übersehen habe:
"One instruction cycle consists of four oscillator periods.
Thus, for an oscillator frequency of 4 MHz, the normal
instruction execution time is 1 μs."
Der PIC scheint 4 Takte zu brauchen, um einen Befehl auszuführen.
Danke für die Unterstützung,
Steffen.
> Der PIC scheint 4 Takte zu brauchen, um einen Befehl auszuführen.
Genau so ist es. Ist übrigens auch bei den 16-Bit von Microchip so und
die werden dieses (blödsinnige) Prinzip sicher noch sehr sehr lange
benutzen.
Katzebuckel wrote:
> Genau so ist es. Ist übrigens auch bei den 16-Bit von Microchip so und> die werden dieses (blödsinnige) Prinzip sicher noch sehr sehr lange> benutzen.
Ich würde das nicht als so "blödsinnig" bezeichnen.
Jeder Befehl besteht ja aus 4 Takten:
- Befehl dekodieren
- Operanden holen
- Operation ausführen
- Ergebnis zurückschreiben
Auch die 1-Clocker machen das so. Der Trick besteht bloß darin, daß sie
Befehle quasi parallel abarbeiten mit einem Zyklus Versatz.
Dabei können dann Probleme auftreten, z.B. waren die ersten AVRs sehr
störempfindlich.
Auch das Pimpen der 8051 von 12 auf 6 oder 4 Zyklen ging relativ
problemlos.
Aber beim Pimpen auf einen Zyklus gabs oftmals kritische Erratasheets.
Ich hab z.B. noch 2 völlig unbrauchbare DS89C420 Samples irgendwo
rumliegen.
Peter
Peter Dannegger wrote:
> Jeder Befehl besteht ja aus 4 Takten:> - Befehl dekodieren> - Operanden holen> - Operation ausführen> - Ergebnis zurückschreiben>> Auch die 1-Clocker machen das so. Der Trick besteht bloß darin, daß sie> Befehle quasi parallel abarbeiten mit einem Zyklus Versatz.
So einfach geht das nicht. Denn damit handelt man sich ja Abhängigkeiten
ein. Wenn man das Ergebnis der vorigen Operation braucht, dann kann man
ja nicht einfach die Operanden holen, bevor nicht der vorige Befehl das
Ergebnis zurückgeschrieben hat. Dann gibts halt einen oder mehrere
Wartezyklen. Ich habe aber noch nie davon gehört, dass es sowas bei den
AVRs geben soll. Das bedeutet dann wohl, dass sie tatsächlich in einem
Takt die Schritte 2-4 ausführen können.
Mir ist allerdings nicht ganz klar, wie das sein kann (interne
Taktvervielfachung?). Oder sie arbeiten direkt auf den Registern?
> Dabei können dann Probleme auftreten, z.B. waren die ersten AVRs sehr> störempfindlich.
Naja, die CPUs im PC sind an der Stelle noch deutlich komplexer und
funktionieren trotzdem zuverlässig.
Markus
Eine andere Frage wäre:
C or Assembler or ... (zB jolt)
Die Effektivität des Compilers + der uC:
als Summe ist interessanter als einzelne MIPS
(spez. bei C, siehe "C-Modus" [heißt der so?] von PIC18F)
Über die Robustheit der Pins
- siehe auch Datenblatt.
- siehe "Internet"
Vergleichen würde ich das Gesamtsystem:
C+uC
Da gibt es irgendwo eine Vergleichsliste im Internet
mit verschiedenen uC, wo = ?
Da wurden auch verschiedene C-Compiler verglichen.
Was bringt ein guter uC, wenn der C-Compiler schlecht ist
bzw. das Assembler nicht das Beste ist ?
Hier möchte ich mal mit einem Mythos aufräumen:
Kein Prozessor führt wirklich eine Instruktion in einem einzigen Takt
aus. Die Verwendung von einer Pipeline führt aber dazu, daß im Idealfall
pro Takt eine Instruktion abgeschlossen werden kann.
Kleiner aber feiner Unterschied.
Wie Du schon richtig bemerkt hast, unterscheidet Microchip Quarz- und
Instruktionszyklen und behaupten dann, daß sie pro Instruktion einen
Zyklus brauchen, obwohl es natürlich 4 Quarzzyklen sind.
Peter Dannegger wrote:
> Immer diese nutzlosen Fragen.>> Ich kann 8051 und AVR und wüßte keinerlei Aufgabe, wo ein PIC18F besser> geeignet wäre.
trotzdem ist es evtl. nicht schlecht seine Architektur kennenzulernen,
alleine schon um seinen Horizont zu erweitern.
> Also werde ich mich nicht mit dem PIC18F beschäftigen.
Verlangt ja auch keiner.
Warum gleich so aufgebracht? Ob du dich jetzt dem PIC- oder dem
AVR-Lager zugehörig fühlst sei mal dahingestellt:
Die Fragen vom Threadersteller waren total begründete objektiv gestellte
Fragen. Wo ist da das Problem? Dieser ewige PIC-AVR-Bandenkriegt widert
mich an.
Markus Kaufmann wrote:
> Peter Dannegger wrote:>> Jeder Befehl besteht ja aus 4 Takten:>> - Befehl dekodieren>> - Operanden holen>> - Operation ausführen>> - Ergebnis zurückschreiben>>>> Auch die 1-Clocker machen das so. Der Trick besteht bloß darin, daß sie>> Befehle quasi parallel abarbeiten mit einem Zyklus Versatz.>> So einfach geht das nicht. Denn damit handelt man sich ja Abhängigkeiten> ein. Wenn man das Ergebnis der vorigen Operation braucht, dann kann man> ja nicht einfach die Operanden holen, bevor nicht der vorige Befehl das> Ergebnis zurückgeschrieben hat. Dann gibts halt einen oder mehrere> Wartezyklen. Ich habe aber noch nie davon gehört, dass es sowas bei den> AVRs geben soll. Das bedeutet dann wohl, dass sie tatsächlich in einem> Takt die Schritte 2-4 ausführen können.>> Mir ist allerdings nicht ganz klar, wie das sein kann (interne> Taktvervielfachung?). Oder sie arbeiten direkt auf den Registern?
Ich glaube, zwischen euch beiden gibts ein Missverständnis. Vielleicht
hilft folgende Skizze:
(Keine Garantie für Richtigkeit. Zu groß ist die Gefahr nachher aufgrund
eines Fehlers geteert und gefedert zu werden. :-))
==================================
_ Erhöhe Program Counter
/
|
| __ Instruction wird ins Instruction Reg.
| / kopiert (nochmals!?) (lt. datenblatt)
| |
| | __ Operand Read
| | /
| | | _ Destination Write
| | | /
| | | |
| | | |
| | | |
+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+
| Q1 | Q2 | Q3 | Q4 | Q1 | Q2 | Q3 | Q4 |
+-------------------+-------------------+
| FETCH | EXECUTE |
+-------------------+-------------------+-------------------+
| FETCH | EXECUTE |
+-------------------+-------------------+-- - -
| FETCH |
+-------------------+--- - -
OSC.:
_ _ _ _ _ _ _ _ _ _ _
/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__/ \__
Quelle: Seite 42 vom PIC18F452-Datenblatt.
http://ww1.microchip.com/downloads/en/DeviceDoc/39564c.pdf
==================================
Viel bleibt zu der Skizze eigentlich nicht zu sagen, ist eigentlich
selbsterklärend.
Die PICs haben eine 2 stufige Pipeline, FETCH und EXECUTE.
Jede dieser Stufen besteht aus vier "Q Cycles": Q1, Q2, Q3, Q4.
Die Q Cycles sind synchron mit dem anliegenden Takt.
Jeder Befehl durchläuft (bzw. "dauert") 8 Q Cycles = 8 Takte.
Nach dem jedoch die ersten vier Q Cycles des nachfolgenden Befehls
zeitgleich mit den letzten vier Q Cycles des vorhergehenden bearbeitet
werden (-> Pipelining), dauert ein Befehl "eigentlich nur" 4 Takte.
(Genaugenommen ist das falsch. Richtigerweise müsste es heißen: Jeder
Befehl dauert 8 Takte, jedoch wird durch die Pipeline alle 4 Takte ein
Befehl "fertig".
Ausnahme: Sprungbefehle zB. Die zerstören die Pipeline. (Siehe Satz
"Abhängigkeiten" von Markus Kaufmann.)
2-stufige Befehle gibts auch, die hab ich mir aber noch nicht näher
angesehen, da kann ich nichts dazu sagen)
Also:
4MHz ====> 1MIPS
4M Takte/Sekunde ====> 1M abgeschlossene Befehle/sek
(wegen den vier Q Cycles)
Obs jetzt bei den AVRs anders/besser/schlechter/whatever ist, weiß ich
nicht. Die kenne ich nur vom Hören-Sagen. Bildungslücke, ich weiß ;/
Tabelle 20-2 zeigt die Anzahl der Takte (also 4x Quarz),
die in Befehl braucht, ;-)
=> MIPS ist immer optimal, ohne Befehle mit 2 or 3 Takte.
Bei abhängigen Sprüngen daher in Klammer weitere Angaben.
Gruß, C.
p.s.: falls der ADU verwendet wird, dann ist der Takt bei
hoher Genauigkeit nicht besonders hoch - wegen Störungen.
(bei AVR und PIC)
p.s.s.:
page 39 zeigt obiges Diagramm
4 MHz bedeutet MAXIMAL 1 MIPS, bei PIC, ;-)
Immerhin haben sie bei manchen von den Pics aus der Not eine Tugend
gemacht, und bieten eine 10Bit-PWM an, die die 4 LSBs über die sonst
"Weggeteilten" Taktzyklen erzeugt.
/Ernst
Ist doch letztendlich egal. Der AVR rennt z. B. mit 20MHz, ein NOP
dauert also 50ns. Ein PIC rennt vielleicht auch mit 20MHz extern wohl
gemerkt, bei dem dauert ein NOP 200ns. Das interessiert den
Programmierer, mehr nicht.
@Manuel Wagesreither:
Ich bezog mich eigenlich auf die "1-Takter", die Peter anspricht, also
z.B. AVR und diverse 8051-Derivate. Denn die müssen ja die 4 Schritte
auch durchführen und zumindest bei den AVRs sind viele Befehle mit einem
Takt angegeben, d.h. die müssen zumindest die Schritte 2-4 wirklich in
einem Takt schaffen.
Markus
@Markus Kaufmann
>auch durchführen und zumindest bei den AVRs sind viele Befehle mit einem>Takt angegeben, d.h. die müssen zumindest die Schritte 2-4 wirklich in>einem Takt schaffen.
Das tun sie auch. Die AVRs haben eine zweistufige Pipeline. Siehe
Datenblatt.
MfG
Falk
Also ich bin auf ARM umgestiegen und voll auf zufrieden damit. Die
Programmierung ist zwar nicht mehr so trivial wie von einem AVR oder
PIC, aber wenn man den Dreh heraußen hat, dann funktionierts tadellos.
Ich würde jetzt mal behaupten, dass ein PIC bessere Peripherie als der
AVR hat. Der PIC18F8722 hat beispielsweise ein externes
Speicherinterface. So etwas zu haben macht schon in gewissen
Applikationen Sinn.
Aber egal wie man es dreht, AVRs haben einfach mehr MIPS!!! Man darf
jedoch nicht vergessen, dass ein PIC mit 40MHz getaktet werden kann und
AVRs jedoch nur mit 20MHz (sollte ich noch am neuesten Stand sein).
Schlussendlich bringt der AVR also nicht 4x so viele MIPS sondern nur
2x.
Thomas P. wrote:
> Ich würde jetzt mal behaupten, dass ein PIC bessere Peripherie als der> AVR hat. Der PIC18F8722 hat beispielsweise ein externes> Speicherinterface. So etwas zu haben macht schon in gewissen> Applikationen Sinn.
Die AVRs wurden als Konkurrenz zum 8051 auf den Markt gebracht und haben
daher auch dessen Businterface geerbt.
Geht natürlich nur zum Datenzugriff, nicht zum Code ausführen.
Einige (ATMega8515, ATMega162) sind auch fast pinkompatibel zum 8051.
Das Businterface ist durch das Adreßmultiplex gut zum direkten Anschluß
von SJA1000 (CAN) oder LAN91C96 (Ethernet) geeignet.
Peter
Hallo,
als ich vor paar Jahren bei den µCs eingestiegen bin , stand ich vor der
Frage: Atmel oder Microchip? Obwohl die Features der beiden doch recht
ähnlich sind, habe ich mich für die PICs entschieden. Das hatte
hauptsächlich 2 Gründe: Zum einen hatte ich mit sprut.de für Anfänger
eine Top-Seite für den Einstieg gefunden, für AVR nichts vergleichbares.
Zum anderen ist die Qualität der Homepage und der Datenblätter von Atmel
im Vergleich zu Microchip echt beschissen. Seitdem bin ich auch bei den
PICs geblieben.
Wie man sieht, sind MIPS, Leistung, etc. eher nebensächlich. Die
Benutzerfreundlichkeit, sprich Programmierung, Einstiegshilfen,
Entwicklungsumgebung sind die entscheidenden Faktoren, und da liegt
Microchip meines Erachtens vorne, obwohl das bei der Leistungfähigkeit
nicht unbedingt der Fall ist.
Gruß Stampede
@ Stampede
>Zum anderen ist die Qualität der Homepage und der Datenblätter von Atmel>im Vergleich zu Microchip echt beschissen.
???
>Wie man sieht, sind MIPS, Leistung, etc. eher nebensächlich. Die
???
Du bist sicher Windows Vista Fan? Ist ja auch sehr sinnvoll, für bissel
Word, Excel und Solitär min. 1 GB RAM und ne 3D Karte im Rechner zu
haben. Ressourcenverschwendung bis zum Gehtnichtmehr!
>Benutzerfreundlichkeit, sprich Programmierung, Einstiegshilfen,>Entwicklungsumgebung sind die entscheidenden Faktoren, und da liegt
Es sind AUCH Faktoren, je nach Bewertung wichtig bis sehr wichtig. Aber
wer die Leistung der Hardware mal einfach als Nebensächlichkeit abtut
(gerade bei solchen kleine uCs), der hat . . ., naja, sollte vielleicht
nochmal über das Thema nachdenken.
>Microchip meines Erachtens vorne
Was ist bei Atmel so schlecht?
AVR Studio ist gut, auch wenn hin und wieder ein paar Service Packs
gebraucht werden (welche Software braucht das heute nicht?)
WINAVR ist auch super
Die Doku ist gut
Die Hardware erst recht
Wo ist das Problem?
MFG
Falk
> Viele PICs aus der 18F Serie haben eingebauten 4x PLL und fuehren damit> eine Instruktion per Aussenzyklus aus. Nur Sprungbefehle brauchen 2> Cyklen.
Die interne PLL hat nur den Vorteil, dass man extern nicht mit 40MHz auf
den µC gehen muß. Nutzt man die PLL, sind extern max. 10MHz machbar,
wenn man den Controller nicht außerhalb seiner Spezifikation betreiben
will.
Naja ansonsten finde ich, dass sowohl MPLAB mit seiner Möglichkeit, den
C18 und C30 zu integrieren, als auch AVR Studio mit der Möglichkeit,
avr-gcc einzubinden, sehr leistungsfähige Tools sind. Die Datenblätter
beider Hersteller sind gut und manch anderer z. B. Philips (jetzt NXP)
oder Renesas kann sich da eine Scheibe abschneiden.
Einzig negativ ist mir bei Microchip aufgefallen, dass die Produkte auf
den Markt werfen, die funktionstechnisch doch extrem grenzwertig sind.
Sowohl bei Microcontrollern als auch anderen Bausteinen (z. B. ENC28J60)
funktionieren Teile einfach nicht und als Anwender sitzt man da wie ein
Ochs vor dem Berg.
Jetzt wo ich das schreibe, fällt mir gerade der ATmega169 mit seinem
integrierten LCD-Controller ein. Bei dem war auch einiges ziemlich übel.
@Falk:
Du hast nicht verstanden, was ich sagen wollte. Ich schrieb: "Beide sind
sich, was die Features anbelangt, ähnlich." Die beiden 8-Bit-RISC's sind
ähnlich schnell oder langsam, je nach Takt. Was ich sagen wollte: Wenn
man also über den Einstieg nachdenkt, ist bei ähnlicher Leistung
(10-12MIPS, für mehr sollte man eh 16 oder 32-Bit Architekturen nehmen)
die einfache Bedienung und der reibungslose Einstieg wichtiger. Und da
ist m.E., Microchip besser. Mit "da" meine ich Dokumente,
Einstiegshilfen, web, Entwicklungsumgebung, etc. Ich denke das habe ich
aber in meinem vorherigen Beitrag unmisverständlich deutlich gemacht.
Das heißt nicht, dass ich Atmel's Produkte schlecht machen will, die
haben definitiv auch ihre Vorteile.
Btw: mit Vista hab ich nix am Hut... und für Solitär hab ich sogar 2GB
RAM und 2GB Auslagerungsdatei reserviert!
Hallo,
ich möchte hier keine Grundsatzdiskussion anfangen, ich wollte nur
erkären WARUM ich mich für PICs entschieden habe.
Ich habe mich im Internet zunächst über die Kontroller schlau gemacht,
ich war vor Allem auf der Suche nach einer Seite, die mir einen leichten
Einstieg bietet. Da bin auf www.sprut.de gestoßen, wirklich DIE Seite
was PIC anbelangt. Eine ähnlich gute Seite, die sich mit AVR
auseinandersetzt, habe ich leider nicht finden können.
Auf der Homepage von Microchip sind Sachen wie "Getting Started" oder
Features der Produkte besser zu finden bzw. direkt auf der Startseite
dargestellt, man erspart sich nerviges Suchen.
Dann sind die Datenblätter von Microchip wirklich besser. Ein Beispiel:
Ich hatte eine AVR-Schaltung gefunden, die den ADC benutzt. Daher wollte
ich wissen, welche Impedanz die zu messende Größe haben sollte, damit
der ADC ordentlich funktioniert. Auch nach langer Suche bin ich da bei
Atmel weder im Datenblatt oder auf der Homepage fündig geworden. Zudem
haben die meisten Atmel-pdfs keine Lesezeichen, und sind optisch einfach
nicht so gut unterlegt wie Microchip das macht.
Das sind zwar keine technischen Vor- oder Nachteile, jedoch machen sie
die Arbeit deutlich angenehmer. Was die Erratas der AVR's anbelangt, bin
ich nicht im Bilde. Da erlaubt sich Microchip schon mal den ein oder
anderen Schnitzer.
Zudem hat Elektor die MPLAB IDE von Microchip als beste
Entwicklungsumgebung bezeichnet, das ist natürlich nicht verbindlich,
aber zumindest ein Indiz.
Ich habe immer das Gefühl, dass die AVRler sich gleich angegriffen
fühlen, wenn man was gegen ihre Kontroller sagt. Vielleicht war ich
anfänglcih bisschen hart mit der Kritik. Aber ich nie gesagt, dass
"Microchip so viel besser ist".
Mir ging es ausschließlich darum, meine Beweggründe für die Entscheidung
für die PICs darzustellen.
Grüße Stampede
Stampede wrote:
> Zudem hat Elektor die MPLAB IDE von Microchip als beste> Entwicklungsumgebung bezeichnet, das ist natürlich nicht verbindlich,> aber zumindest ein Indiz.
Wenn ich mir die Abstürtze des MPLAB anseh wenn den ICD2 abzieht und
wieder ansteckt und die MPLAB nicht neu startet ohne anschliessenden neu
starte der IDE. Dann stürtzt die IDE kommentarlos ab. Oder es dürfen
keinen Leerzeichen im Ordnernahme sein.
Bei Microchip sind auf jeden Fall die Application Notes besser und
umfangreicher als die bei Atmel.
Ich habe zwar noch keine PICs programmiert, aber bei den ANs schon
einige interessante Dokumente gefunden (z.B. der 3-Phasen
Frequenzumrichter), die auch für nicht PICler interessant sind.
