Sehe ich fast genauso. Hab selbst mit Pics angefangen und mache jetzt mehr
mit Atmels als mit den Pics.
Vorteil bei den Atmels ist, dass die CPU mit vollem Quarztakt läuft, während
bei den PICs fast immer noch ein Vorteiler 1:4 davor sitzt.
Was ich bei den Atmels auch schön finde, ist dass man in C Interrupts etwas
einfacher einhängen kann und dass einem der Compiler schon das ganze 0-Init
der Variablen abnimmt, wie man es beim Programmieren auf dem PC gewohnt ist.
Der PIC hat dafür manchmal die etwas geschicktere oder üppigere Hardware-Implementierung von Peripherie onboard.
Ausserdem schickt Microchip einem gerne kostenlose Samples zu, wenn man
sich einigermassen professionell gibt

Einen (für mich) Super-Vorteil haben die Atmels noch: Selbst ein Attiny2313
für 95 ct. kann per reiner Software-Implementierung zu einem USB-Low-Speed
Device werden. Man braucht dann keinen zus. Chip für das USB-Protokoll.

Gruß
Stefan






_________________
Alle sagten: Das geht nicht. Dann kam einer, der wusste das nicht und hat´s gemacht.

Zitat : Nukeman hat am 14 Jan 2009 01:09 geschrieben :

Einen (für mich) Super-Vorteil haben die Atmels noch: Selbst ein Attiny2313 für 95 ct. kann per reiner Software-Implementierung zu einem USB-Low-Speed Device werden. Man braucht dann keinen zus. Chip für das USB-Protokoll.

Offtopic :

An dieser Software wäre ich mal interessiert... Gibt's das als open source? beste Grüße hajo

_________________
Interpunktion und Orthographie dieses Beitrags sind frei erfunden.
Eine Übereinstimmung mit aktuellen oder ehemaligen Regeln wäre rein zufällig und ist nicht beabsichtigt.
Wer einen Fehler findet, darf ihn behalten!

Ich hingegen benutze eher PIC, da ich die Atmels nirgens herkriege. Interessanterweise sind die in Deutschland leichter zu bekommen als hier in Italien.

@Nukeman: Da sitzt kein 1:4 Vorteiler im PIC drin der diesen langsamer macht. Der PIC braucht nur vier Taktschläge um einen Befehl auszuführen (1. Befehl dekodieren, 2. eventuell Operanden aus Datenspeicher laden, 3. Befehl ausführen, 4. eventuell Ergebnisin Datenspeicher zurückschreiben).
Genauer gesagt braucht der PIC zwei mal vier Taktschläge, im aktuellen Befehlszyklus wird der aktuelle Befehl ausgeführt und gleichzeitig der Nächste bereits "geladen". Deshalb braucht ein Sprungbefehl auf zwei Befehlszyklen zur Ausführung, da eben der Befehl am neuen "Program Counter" nicht im voraus geladen werden kann. Das hier sage ich über die Serie 16Fxxxx, von der weiß ichs, von neueren nicht mehr so genau).

Beim Atmel glaub ich, dass die vier Abläufe um einen Befehl auszuführen parallel ablaufen. Sprich: Wenn ein Befehl im vierten Abschnitt steckt und gerade Ergebnisse zurückgeschrieben werden ist der nächste Befehl bereits beim Ausführen, der übernächste lädt bereits die Daten und der überübernächste Befehl wird bereits dekodiert. Aber so genau weiß ich das nicht. Am besten Jornbyte oder sonstjemand, der sich mit Atmels besser auskennt, fragen.

Grüße
Simon

edit: Rechtschreibfehler

[ Diese Nachricht wurde geändert von: wulf am 14 Jan 2009  9:05 ]

Also ist es grundsätzlich egal welchen mann nimt. Ich mach dann einfach mal mit Pic weiter. da ich das zeug habe. Danke!

Danke wulf für die Erläuterungen zum Pic/Atmel-Pipelining. Für den User ist es
im Effekt aber wohl so, das ein PIC auf 12Mhz max. 3Mips schaffen kann, während
der Atmel auf 12MHz max. 12 Mips packen kann.

Hajos, hier der Link zu dem Firmware-Only USB, es ist anscheinend ein
österreichisches OpenSource-Projekt. Natürlich zieht die Implementierung
einiges an Prozessor-Performance weg und ich glaube die USB-Spec wird nicht
überall 100% eingehalten. Ich habe aber schon mehrere kleine Projekte damit
gemacht und die laufen bislang völlig ohne Probleme.

Hier das Basis-Projekt ( einfache I/O mit einem 2313 )
http://www.obdev.at/products/avrusb/powerswitch.html

Auf der Seite sind noch sehr viel mehr Beispiel-Projekte hinterlegt.

Gruß
Stefan

Zitat :

Beim Atmel glaub ich, dass die vier Abläufe um einen Befehl auszuführen parallel ablaufen. Sprich: Wenn ein Befehl im vierten Abschnitt steckt und gerade Ergebnisse zurückgeschrieben werden ist der nächste Befehl bereits beim Ausführen, der übernächste lädt bereits die Daten und der überübernächste Befehl wird bereits dekodiert.

Ja, so ist es. Ein Takt besteht aus 4 Teilen, Low, steigende Flanke, High und fallende Flanke. In jeden Teil eines Taktes wird eine Operation ausgeführt, daher komm die Rechenleistung. Abweichend sind (fast) alle Befehle die auf Flags reagieren müssen, die benötigen 2 Takte, da die Auswertung auch Zeit braucht.

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

[ Diese Nachricht wurde geändert von: Jornbyte am 14 Jan 2009 23:18 ]

Zitat :

Abweichend sind (fast) alle Befehle die auf Flags reagieren müssen, die benötigen 2 Takte, da die Auswertung auch Zeit braucht.Abweichend sind (fast) alle Befehle die auf Flags reagieren müssen, die benötigen 2 Takte, da die Auswertung auch Zeit braucht.

Das liegt wohl weniger an der Auswertungszeit, sondern daran, dass im Falle eines auszuführenden Sprungs die Pipeline keine brauchbaren Daten mehr enthält und der neue Befehl erst irgendwo geholt und decodiert werden muss.

_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Zitat :

dass im Falle eines auszuführenden Sprungs die Pipeline keine brauchbaren Daten mehr enthält und der neue Befehl erst irgendwo geholt und decodiert werden muss.

Genauso ist das!
Währendessen der Prozessor im Schritt 3 und 4 den Befehl ausführt und ev. die Daten an die gewünschte Speicherstelle zurückschreibt, holt er sich im Hintergrund schon den nächsten Befehl aus dem Speicher und decodiert ihn. Er führt also immer schon den Schritt 1 und 2 im Hintergund aus, währendessen er scheinbar noch mit Schritt 3 und 4 beschäftigt ist.

Trifft jedoch die Sprungbedingung zu (und nur dann), dauert der Befehl doppelt solange, weil ja der nächste im Speicher stehende Befehl, der mit dem Pipelining bereits geladen ist, verworfen werden muß und der übernächste Befehl geladen und decodiert wird.
Wird der Sprung nicht ausgeführt, dann ist der bereits geladenen Befehl gültig und der nicht ausgeführte bedingte Sprung dauert auch nur einen "Maschinenenzklus" lang. Ein "goto" Befehl dauert daher immer die doppelte Anzahl an Zyklen, weil das Pipelinig nicht funktioniert.

Das der Takt intern in 4-6 Zyklen unterteilt wird, mit dem die einzelnen Ausführungsschritte getaktet werden, ist eigentlich so alt wie die Prozessortechnik selber. Teilweise wurde das auch noch außerhalb des eigentlichen Prozessors durch den Taktgenerator erledigt (einge Typen von TI). Der Z80 hatte sogar eine Ausgang genannt "M1" (Machinenzykluns 1), der eben besagt, daß der Prozessor am Anfang der Prozesskette steht und das geladenen Byte im Befehlsregister landet. Auch der Trick des sogenannten "Pipelinigs", wo bei den internen Verarbeitungszyklen der freie Bus genutzt wird um den nächsten Befehl zu holen, ist schon sehr alt. Soviel ich weiß behrrschte der alten 6502 (C64), der aus einer Abspaltung von Motorola entstand, schon diesen Trick.

Prozessoren, die pro Takt einen Befehl "durchwurschteln", arbeiten intern genauso mit meist 4 Zyklen. Nur wird hier mit dem Takt eine interne PLL angestoßen, die eben dann mit der vierfachen Taktfrequenz schwingt. Genaugenommen müßte man sagen, daß dieser Prozessor mit der vierfachen Taktfrequenz arbeitet. Bei digitalen Signalprozessoren ist das schon lange Gang und Gebe und wurde auf kleine einfache Typen übernommen.

Schöne Grüße Selfman

_________________
Traue keinem Ding, das du nicht selber vermurkst hast.

Aber eine kleine Korrektur: Die Atmels nutzen keine PLL, um die
Performance zu erhöhen so dass ein Befehl pro Zyklus ausgeführt werden
kann, sondern das wird einfach über paralleles Abarbeiten der Phasen
abgefeiert.

Ausschnitt aus Atmega8-Spec:

Zitat :

In order to maximize performance and parallelism, the AVR uses a Harvard architecture – with separate memories and buses for program and data. Instructions in the Program memory are executed with a single level pipelining. While one instruction is being exe- cuted, the next instruction is pre-fetched from the Program memory. This concept enables instructions to be executed in every clock cycle. The Program memory is In- System Reprogrammable Flash memory.

Gruß
Stefan

Ich kenne jetzt die Struktur der Atmels nicht so genau, aber das was der Auszug beschreibt hat der PIC 1:1 genau so. Die Havard-Struktur mit getrennten Programm- und Datenbus genauso wie das einfache Pipelinig.

Aber das ein Prozessor mit nur einem Impuls den Befehl aus dem Speicher holen, dekodieren, diesen auch ausführen und ev. den Wert ins Register zurückschreiben kann, ist schier unmöglich. Eine Splittung in zumindest diese 4 Unterzyklen ist praktisch immer nötig. Daher glaube ich nicht ganz daran, daß der Atmel nicht doch irgeneine Schaltung drin hat, die den Takt noch einmal in mehrere Teile aufsplittet, auch wenn es im Datenblatt nicht erwähnt wird..

Etwas anders ist es bei einer reinen RISC Architektur. Dann ist aber jedes Bit im Befehlscode einer fixen Funktion zugeordnet. Irgenwelche Kombinationen sind dann nicht mehr drinn. Auch Quell- und Zielregister sind dann oft schon fix vorgegeben. Dememtsprechend dünn ist dann auch die Anzahl der Befehle, manchmal sind nicht einmal Sprünge mit von der Partie. Dadurch kann man die internen Zyklen minimieren.

Nur fällt mir beim PIC gerade jetzt erst auf, daß er eigenlich 8 externe Taktzyklen braucht um eine Befehl von vorne bis hinten zu bearbeiten. Durch das Pipelinig wird es aber normalerweise auf 4 beschränkt. Schön langsam bekomme ich auch Zweifel, wozu er 8 Zyklen braucht, 4 hätte ich ja noch verstanden.

Schöne Grüße Selfman


_________________
Traue keinem Ding, das du nicht selber vermurkst hast.

Zitat :

das ein Prozessor mit nur einem Impuls den Befehl aus dem Speicher holen, dekodieren, diesen auch ausführen und ev. den Wert ins Register zurückschreiben kann, ist schier unmöglich.

Doch, das geht schon.
Schiebebefehle, INC und DEC z.B. sind typische Beispiele dafür.

Jeder Takzyklus beteht ja aus mindestens einer steigenden und einer fallenden Flanke, ganz alte Prozessoren verwendeten auch mehrphasige Clocks
Nach jeder dieser beiden Flanken steht eine Menge Zeit für die asynchrone Logik zur Verfügung.
Oft ist das bischen Logik für Schieben und Zählen auch schon fest mit den Registern verbunden und deshalb braucht man die ALU dafür garnicht.
Das spart insbesondere bei registerindirekter Adressierung mit "gleichzeitigem" Ändern des Adressregisters (z.B. PUSH und POP) einiges an Zeit.





_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Zitat :

Schiebebefehle, INC und DEC z.B. sind typische Beispiele dafür.

Das ginge auch mit ganzen Rechenbefehlen in einer RISC Architektur.
Addition Register 1 mit Register 2 , Ergebnis in Register 3

steigende Flanke: Lade Befehl ins Befehlsregister und dekodieren.
Register 1 und Register 2 werden mit den beiden Eingängen der ALU
verbunden. ALU wird auf Addition gestellt, Ergebnis liegt am Ausgang an.
fallende Flanke: Register 3 übernimmt Wert von der ALU.

MfG
Holger

_________________
George Orwell 1984 ist nichts gegen heute.
Der Überwachungsstaat ist schon da!

Leider lernen die Menschen nicht aus der Geschichte,
ansonsten würde sie sich nicht andauernd wiederholen.