Hallo Zusammen, Vielleicht kann / will mir einer (kurz) helfen ;)... Ich bin grad am Durchwühlen des Datensblatts vom ATmega64, und mir ist noch nicht ganz klar, wie der Programmspeicher auf den Datenspeicher zugreift. Prinzipiell ist es ja so, dass im Programmspeicher sowohl "Operation code + Adresse / Zahl" 1 Anweisung bilden, sehe ich das richtig? Nun ist es aber ja im ATmega64 so, dass der SRAM / Flash (bis zu) 64kB Speicherplatz haben, d.h. 16 Bit sind für die Adressierung notwendig. Zusätzlich für eine gültige Anweisung ist noch der OpCode. Meine Fragen: Mit wie vielen Bit wird der Programmspeicher ausgelesen? 16 Bit OpCode + 16 Bit Adresse / Zahl? Das würde ja bedeuten, dass 1 Anweisung 32 Bit lang ist, oder? Anschließend springt der Programm Counter um 4 Byte weiter? Wie groß ist das Instruction Register? Danke für die Hilfe ;) Grüße
Gast
#5746144
Alexander M. schrieb: > Mit wie vielen Bit wird der Programmspeicher ausgelesen? 16 Bit OpCode + > 16 Bit Adresse / Zahl? Das würde ja bedeuten, dass 1 Anweisung 32 Bit > lang ist, oder? Anschließend springt der Programm Counter um 4 Byte > weiter? Wie groß ist das Instruction Register? Das kommt darauf an. Manche Anweisungen sind 16Bit groß, manche 32Bit. Manche haben Adressen "dabei", die den ganzen Speicher ansprechen können, andere nur kleine Teile des I/O-Bereichs oder (die ganzen branch-Befehle) nur relativ zum aktuellen Programm Counter. Guck in das "Instruction Set Summary". Ich weiß nicht, ob das noch Teil des "normalen" Datenblatts ist oder separat, aber da steht das für jeden Befehl drin. MfG, Arno
Gast
#5746185
Hallo, Flash Speicher wird für Instruktionen und weitere Daten werden immer als Word adressiert, mit 64k Word hat man also 128k Byte an Flashspeicher. Das heißt auch gleichzeitig, liegen Daten im Flashspeicher, so muss man nun 17 Bit zur Adressierung verwenden! http://ww1.microchip.com/downloads/en/DeviceDoc/atmel-2490-8-bit-avr-microcontroller-atmega64-l_datasheet.pdf
Danke ;) Ja soweit hab ich das auch verstanden, mir ist aber trotzdem noch unklar, wie mit 17Bit Adresse + OpCode übermittelt werden kann. 16Bit entsprechen ja 64kB Adressen, den SRAM / Flash anzusprechen, dann fehlen aber immer noch die Informationen, was mit den Daten gemacht werden soll (ADD, JMP, ..) ?! Ich stehe da aktuell voll auf dem Schlauch... Grüße
Alexander M. schrieb: > Danke ;) > Ja soweit hab ich das auch verstanden, mir ist aber trotzdem noch > unklar, wie mit 17Bit Adresse + OpCode übermittelt werden kann. Es gibt einen 17 Bit Adressbus und 16 Bit Datenbus. Der Adressbzus sagt, von welcher Flash-Adresse gelesen werden soll, der Flash gibt dann die Daten auf dem Datenbus aus. > 16Bit entsprechen ja 64kB Adressen, den SRAM / Flash anzusprechen, Die Busse für Flash und SRAM sind beim AVR getrennt, siehe Harvard-Architektur. > dann > fehlen aber immer noch die Informationen, was mit den Daten gemacht > werden soll (ADD, JMP, ..) ?! Nö, die stecken in den Daten im Flash. Wie die kodiert sind, verrät dir das Assemblermanual. Diese Daten aus dem Flash (Befehle) werden vom Befehlsdekoder ausgewertet und die entsprechenden Operationen ausgeführt. Die Alu (Arithmethic Logical unit) rechnet, das Registerfile liefert und speichert Daten und der PC (Programm Counter) wird ja nach Befehl (Normal oder Sprung) erhöht. > Ich stehe da aktuell voll auf dem Schlauch... Dann mal mal nen Schritt vorwärts.
Alexander M. schrieb: > Ich stehe da aktuell voll auf dem Schlauch... Einfach mal ins Instruction-Set schauen. Da steht für jeden Befehl ganz genau drin, was welche Bits bedeuten.
Gast
#5746219
Anhand des Befehls ist klar, ob Program Space oder Data Space gemeint ist. Sprungadressen sind immer im Flash, Du kannst keinen Code im RAM ablaufen lassen. Datenpointer sind immer im Data Space. Um Daten aus dem Flash zu lesen, gibts spezielle Befehle (LPM/ELPM). Ist bei 8051 und 8-Bit/16 Bit PIC genauso. fchk
Datenblatt lesen ist immer gut, in dem Fall liest man besser das hier: http://ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf Und findet dann z.B heraus, das LDS/STS 32-Bit breite Befehle sind, mit 16bit für den Befehl, und 16 bit für die Adresse, die damit 64kB Ram adressieren können. Oliver
Gast
#5746240
Arno schrieb: > Guck in das "Instruction Set Summary". Ich weiß nicht, ob das noch Teil > des "normalen" Datenblatts ist oder separat, aber da steht das für jeden > Befehl drin. Oliver S. schrieb: > Datenblatt lesen ist immer gut, in dem Fall liest man besser das > hier: > > http://ww1.microchip.com/downloads/en/devicedoc/atmel-0856-avr-instruction-set-manual.pdf Danke, Instruction Set Manual meinte ich :) MfG, Arno
Danke ;) das hat mir gefehlt! Wenn aber 32 Bit ausgelesen werden (16 Bit Adresse + 16 Bit Befehl), und es "lediglich" einen 8-Bit-Datenbus (Seite 3: 8-Bit Data Bus, oder sind's tatsächlich wie vorhin im Beitrag erwähnt 16 Bit Datenbus?) gibt, dann sind ja 4 Zyklen notwendig, um eine Anweisung auszuführen, oder? In den ersten 2 Zyklen wird z.B. die Adresse ausgelesen, danach der Befehl? Grüße
Ytja, du kannst jetzt stundenlang weiter herumhypothetisiern, wie das alles funktionieren würde, wenn es so wäre, wie es nicht ist, oder aber du liest tatsächlich im Datenblatt nach, wie der Prozessor aufgebaut ist und funktioniert, und im Instructionset-Manual, wie viele Takte benötigt werden. Als erstes solltest du nochmals die Organisation von Flash- und Datenspeicher nachlesen, und auch, wie der Prozessor Befehle abarbeitet. Denn selbst in solch einem einfachen AVR passiert manches parallel. Oliver
Alles klar. Danke euch ;)
Alexander M. schrieb: > Danke ;) das hat mir gefehlt! > Wenn aber 32 Bit ausgelesen werden (16 Bit Adresse + 16 Bit Befehl), Es wird keine Adresse gelesen, die wird vorgegeben! und > es "lediglich" einen 8-Bit-Datenbus Das ist ein anderer Datenbus, nicht der zum Flash. Sagte ich bereits, AVRs sind Harvard-Maschinen. > (Seite 3: 8-Bit Data Bus, oder > sind's tatsächlich wie vorhin im Beitrag erwähnt 16 Bit Datenbus?) gibt, > dann sind ja 4 Zyklen notwendig, um eine Anweisung auszuführen, oder? Oder! Der AVR liest mit JEDEM Takt einen neuen Befehl vom Flash, mit Ausnahme der wenigen 32 Bit Befehle, die brauchen halt 2 Takte. > In den ersten 2 Zyklen wird z.B. die Adresse ausgelesen, danach der > Befehl? NEIN!! Adressen werden nicht gelesen! Der PC gibt die Adresse für den Flash vor, der liefert den Inhalt an der jeweiligen Adresse.
Gast
#5746474
Der Programmspeicher (Flash) beginnt an Adresse 0 und ist 16 bit breit mit der CPU verbunden. Der Datenspeicher (RAM) beginnt ebenfalls an Adresse 0 und ist 8 bit breit mit der CPU verbunden. Die CPU kann auf beide Speicher gleichzeitig zugreifen, weil sie jeweils über einen eigenen Bus verfügen. Der Opcode des jeweiligen Befehls bestimmt, welche Speicher als Operand ansgeprochen wird - nicht die Adresse.
Gast
#5746555
Stefanus F. schrieb: > Der Programmspeicher (Flash) beginnt an Adresse 0 und ist 16 bit breit > mit der CPU verbunden. > > Der Datenspeicher (RAM) beginnt ebenfalls an Adresse 0 und ist 8 bit > breit mit der CPU verbunden. > > Die CPU kann auf beide Speicher gleichzeitig zugreifen, weil sie jeweils > über einen eigenen Bus verfügen. Der Opcode des jeweiligen Befehls > bestimmt, welche Speicher als Operand ansgeprochen wird - nicht die > Adresse. Du willst schon das Richtige ausdrücken, im Detail stimmt's aber leider doch nicht ganz. Fieserweise ist der "RAM-Daten-Adressraum" segmentiert. Der RAM beginnt tatsächlich erst ab Adresse 0x60 oder 0x100. Darunter liegt das "Registerfile" (nicht bei den XMega) und der MMIO-Bereich. Noch fieser wird's mit externem RAM. Dann ist auch der tatsächliche RAM-Bereich noch weiter fragmentiert, nämlich in internen und externen RAM, ggf. sogar noch mit Remapping für den unteren Teil des externen RAM auf eine Adresse nach dem eigentlichen RAM-Ende...
Gast
#5746652
Hi
>Fieserweise ist der "RAM-Daten-Adressraum" segmentiert.
Was ist daran fies? Atmel/Microsoft bezeichnet das alles einfach als
Data Space. Und darauf kann man komplett mit den vielen LD/ST-Befehlen
zugreifen:
Z.B. steht im Instruction Set bei LDS:
'For parts with SRAM, the data space consists of the Register File, I/O
memory and internal SRAM (and external SRAM if applicable).'
Wenn ich mit einem Befehl alles überstreichen kann ist diese
'Segmentierung' eher künstlicher Natur.
MfG Spess
Gast
#5747145
spess53 schrieb: > Wenn ich mit einem Befehl alles überstreichen kann ist diese > 'Segmentierung' eher künstlicher Natur. Natürlich ist das irgendwie "künstlich" (wie eigentlich fast jedes Speichermodell), hat aber durchaus auch ganz praktische Konsequenzen. Z.B. die Tatsache, dass du mit externem RAM bei Adresse 0 mal garnix erwischst, mal das Register R0, und mal "irgendeine" (natürlich vorhersagbare) Adresse im externen RAM. Besonders Scheisse ist das halt für kaputte Programmiersprachen, die nur einen Adressraum kennen und die dann auch noch das sehr verwegene Axiom haben, dass ein Zeiger auf die Adresse 0 ungültig sein muss. Ich will jetzt keinen Namen einer solch dermaßen behämmerten Sprache nennen... Des Weiteren gibt es ja noch viel mehr Adressräume selbst bei einer so einfachen Struktur wie der AVR8-Architektur. Diese ungenannte Scheisssprache kann mit all denen nicht wirklich gut umgehen. Naja, EEPROM haben sie immerhin einigermaßen transparent hingefrickelt bekommen. In neuerer Zeit auch den Zugriff auf Daten im Codespace jenseits der 64kB-Grenze. Was als Baustelle verbleibt, ist mindestens noch der Zugriff auf Code jenseits der 64k-Word-Grenze. Die "Trampolin"-Technik ist nur ein notdürftiger Workaround um die Grenzen der Sprache, mehr nicht. Auch die Tatsache, dass er in den allermeisten Fällen hinreichend ist, ändert daran nix. So ist das nunmal in der Informatik: eine Gegenanzeige genügt, um ein Konzept als Ganzes als ungenügend zu entlarven.
Gast
#5747159
c-hater schrieb: > dass ein Zeiger auf die Adresse 0 ungültig sein muss. Ich will > jetzt keinen Namen einer solch dermaßen behämmerten Sprache nennen... Unfug! Natürlich kann man über C/C++ Pointer auf die Adresse 0 zugreifen.
Gast
#5747162
Arduino Fanboy D. schrieb: > Unfug! > Natürlich kann man über C/C++ Pointer auf die Adresse 0 zugreifen. Das habe ich nirgendwo bestritten. Aber: Leg' mal eine C++-Objektinstanz auf Adresse 0 und versuche, sie als Referenz zu übergeben, dann wirst du begreifen, was ich meine... Und nein: Aus Sicht der Maschine wäre sie an dieser Stelle völlig legal und voll funktionsfähig. Also: Problem der Sprache alleine...
Gast
#5747180
c-hater schrieb: > dass ein Zeiger auf die Adresse 0 ungültig sein muss. Du sprachest ausdrücklich von Zeigern. Jetzt von Referenzen. Das ist eine bewusste Täuschung. c-hater schrieb: > So ist das nunmal in der > Informatik: eine Gegenanzeige genügt, um ein Konzept als Ganzes als > ungenügend zu entlarven. Du hast dich damit selber als Lügner und Täuscher entlarvt. Einmal reicht dafür. Und tschüss...
Gast
#5747195
Arduino Fanboy D. schrieb: > Du sprachest ausdrücklich von Zeigern. > Jetzt von Referenzen. > Das ist eine bewusste Täuschung. Nö. Das zeigt den ganzen Schwachsinn der Definition von Referenzen in C++ in ungeschminkter Klarheit. Es ist ja nicht so, dass das nur die AVR8-Architektur betreffen würde (die betrifft es ja nur in dem eher seltenen Fall mit externem RAM)...
Beitrag #5747214 wurde von einem Moderator gelöscht.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.