mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmega8515


Autor: Hans Reichert (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Morgen !

Ist ein T89C51RD2 kompatiebel mit einem Atmega8515 für mein Projekt ?

Screenshot vom Schema als Anhang !

gruss

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die sind weitgehend pinkompatibel (andere Resetpolarität).

Zum Brennen und Software entwickeln brauchst Du aber andere Tools.


Peter

Autor: Hans Reichert (Gast)
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Andi (Gast)
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Simon Küppers (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Andi (Gast)
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Andi (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Andi (Gast)
Datum:

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

Autor: Matthias (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

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.