Morgen ! Ist ein T89C51RD2 kompatiebel mit einem Atmega8515 für mein Projekt ? Screenshot vom Schema als Anhang ! gruss
Angehängte Dateien:
-
schema.jpg
130 KB
Die sind weitgehend pinkompatibel (andere Resetpolarität). Zum Brennen und Software entwickeln brauchst Du aber andere Tools. Peter
Danke ! Das ist genau mein Problem darum möchte ich ja der Atmega ersetzen da ich keine Erfahrung mit AVR habe und mit Keil uVision 2 programmmieren möchte ! Meine Probleme sind: - genügend schnell ? - keine Problem mit dem S-Ram ansteueren ? - Probleme mit der CF-Card ansteuerung ?
Hi kommt drauf an.... ;-) Wenn der AVR in der Anwendung mathematisch (vor allem der Multiplikator, evtl. sogar FMUL) oder anderweitig arg gefordert wird, wird der T89C51RD2 nicht mehr hinterherkommen. Im stehen schließlich nur 3,3MIPS zur Verfügung dem AVR aber max. 16MIPS (Wenn diese Aussage auch nicht 100% exakt ist da MIPS -> *M*eaningless *I*nformation about *P*rocessor *S*peed) Ohne eine genaue Beschreibung was da passiert wird auch niemand eine Aussage treffen können. Ansonsten sind die 51er etwas gutmütiger auf dem Speicherinterface und damit problemloser bei der Ansteuerung von SRAM und CF-Karten. Matthias
"*M*eaningless *I*nformation about *P*rocessor *S*peed" Und ich dachte immer MIPS heißt *M*ega-*I*nstructions *p*er *S*econd! Wobei dann immer die kürzeren 1-Takt-Befehle angegeben werden also das max. Mögliche. MfG Andi
Hi die Angabe sagt aber so gut wie nichts über die Leistungsfähigkeit eines Prozessorkerns aus. Die von mir genannte Aufschlüsselung ist nicht die "offizielle" Bedeutung gibt aber doch ganz gut die Bedeutung dieser Zahl wieder. Matthias
Die Angabe sagt viel mehr aus, als eine normale Taktfrequenz. Beim 8051 ist die Taktfrequenz doch auch sehr hoch, trotzdem isser lahmer als nen AVR. Der AVR hat echte 16MIPS bei 16Mhz. Schafft also bis zu 16mio Instruktionen.
Die MIPS sind einfach nur die Anzahl der Mega-NOPs, mehr nicht. Ein direkter Vergleich RISC/CISC ist damit nur eingeschränkt möglich, d.h. CISC sind bei gleicher MIPS-Zahl schneller. In etwa sind 3,3MIPS beim 8051 vergleichbar schnell, wie 5MIPS beim AVR. Die 8051-er gehen bis 100MIPS (Silabs), die AVRs bis 20MIPS (ATMega48). Im DIP-Gehäuse gehen die 8051 aber nur bis 33MIPS (Maxim: DS89C420). Peter
"...nur bis 33MIPS..." ist aber keine Wertung. Der weitaus größte Teil meiner 8051 läuft bei 0,9MIPS (11,0592MHz Quarz) und ist trotzdem noch lange nicht am Anschlag. Peter
Wobei die Definition von RISC für AVR und CISC für 8051 vielleicht nicht so ganz stimmt. Wenn man jede Befehlskombination auflistet dann kommt der AVR schon eher an CISC wie ein 8051. Der 8051 hat genau 256 Befehle wobe ein AVR schon mit dem Befehl "MOV Rd,Rr" bereits auf 1024 (32 x 32) verschiedene kommt. Jeder µC hat auch seine Vor- und Nachteile: Schade das ein AVR nicht direkt SRAM-Inhalte verändern/setzen kann ohne Umwege über Register dafür kann man mit jedem Register direkt Rechnen (add, sub etc.). Schade das ein 8051 jede Arithmetik-Operation nicht ohne Umweg über das Accumulator-Register geht, würde die Gesammtzahl von 256 Befehlen sprengen, dafür kann direkt der RAM verändert/gesetzt werden. Will damit auch sagen, das man nicht mit Sicherheit behaupten kann, 5MIPS bei einem AVR seien das selbe wie 3,3MIPS bei einem 8051. Es kommt eher auf die Anwendung und Programmierweise an. MfG Andi
Hi >Es kommt eher auf die Anwendung und Programmierweise an. FullACK. Ohne Definition der Anwendung kann man da keine Aussage treffen. Es finden sich bestimmt einige Anwendungen in denen ein 100MIPS 8051er einem 20MIPS AVR haushoch unterlegen ist. Selbiges dürfte umgekehrt gelten. BTW1: Der 8051 hat nur 255 Befehle. Ein OP-Code ist unbesetzt. BTW2: RISC ist eigentlich auch nur eine Werbeaussage die ein Controller/Prozessor heute anscheinend haben muß. Eine richtige Definition von RISC bzw. CISC existert überhaupt nicht so das man eine Architektur in eine eindeutige Ecke stellen kann. Matthias
Na ja, bei 100MHz zu 20MHz ist das für den langsammeren sehr schwierig dem schnellerem etwas überlegen zu sein. Es sei denn, der Compiler für den schnelleren ist nicht so gut mit optimieren oder gar das man den mit 100MHz in BASCOM programmiert und den langsammeren in ASM. Ansonsten stim ich Dir voll zu. Es kommt eher auf die innere Architektur an, also was so in einem Maschinentakt sonst noch so nebenher geschaltet wird, und nicht auf die Befehlsanzahl. Aber wirklich schade das im AVR keine direkten Speicherzugriffe enthalten sind. Eine Frage zum P4: Der ist ja auch von Intel und jedes Prozessorhaus bastelt ja neuere CPU´s basierend auf seine Vorgänger. Ist es beim P4 eigentlich immer noch so, das jede Arithmetik, wenn man nicht die FPU verwendet, über den Accu laufen muß? Wenn ich so die Registerinhalte nach nen Programmabsturz sehe (gesehen hatte) glaube ich das noch irgend wie (EAX etc.). Mir ist schon klar das Intel was mit Pipelines, riesen Cache etc. gemacht hat. MfG Andi
"Es finden sich bestimmt einige Anwendungen in denen ein 100MIPS 8051er einem 20MIPS AVR haushoch unterlegen ist." Das dürfte aber wirklich nur äußerst schwer zu packen sein. Der umgekehrte Fall, daß ein 3,3MIPS 8051 einen 20MIPS AVR überfordert geht relativ einfach. Nämlich dann, wenn man viele verschieden schnelle Interupts benötigt und diesen bequem beim 8051 bis zu 4 verschiedene Prioritäten zuweisen kann, die dann ohne Verzögerung durch die Interrupt-Hardware aufgelöst werden. Besonders bei der Programmierung in C ergeben sich dadurch wesentliche Vorteile. Ich wundere mich daher sehr, daß sämtliche AVRs immer noch nur eine Priorität haben. Ich hätte schon einige größere Aufgaben, wo der ATMega128 besser geeignet wäre (mehr Flash), aber aufgrund der umständlicheren Interruptbehandlung außen vor bleiben muß und nur z.B. ein AT89C51ED2 in der Lage ist, die benötigten Zeitbedingungen auch einzuhalten. Peter
Was hat es eigentlich mit den Int.-Prioritäten beim 8051 auf sich? Geht es jetzt darum, das bei 2 gesetzten Int.-Flags einer davon Priorität hat und aufgerufen wird und/oder das während eines längeren Int.-Programmes ein anderer Interrupt aufgerufen werden kann? Das ließe sich doch mit SEI und einem reservierten Int.-Flag-Register auch im AVR handeln. MfG Andi
>>Es finden sich bestimmt einige Anwendungen in denen ein >>100MIPS 8051er einem 20MIPS AVR haushoch unterlegen ist. >Das dürfte aber wirklich nur äußerst schwer zu packen sein. z.B. Fixpunktarithmetik -> FMUL Mathematik im allgemeinen da der 8051 fast immer über den Akku muß >Der umgekehrte Fall, daß ein 3,3MIPS 8051 einen 20MIPS AVR überfordert >geht relativ einfach. $INTERRUPTPRIORITÄT Das hat aber überhauptnichts mit den MIPS zu tun. Das ist mangelhaftes Design des Interrupt-Controllers des AVR. @Andi >Ist es beim P4 eigentlich immer noch so, das jede Arithmetik, wenn >man nicht die FPU verwendet, über den Accu laufen muß? Ja. Wobei das über Register Renaming und das pipelining etwas entschärft wurde. Mit AMD64 wurden aber nicht ohne Grund acht weitere Register eingeführt. Matthias
@Andi, "Das ließe sich doch mit SEI und einem reservierten Int.-Flag-Register auch im AVR handeln." das hatte ich auch erst gedacht, aber blöder Weise löschen die lahmarschigsten Interrupts (UART, I2C, EEPROM) ihre Flags nicht, d.h. da würde sofort der Stack crashen. Auch kann es zur gefürchteten Prioritätsinversion kommen, d.h. auch die langsamen Interrupts können ja wieder unterbrechen. Ich hatte mal versucht, eine universelle Softwareprioritätsroutine zu schreiben, aber schnell gemerkt, daß ich nicht unter je 100 Zyklen bei Eintritt und Verlassen kommen, war also vollkommen zwecklos. Ich hab mich jetzt damit abgefunden, daß der ATMega8 recht optimal ist. Bei solch kleinen Sachen lassen sich die Interrupts gerade noch so beherrschen. Obwohl einmal mußte ich tricksen, der EEPROM sollte im Hintergrund geupdatet werden. Ich habs dann einfach mit in den Timerinterrupt gepackt, der setzt ja sein Flag automatisch zurück und behindert damit keine eiligeren Interrupts. Für größere Sachen kommen dann die 8051-er ran, es macht ja keinen Sinn, wenn ich beim Software schreiben ständig nur darauf achten muß, daß die Interrupts sich nicht beißen, Programmierzeit kostet schließlich auch Geld. In einem konkreten Fall, hatte ich schon den ATMega128 im Auge, bloß ehe ich mir dann einen abquäle und womöglich Geräte zurückrufen muß, weil ich eine bestimmte Interruptkonstellation doch noch übersehen habe, mußte ein AT89C51ED2 ran, auch wenns mit dem Flash schon sehr eng wurde. Sicherheitshalber hatte ich aber noch einen AT24C512 im Layout mit vorgesehen, um konstante Daten auszulagern, falls der Flash doch nicht mehr gereicht hätte. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.