µC Speed

Eine derartige Liste kenn ich auch nicht, aber es gibt ein paar bekannte 
Werte wieviele Takte Pro Befehl benötigt werden.
AVR braucht für die meisten Befehle 1 Takt, Ein paar wenige 2, 3 oder 4.
Die PIC Familie benötigt für die schnellsten Befehle soweit ich weiß 3 
Takte. Ob es mittlerweile schnellere gibt weiß ich nicht.
Und bei 8051 wirds kompliziert. Der Ur 8051 brauchte glaub ich 12 oder 
sogar 24 Takte pro Befehl, einige neue Nachbauten brauchen 4 Takte und 
ein paar total aufgebohrte brauchen sogar nur noch 1 Takt für die 
schnellsten Befehle. Allerdings hat sich am Flaschenhals "Akku-Register" 
soweit ich weiß bis heute nichts geändert.

Hoffe das war erstmal hilfreich
Markus

Ein Instruction-Cycle bei allen PIC´s ist genau 4 Takte lang. Also 4MHZ 
= 1MIPs.
MfG

Quatsch, der PIC hat auch nur 1 und 2 Cycle Commands

35 Intructions:
davon 5 mit 2 Cycles
und   4 mit 1 oder 2 Cycles  (conditional branches)
der Rest ist 1 Cycle


MooseC

Vorsicht! Die Pic's haben einen Vorteiler von 4. D.h. pro Cyclus 4 
Quarztakte -> 1 Befehlszyklus. 1NOP bei 4MHz -> 1µs

Der Ur-8051 hat einen Vorteiler von 12 - 12 Quarztakte -> 1 
Befehlszyklus. 1 NOP bei 12 MHz -> 1µs

Will nicht Klugscheißen, aber das darf man nicht durcheinanderbringen...

Erst einmal vielen Dank für die schnellen Antworten.

@Peter: Ich kenne bisher nur den AVR. Dort ist der Befehlssatz soweit 
vereinfacht, daß nahezu jeder Befehl einen Zyklus braucht. Wenn ich das 
beim 8051 richtig verstanden habe, gibt es da Befehle, die im Vergleich 
zum AVR einige Dinge zusammenfassen - wie Dein Beispiel zeigt.
Da in Deinem Beispiel beide CPUs das gleiche tun, jedoch nur anders 
gesagt bekommen, aber für die gleiche Arbeit genau gleiche Zyklenzahl 
benötigen, dann sind sie doch auch gleich schnell, oder? Mal angenommen, 
ich würde einen AVR auch auf 75MHz takten, dann wäre er doch genau so 
schnell, wie der 8051.
Wenn ich einen AVR in einer Hochsprache (z.B. C) programmiere, scheint 
er bei einigen Befehlen auch langsamer zu sein, weil er scheinbar mehr 
Zyklen benötigt. Doch in Wahrheit wird dieser eine Befehl nur in mehrere 
aufgeteilt, damit die CPU mit ihrem begranzten Befehlssatz das auch 
versteht.

Oder habe ich das alles falsch verstanden?

Also, hab grad nochmal ein Datenblatt durchstöbert. Da steht zwar drin 
das die Befehle einen oder zwei Zyklen brauchen, aber trotzdem ist er 
nur mit 10 MIPS bei 40 MHz angegeben. Es stimmt also was Ralf 
geschrieben hat.
Generell ist der Geschwindigkeitsvergleich zwischen den MCU's ne 
Milchmädchenrechnung und man kann sich nur grob orientieren.
Die Rechnung von Peter weiter oben müsste stimmen, aber ein Programm 
besteht ja nunmal nicht nur aus CJNE Befehlen.
Generell würde ich aber trotzdem sagen das die AVR bei gleichem Takt die 
schnellsten 8 Bitter sind, ist aber ne rein subjektive Meinung und 
stützt sich nur zum Teil auf praktische Erfahrung

@Ralf:
Das scheint mir doch eine recht wichtige Info zu sein. Warum auch immer 
dieser Vorteiler bei einigen CPUs existiert, wichtig ist doch, was am 
Ende bei der CPU ankommt. Und da scheint es im Vergleich "Input/Output" 
doch so zu sein, daß bei 4MHz ein AVR 4 Zyklen und ein PIC nur einen 
verarbeitet. Somit ist ein AVR schneller als ein gleich getakteter PIC. 
Oder?

Wie ist das denn nun konkret beim 80320 @ 24MHz? Habe da 'ne Applikation 
gesehen und würde das gerne mit AVR machen, um nicht noch eine Sprache 
zu lernen und 'nen Programmer zu kaufen.
Angenommen der 80320 hat auch 'nen Vorteiler, dann könnte das doch auch 
ein AVR schaffen?

Also ich denke wenn das ein 80320 mit 24MHz schafft dann schafft das ein 
AVR mit 16MHz locker. Der 80320 hat soweit ich weiß noch einen /4 
Vorteiler, hat also sozusagen nur 6MHz (jaja, ich weiß. stimmt nicht 
exakt. nich hauen ;)

Hi

zum Vorteiler:
Der ist nötig da bei der 8051er Architektur nicht alles mit einem Takt 
gemacht werden kann. Beim 1sten Takt schreibt er die Low-Adresse auf den 
Bus, beim 2. legt er die Daten an usw. So das sich eben beim Ur 51er 12 
Takte pro Maschinenzyklus ergeben. Der AVR macht das auch nicht alles in 
einem Takt. Jeder Befehl braucht dort eigentlich zwei Takte. Aber da er 
aber eine sog. Instruction-Prefetch Einheit hat holt er sich bereits 
beim Ausführen eines Befehls den nächsten. Bei Sprungbefehlen kann das 
aber nicht klappen. Deshalb brauchen Sprungbefehle immer 2 Zyklen. 
Bedingte Sprünge brauchen aus obigem Grund 1 Zyklus wenn nicht 
gesprungen wird und 2 Zyklen wenn gesprungen wird.

80320 vs. AVR:
Das kann man so nicht sagen. Wenn der 80320 ne Menge mit Bitvariablen 
macht wird der AVR Mühe haben da mitzukommen da er vieles über das 
ausmaskieren von Bits machen muß wo der MCS51-Kern des 80320 spezielle 
Befehle dafür hat. Macht der 80320 aber ne Menge Arithmetik und hantiert 
mit long-Zahlen dann dürft der AVR deutlich schneller sein.
Wie Peter geschrieben hat:
"Ein echter Vergleich ist daher nur anhand der gewünschten Anwendung 
möglich."

Matthias

Jetzt bin ich neugierig. Was sind das denn für spezielle Befehle beim 
8051?

@Markus

Es ging mit auch gar nicht um die Quarzfrequenz, die ist ohnehin nur von 
geringer Bedeutung, aus schon hier mehrfach beschriebenen Gründen, 
sondern um die Richtigstellung, das der PIC keine 3 Takte braucht.

Natürlich ist der AVR mit 16MHz schneller als ein PIC18 mit 40MHz, aber 
es ging mir ja auch gar nicht um den Vorteiler.
Entscheidend ist für die Ausführungszeit eh die Befehlszykluszeit und 
die Architektur der CPU.

Peter hat es mit den MIPS schön getroffen...

Kommt eben immer darauf an wofür der Controller eingesetzt wird.

MooseC

Ok. Vielen Dank!

Ich wollte den Vergleich allgemein halten, um ihn auch später noch 
anwenden zu können. Das ist aber wohl so pauschal nicht möglich. Also 
werde ich konkret:

Mein Laptop hat keine Midi-Schnittstelle. Die brauche ich aber für den 
mobilen (Service)-Einsatz. Bei Elektor habe ich ein Interface gefunden, 
das mit einem Treiber von Yamaha den COM-Port umwandelt zu MIDI.
Da ich dieses Feature evtl. auch später noch in anderen Projekten 
einsetzen möchte, würde ich das gerne auf 'nem AVR realisieren (wegen 
bekannter Sprache, vorhandenem Programmer etc.).
Alles, was ich bisher gesehen habe, wo es um Interfaces geht 
(RS232-MIDI, MIDI-DMX) wurde kein AVR eingesetzt. Mitlerweile gibt es 
aber auch schon AVRs mit 2 seriellen Schnittstellen, so daß das von der 
Hardware ein leichtes wäre.

Wäre nett, wenn sich das Programm mal einer ansehen könnte, der sowohl 
80320 als auch AVR kennt und seinen Kommentar abgeben könnte, ob das 
konvertierbar ist. Das Listing findet Ihr auf www.elektor.de unter 
Downloads Heft Mai2001, Projekt RS232-nach-Midi-Interface, Software 
(leider direkter Link nicht möglich).

Besten Dank

Hi

Bitbefehle des 8051:
Der 8051 kann direkt 256 Bits addresieren. Diese liegen haben im Prinzip 
einen eigenen Adressraum. 128 Bits davon liegen im internen RAM IIRC von 
Adresse 0x20 bis 0x2F. Der Rest liegt im SFR-Bereich. D.h. du kannst 
entweder Bit oder Bytewide auf den selben Speicher zugreifen. Das ist 
bei Bitgefummel schonmal sehr effektiv.
Dann kann er mit jedem dieser Bits
Set Bit
Clear Bit
Complement Bit
And with Carry
Or with Carry
Mov to Carry
Mov from Carry
Jump if
Jump if not

Das macht Bitgefummel einfach effektiver als auf dem AVR. Auch kann der 
8051 viele Befehle direkt auf dem kompletten internen Speicher 
ausführen. Auf dem AVR sieht das Drehen eines Bits an einem Port-Bit 
irgendwie so aus:
IN temp1,PINB
LDI temp2,0x01
EOR temp1,temp2
OUT PORTB,temp1

auf dem 51er dafür
CPL P2_1

Zum RS232->MIDI
Das geht auf jeden Fall mit dem AVR. Die serielle Schnittstelle liefert 
die Daten lange nicht so schnell wie sie der aVR verarbeiten kann.

Matthias

@ MooseChecker: naja, ganz uninteressant ist die Taktfrequenz auch 
nicht. Zum einen steigt die Leistungsaufnahme mit der Taktfrequenz, zum 
zweiten steigt die Empfindlichkeit der Schaltung und zum dritten steigt 
mit jedem Mhz auch die Produktion von Störstrahlung (Stichwort EMV).
Ein Lochrasteraufbau bei 16MHz ist noch relativ problemlos, bei 40 oder 
mehr kann es schon schwierig werden. Da kann jeder cm Leitung, jede 
Lötstelle und jeder Steckkontakt zur Fehlerquelle werden

@Gralf: wenn Du 2 UARTS brauchst empfehle ich den ATmega162. Der sollte 
die Anwendung "auf einer Arschbacke" schaffen ;)
Also genug Speicher, genug Leistung, genug Reserven

@gralf
Die Schaltung ist ja nichts anderes als ein simple 
Baudratenkonvertierung 31250 (MIDI) <--> 38400 (PC) mit Software FiFo 
und Option Hardware Handshake. Läßt sich mit nahezu beliebigem µc lösen. 
Wenn man die Software möglichst einfach gestalten will, sollte diese 
über 2 Hardware UART verfügen. Beim AVR kommen da MEGA 128/162 oder 162 
in Betracht. Als Taktfrequenz sollten dann 8 MHz vorgesehen werden, um 
den Fehler bei beiden Baudraten möglichst gering zu halten. 16 MHz geht 
zwar auch, ist aber hier absolut nicht notwendig, da für die reine 
Rechnerei wohl schon 1-2 MHz reichen würden.

@Mathias: Ok, da scheint es einige Unterschiede zu geben. Aber der AVR 
hat auch einige Bit Befehle, einschließlich Compare/JMP und sowas.
Dein Beispiel versteh ich aber nicht ganz. Wieso liest Du einen Wert aus 
PinB aus und schreibst ihn in PortB? Was willst du damit erreichen?

Hi

klar hat der AVR auch ein paar Bitbefehle. Die sind aber eben nicht ganz 
so mächtig.

Mit dem Beispiel wollte ich dich verwirren. Nein. Spaß beiseite. Ist 
einfach ein Fipptehler. Sollte natürlich heißen:
IN temp1,PORTB
LDI temp2,0x01
EOR temp1,temp2
OUT PORTB,temp1


Matthias

Aha, so macht das schon mehr Sinn, aber auch nicht. Man kann ohne 
weiteres einzelne Bits direkt in PortB setzen/löschen

Die ganze Diskussion ist realtiv müssig, jede Prozessorfamilie hat ihre 
Vor- und Nachteile, einen direkten Bit-Toggle Befehl für die I/O Ports 
kennt der AVR zwar nicht (Anwendung eher selten) dafür aber direkte Bit 
Set/Reset Befehle. Toggle lässt sich aber auch einfach so realieren, 
zwar mehr Clock-Zyklen aber dafür keine Registernutzung:
        sbis    PINB,0
        rjmp    PC + 3
        cbi     PORTB,0
        rjmp    PC + 2
        sbi     PORTB,0

Hi,

müsste man nicht, um zwei Prozessoren zu vergleichen, ein 
Benchmark-Programm laufen lassen (das Programm kann ja durchaus an die 
jeweiligen Features der Archtektur angepasst sein) ??

Im Prinzip müsste man sich ne Anwendung suchen (Primzahlen berechen für 
Numerik, Memory-Schreiben für I/O etc.) und die laufen lassen ...

Gruß

UBoot-Stocki

Da ganze Diskussion geht wohl in die falsche Richtung, Benchmarks für 
Mikrocontroller sind schlichtweg gesagt ein Witz und dienen wohl eher 
der Befriedigung irgendwelcher Werbestrategen in den 
Marketingabteilungen. Die Frage sollte vielmehr laut, kann der Prozessor 
x die von mir gestellte Aufgabe lösen und passt er in meinen 
Preisrahmen. Wenn ich diese Frage mit ja beantworten kann hat sich das 
Thema erledigt, ansonsten muß ich nach einem besser geeigneten 
Controller Ausschau halten. Was nützt der "beste" Controller wenn dieser 
90% seiner Zeit mit "nichtstun" beschäftigt ist und außerdem viel zu 
teuer da völlig überdimensioniert.

@Markus
Das ist doch schon wieder eine Fehlinfo.

>>Ein Lochrasteraufbau bei 16MHz ist noch relativ problemlos, bei 40 oder mehr 
kann es schon schwierig werden. Da kann jeder cm Leitung, jede Lötstelle und jeder 
Steckkontakt zur Fehlerquelle werden

Der PIC hat einen 10MHz Quarz und eine x4 PLL intern. Erzeugt so 40MHz 
und teilt sie wieder durch 4 um dann auch seine eigentliche Cyclespeed 
zu kommen. Die 40MHz sind intern, davon merks Du außen gar nichts und 
hast auch kein Problem mit der EMV. Was die Empfindlichkeit betrifft, 
stimmt das auch nicht, da das System für sich gekapselt ist. Die PICs 
laufen sehr sicher, wir haben schon tausende in unseren Geräten verbaut 
und haben NULL Probleme mit der Funktion.
Und mit EMV haben wir auch überhaupt keine Probleme, bei den Messunungen 
wird schonmal gefragt, ob die Geräte nur eine Attrappe seien

Irgendwie ja komisch da ich hier den PIC verteidigen muß...


MooseC

@MooseC: sorry, verteidigen mußt du ihn nicht. Da bin ich wohl einer 
Fehlinfo unterlegen. Für mich heißt 40 MHz das auch ein 40MHz Quarz 
angeschlossen ist. Ich behaupte sicher auch nicht das die PIC schlechte 
Controller sind. Ich bin nur der Meinung das die AVR für den 
Hobbyanwender der geeignetste Controller ist. Die Verfügbare Palette ist 
übersichtlicher, die Leistung ist mehr als ausreichend und die 
Handhabung ist recht einfach. Als ich vor ein paar Jahren nach einem für 
mich passenden µC gesucht habe hab ich mir neben AVR und PIC auch 8051 
und 68HC11 näher angeschaut und beim PIC hat mich einfach die 
unübersichtliche Produktvielfalt gestört. Irgendwie hab ich nie den 
passenden Controller gefunden. Außerdem hat mich die geringere Leistung, 
die kleinen Speicher, die damals meist verwendete Speicherwortbreite von 
12/14 Bit und das gewöhnungsbedürftige Speichermanagement gestört.
Die AVR haben mich einfach von Anfang an überzeugt und ich bin bisher 
auch noch nicht wirklich entäuscht worden.

Aber um das nochmal zusammenzufassen: es ist meist relativ egal welchen 
µC man wählt da die meisten irgendwo ihre Vorzüge haben. Ein 
Leistungsvergleich (was ja das ursprüngliche Thema war) ist müßig und 
eigentlich auch völlig überflüssig. Die Wahl, welchen µC man wählt hängt 
eigentlich nur von zwei Faktoren ab:
1. Von den persönlichen Vorlieben bzw von der persönlichen Einstellung
2. Von der Applikation

Meine Meinung zu 1. habe ich denke ich schon oft genug kundgetan und zu 
2. kann ich sagen, das ich bisher noch keine Applikation hatte für die 
ich nicht einen AVR einsetzen konnte

Jetzt wünsche ich erstmal ein schönes Wochenende
Gruß
Markus

@Markus
Kann es sein das Du glaubst ich würde den PIC propagieren?
Es ging lediglich um die korrekte Darstellung nicht um Vorlieben.

Allmählich solltest auch Du wissen wer hier im Forum welchen Controller 
einsetzt, beziehungsweise welche Architektur bevorzieht. Ebenso die 
Ansichten der einzelnen Leute hier ist hinlänglich bekannt. Somit habe 
ich auch keine Lust immer wieder meinen Standpunkt darzulegen, wobei das 
auch nur temporär wäre, da ich mich immer gerne nach anderen Controllern 
umsehe und nicht festgelegt bin und auch nicht sein will.

MooseC

Weiter oben habe ich gelernt, daß man den Befehl
"CJNE @Ri, wert, label"
auf einem AVR wie folgt programmiert:

LD r16,X
CPI r16, wert
BRNE label

Vom 68k-Controller kommend möchte ich gerne den superschnellen 75MHz 
Cygnal 51er einsetzen und brauche eine Lösung, wie ich den Befehl

LEA.L   $02(A6,D0.L),A3

entsprechend formuliere; er braucht nur wenige Taktzyklen.

Das müßte doch ganz einfach sein, schließlich ist der 8051 ja 
Industriestandard. Wieviel Taktzyklen braucht der 51er, hundert oder 
noch mehr ?

@Mikki, Markus, Matthias
Danke für Eure Einschätzung. Werde dann wohl mal bei Gelegenheit die 
Schaltung umsetzen.

@MooseChecker
Wie bitte? Der externe Takt wird intern im PIC vervierfacht und dann 
wieder geteilt? Dann gibt es ja im Endeffekt doch ein Verhältnis von 1:1 
von Quarztakt zu Zyklus. Wie beim AVR. Was dazwischen passiert ist doch 
eigentlich egal.

Hi

nicht ganz egal. Der PIC braucht halt die 4 Takte pro Maschinenzyklus 
(das ist jetzt keine Kritik so ist halt die Architektur des PIC). Die 3 
zusätzlichen Takte werden nicht einfach weggeschmissen.

Matthias

Das mit der PLL-Taktmultiplikation und anschließenden Division wird 
gemacht, um

1. ein Taktsignal mit einem Tastverhältniss von genau 50%   zuerhalten, 
und um

2. einen höheren internen CPU-Clock zuerhalten, als der  angeschlossene 
Quarz direkt liefern kann.


Bei meiner MCU(XC161) verwende ich einen 8MHz Quarz. Die PPL jubelt 
diese Frequenz auf über 100MHz hoch, um dann durch Teilung den 
40MHz-CPU-Clock zuerzeugen.

Die Instructionzykluszeit ist somit 25nSek.

@Michael
Wenn Du von dem 68k kommst, warum bleibst du dann nicht bei den 
16/32Bittern? Sieh Dir doch mal die M16er von Renesas (einst Mitsubishi) 
an. Die sind dem 68k so ähnlich, das man meinen könnte, die hätten 
kräftig geklaut. Ist wie Nachhause kommen, wenn man den 68k kennt.
Der ist mit dem M16C80 bei ca. 17 Euro und 20MHz ein CISC Arbeitspferd. 
256k Flash, 20k SRAM, 5xUARTs/SPI/I2C, 11x16Bit Timer, 8x10BitADC, 
2x8BitDAC, integrierter Bootloader und und und...

MooseC

@MooseC
Danke für Deinen Tipp. Ich setze bereits den H8S/2394 ein; die M16er 
sind auch eine feine Sache.

Meine 'Frage' war eine Überspitzung: wie übertrage ich ein 8051 
Programm, ohne mich mit der Struktur des anderen Prozessors 
auseinanderzusetzen. Folglich ist es kein Wunder, daß bei soviel 
Ignoranz der andere Prozessor - welcher auch immer - als der schlechtere 
da steht, wie es dann auch noch genau vorgerechnet wird.

die Ironie hätte mir eigentlich bei der Frage nach den Taktzyklen 
auffallen müssen.
Dann bist Du ja schon bestens versorgt.

Ich werde mir die Hitachis/Renesas wohl auch noch einmal ansehen, das 
hatte ich zwar vor ein paar Jahren schon getan, aber die Kreterien 
ändern sich ja auch - also auch danke für den Tip.

Wie ist es denn mit den Tools und Environments der H8 bestellt? Gibt's 
die Tools mittlerweile for free?

MooseC

@MooseC

Einen GNU-CC-Compiler mit allem Zubehör gab es schon immer; ich verwende 
meist die Version 98R2 o.ä.. Die gab es auf der Hitachi CD von 1999 und 
erzeugt guten Code. Die CD läßt sich bei Bedarf auch kopieren. Gibt zwar 
auch neuere Versionen, aber die sind mir zu 'windows-haft'.

Für den MC16 gib es das glaube ich nicht (?). Beim Prozessor verwende 
ich immer externes Flash-EPROM+RAM wegen benötigter Akkupufferung und 
Platzbedarfs. Soweit.

GCC für M16? weiß ich nicht, wozu auch gibt ja den NC30 und NC308. Und 
als Oberfläche den Toolmanager. Aber der Compiler läuft im Dos-Fenster 
und kann auch ganz normal in Batchfiles oder vom Editor(z.B. CodeWrite) 
aus mit dem Makefile aufgerufen werden. Je nach Vorliebe.
Der Toolmanager vereint zudem noch den Debugger und ein paar andere 
nette Dinge wie den Stackviewer. Läßt sich aber auch ohne TM nutzen.

Auf der CD von Hitachi ist der Compiler drauf? Dann werde ich mal bei 
SASCO anfragen...

MooseC

@MooseC

Der GNU-C-Compiler befindet sich letztmalig auf der CD Sept/2001 (99r1, 
ca. 95MB). Wohl aus Platzgründen fehlt das Verzeichnis 'tools' auf der 
CD 11/2002. Unter www.kpit.com gibt es eine für die H8-Familie 
optimierte Version des GCC (ca. 25MB).

Den MC16/80 hatte ich vor längerer Zeit getestet zusammen mit KNC308... 
Die 3-Monatstestfrist ist lange vorbei. Mit GCC bin ich vertrauter.
Wenn es die H8S nicht geben würde, wäre ich wohl bei MC16/32 gelandet. 
Vielleicht bringt uns der neue Firmenverbund auch verbesserte 
Prozessoren.

Nachtrag: ich hätte heute zuerst den realen Briefkasten auf Inhalt 
prüfen sollen. Renesas plant einen H8SX mit dem von mir schon immer 
vermissten VBR (vector base register)und einigen Erweiterungen.