Hallo, hat jemand mal erfahrung mit der Simulation des ATmega1280 im AVR Studio gemacht. Irgendwie funktioniert die Memory Watch Funktion niht richtig. Ich habe zum Beispiel einen String im Flash liegen. Im Watch windows wenn ich die variable eingebe sagt mir AVR Studio die Variable fängt bei 0x0114 and. Dabei hat die Variable auch den richtigen Inhalt den ich initialisiert habe. Jedoch im Memory Window wo man den kompletten Speicher sehen kann. liegt der String ganz woanders. Wie kann das sein? Dort fängt der String nämlich bei 0x8A an.
Das eine Fenster wird in Bytes zählen, das andere in 'word's also 16-Bit Portionen, weil der Flash so organisiert ist (und zufällig ist 0x0114 / 2 = 0x8A ;) ) hth. jörg
Häääää???? Mus man das verstehen? Die Fenster geben doch die absolute Adressen an
Hallo, richtig. Der Flash ist Word-organisiert, also 16Bit breit. Die angezeigten Adressen sind also Word-Adressen. Per Programm liest der AVR den Flash aber Byte-weise, damit sind die Adressen also *2, weil ein 16Bit = 2 Byte. Hätten die Entwickler des AVR das anders gemacht, müßte man immer Word-weise z.B. in 2 Register lesen, auch wenn man nur ein Byte lesen will... Gruß aus Berlin Michael
Michael U. wrote: > Der Flash ist Word-organisiert, also 16Bit breit. Nur für die Befehlslesezyklen. LPM arbeitet byteweise, damit ist das Prinzip aufgeweicht. > Hätten die Entwickler des AVR das anders gemacht, müßte man immer > Word-weise z.B. in 2 Register lesen, auch wenn man nur ein Byte lesen > will... Häh? Was hat die Darstellung der Adressen mit der Granularität des Speichers zu tun? Es gibt keine rechte Entschuldigung für diesen Quatsch, außer vielleicht, dass ,,schräge'' Architekturen (wie PICs mit ihren 12- und 14-bittigen Befehlswörtern) keine rechte Chance haben, Dinge sauber als Bytes auszudrücken. ,,Richtige'' RISC-CPUs benötigen oftmal eine 32- (oder gar 64-)bit-Granularität, d.h. deren Speicherbus ist komplett 32-bittig ausgeführt und nur auf ganzen (32-bit-)Wortadressen zugreifbar (sonst bekommt man einen misalignment trap), trotzdem drücken die alle Adressen als Byteadressen aus, weil das einfach für die Gewohnheiten der Programmierer verständlicher ist.
Hallo, @Jörg Wunsch: ich stelle jetzt einfach die gewagte Behautpung auf, daß ein µC sich nur relativ wenig aus schrägen Architekturen macht, die Entwickler desselben schlicht eine Hardware bauen müssen. Ob die jetzt onChip ist oder als diskrete Bauteile, macht für mich da erstmal wenig Unterschied. Also ist ein Speicher"chip" physikalisch irgendwie aufgebaut. Mit irgendeiner Bit-Breite. Damit werden eben soundsoviele Bits parallel gelesen oder geschrieben. Ob im AVR jetzt 2 8Bit-organisierte Speicher sind, von denen für das Programm beide gleichzeitig und für LPM beide einzeln angesprochen werden oder umgekehrt, ist nur eine Sache der internen "Verdrahtung". Die ist aber vom Hersteller halt so beschlossen. Atmel spricht von 16Bit-Flash, bleibe ich also dabei. Ob es lesbarer gewesen wäre, wenn man den Programmierern erklärt hätte, daß ein AVR seinen Programmcounter immer in 2er-Schritten erhöht? Ich glaube kaum. Gruß aus Berlin Michael
> Ob es lesbarer gewesen wäre, wenn man den Programmierern erklärt hätte, > daß ein AVR seinen Programmcounter immer in 2er-Schritten erhöht? Das machen zumindest andere RISCs so. Die unteren Bits kannste ja dann hardwaremäßig auf 0 verdrahten, und ein Sprungbefehl kann diese beim Adressieren weglassen (es programmiert ja heutzutage eh keiner mehr im Maschinencode). Es wäre jedenfalls manches damit einfacher geworden. Dieses Hin- und Hergeschiebe kostet einige Verrenkungen in den Tools (im Compiler zum Beispiel).
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.