Hi, weiß jemand nochmal, wie man in Assembler bei einem AVR direkt auf jedes einzelne Byte im RAM zugreifen kann? Wusste es mal, habe es aber vergessen. Danke! Pascal
Hallo, meinst du Ld bzw Ldi ? http://www.microchip.com/webdoc/avrassembler/avrassembler.wb_LD.html Gruß
Pascal schrieb: > weiß jemand nochmal, wie man in Assembler bei einem AVR direkt auf jedes > einzelne Byte im RAM zugreifen kann? Gibt es da denn was anderes als direkt auf einzelne Bytes zuzugreifen?
Hallo, Rolf M. schrieb: > Gibt es da denn was anderes als direkt auf einzelne Bytes zuzugreifen? ja, indirekt mit X,Y,Z als Zeiger. Gruß aus Berlin Michael
Michael U. schrieb: > Hallo, > > Rolf M. schrieb: >> Gibt es da denn was anderes als direkt auf einzelne Bytes zuzugreifen? > > ja, indirekt mit X,Y,Z als Zeiger. Naja, das ist aber kein indirekter Zugriff, sondern lediglich eine indirekte Adressierung. "raw" ist der Zugriff immer noch, und auf einzelne Bytes auch.
Hallo, so betrachtet wird er es beim AVR wirklich immer bleiben. Was wäre bei Dir ein indirekter Zugriff? Das der Ram nicht das liefert, was an der angelegten Adresse steht? Im µC-Umfeld wäre das für mich ein defekter Ram. ;-) Gruß aus Berlin Michael
Michael U. schrieb: > Rolf M. schrieb: >> Gibt es da denn was anderes als direkt auf einzelne Bytes zuzugreifen? > > ja, indirekt mit X,Y,Z als Zeiger. Bei Devices wie ATtiny40 gibt es sogar RAM-Bereiche, auf die nur indirekt zugegriffen werden kann: LDS hat dort eine 16-Bit Codierung und kann nur RAM-Speicher von 0x40..0xBF adressieren. Auf den Bereich ab 0xC0 kann nur indirekt zugegriffen werden.
@ Johann L. (gjlayde) Benutzerseite >Bei Devices wie ATtiny40 gibt es sogar RAM-Bereiche, auf die nur >indirekt zugegriffen werden kann: LDS hat dort eine 16-Bit Codierung >und kann nur RAM-Speicher von 0x40..0xBF adressieren. Auf den Bereich >ab 0xC0 kann nur indirekt zugegriffen werden. Ja, aber da fragt man sich im 21. Jahrhundert, was der Scheiß soll? Weder ASM-Programmierer noch C-Compiler-Entwickler wollen sich so einen Scheiß antun. Und was soll das bringen? 100 Gatter und 10um^2 an Silizium gespart? OMG!
Falk B. schrieb: > @ Johann L. (gjlayde) Benutzerseite > >>Bei Devices wie ATtiny40 gibt es sogar RAM-Bereiche, auf die nur >>indirekt zugegriffen werden kann: LDS hat dort eine 16-Bit Codierung >>und kann nur RAM-Speicher von 0x40..0xBF adressieren. Auf den Bereich >>ab 0xC0 kann nur indirekt zugegriffen werden. > > Ja, aber da fragt man sich im 21. Jahrhundert, was der Scheiß soll? > Weder ASM-Programmierer noch C-Compiler-Entwickler wollen sich so einen > Scheiß antun. Und was soll das bringen? 100 Gatter und 10um^2 an > Silizium gespart? OMG! AVR mit PICel!
Michael U. schrieb: > so betrachtet wird er es beim AVR wirklich immer bleiben. > Was wäre bei Dir ein indirekter Zugriff? Was das sein soll, war ja gerade meine Frage. Ich war auf den Thread gestoßen, weil ich neugierig war, was wohl der "RAM raw Zugriff" aus dem Betreff sein könnte, bzw. was es denn sonst noch für RAM-Zugriffe geben könnte, die nicht "raw" sind. Aber das Lesen des Postings hat dann gezeigt, dass es um einen AVR geht und eher mehr Fragen aufgeworfen als Antworten Dort war dann eben noch vom Zugriff in Assembler "auf einzelne Bytes" die Rede, und ich hatte wieder keine Idee, wie man denn auf dem AVR anders als auf einzelne Bytes zugreifen könnte (außer vielleicht auf einem ATxmega per DMA oder so). > Das der Ram nicht das liefert, was an der angelegten Adresse steht? Den Zugriff über einen Cache könnte man als indirekt ansehen, aber der ist ja in der Regel für das Programm transparent und außerdem beim AVR nicht vorhanden. ;-)
Beim Arduino wird man ja gelehrt, immer nur mit den RAM verschwendenden int-Befehlen etc. darauf zuzugreifen. Keine direkte Adressierung möglich. Deshalb programmiere ich die Arduinos jetzt über ISP, kein nervender Bootloader, schön in Assembler.
Pascal schrieb: > Beim Arduino wird man ja gelehrt, immer nur mit den RAM verschwendenden > int-Befehlen etc. darauf zuzugreifen. Was meinst Du damit?
Rufus Τ. F. schrieb: > Was meinst Du damit Vielleicht
1 | byte * a=0x1234; |
2 | byte b=*a; |
oder gleich
1 | byte b=*(byte *)0x1234; |
oder
1 | b = 0[0x1234]; |
Bei den Arduinos (mit denen ich in Sachen Mikrocontroller den Einstieg fand) hat man ja keinen direkten Zugriff auf den RAM. Man nutzt diesen durch Befehle wie z.B. int int8_t int16_t uint uint8_t uint16_t byte boolean usw. und kann dadurch keine wirklich effizienten Programme schreiben. Ich möchte so hardwarenah wie möglich programmieren -> Assembler, denn nur so kann ich die vollen 2 Kibibyte (kiB statt kB, 1024 statt 1000 für die die es nicht kennen) nutzen. Das beim Arduino nenne ich mal "indirekten Zugriff" auf den RAM Manipuliere ich durch Assembler-Befehle irgendein beliebiges Byte im RAM, funktionieren diese Arduino-Funktionen wie int, ich würde es fast schon "RAM-Disk" oder "Dateisystem im RAM" nennen, nicht mehr korrekt. Nunmal nutzen so gut wie alle Bibliotheken diese. Deshalb möchte ich jetzt nicht mehr diesen C++ C Arduino Mix an Programmiersprache nutzen, sondern die volle Kontrolle über die Register, RAM, EEPROM,... haben Also keinen indirekten Arduino-Zugriff mehr, sondern "raw-access" insofern, dass ich nicht mehr uint8_t variable=0xFF; schreibe, sondern direkt z.B. Byte 0x2E auf den Wert 0xFF setze. Finde ich effizienter und leichter, als mit den Namen und nicht glasklaren Speicherorten, hardwareabstrahiert herumzuspielen. Ich halte nicht viel von Hardwareabstraktion. Außer wenn es z.B. um ein OS geht, welches auf 10.000 und mehr verschiedenen PCs laufen soll.
Pascal schrieb: > Beim Arduino wird man ja gelehrt, immer nur mit den RAM verschwendenden > int-Befehlen etc. darauf zuzugreifen. Keine direkte Adressierung > möglich. Deshalb programmiere ich die Arduinos jetzt über ISP, kein > nervender Bootloader, schön in Assembler. Was möchte er sagen? Ah, daß Letzte!
Ahh, ein Anfänger der Cool sein und Pascal schrieb: > (kiB statt kB, 1024 statt 1000 für die die es nicht kennen) und klugscheissen will. Pascal schrieb: > Das beim Arduino nenne ich mal "indirekten Zugriff" auf den RAM Dabei hilf es immer seine eigenen Ausdrücke zu definieren, egal ob die schon anders benutzt werden Pascal schrieb: > manipuliere ich durch Assembler-Befehle irgendein beliebiges Byte im > RAM, funktionieren diese Arduino-Funktionen wie int und es schadet natürlich nicht, wenn man garnicht verstanden hat, was es ist, was man unbedingt besser machen will. Aber Du hast ja gute Gründe dafür: Pascal schrieb: > Finde ich effizienter und leichter, als mit den Namen und nicht > glasklaren Speicherorten, hardwareabstrahiert herumzuspielen. > Ich halte nicht viel von Hardwareabstraktion. Du machst eine typischen Anfängerfehler: Du versuchst alles besser zu machen bevor Du überhaupt verstanden hast wie es funktioniert. Benutzt doch mal die Forensuche, Du findest hier Diskussionen zun Thema 'Assenbler oder c(++)' von Leuten die beides können und echte Argumente haben. Lies die und versuch sie zu verstehen. Die Effizienz von Arduino hängt nicht an der Verwendung eine Hochsprache, sie leidet an der komplexen Unterkonstruktion die man immer mitschleppt, egal ob man sie aktuell braucht oder nicht. Und das lässt sich einfacher umgehen als die Assemblerbefehle Byteweise in den Prozessor zu brennen. Papier, Bleistift und 8 Dipschalter, das ist hardwarenah aber alles andere als effizient. btw: eine der ersten 'Erleichterungen' eines Assemblers bestand darin Namen für Speicheradressen zu benutzen, damit die Verwendung klarer wurde.
@ Pascal (Gast) >Bei den Arduinos (mit denen ich in Sachen Mikrocontroller den Einstieg >fand) hat man ja keinen direkten Zugriff auf den RAM. Unfug. Aber wenn ASM-Fetischisten über C reden, muss ja sowas rauskommen. Mobby, bist du es? >und kann dadurch keine wirklich effizienten Programme schreiben. Unfug^2. >Ich möchte so hardwarenah wie möglich programmieren -> Assembler, denn >nur so kann ich die vollen 2 Kibibyte (kiB statt kB, 1024 statt 1000 für >die die es nicht kennen) nutzen. Jaja. >Das beim Arduino nenne ich mal "indirekten Zugriff" auf den RAM Unfug^3.
Pascal schrieb: > Bei den Arduinos (mit denen ich in Sachen Mikrocontroller den Einstieg > fand) hat man ja keinen direkten Zugriff auf den RAM. Man nutzt diesen > durch Befehle wie z.B. > > int int8_t int16_t > uint uint8_t uint16_t > byte > boolean > > usw. Das sind keine Befehle, sondern Datentypen. Und das ist auch nicht Arduino-spezifisch. Indirekt ist an denen auch nichts. Hast du dir mal den Assembler-Code angeschaut, der für den Zugriff auf solche Variablen erzeugt wird? Bei Arduino gibt es viele Dinge, die sehr ineffizient sind, aber gerade das gehört da nicht dazu. > und kann dadurch keine wirklich effizienten Programme schreiben. Hast du das gemessen, oder wie kommst du auf diese seltsame Idee? > Ich möchte so hardwarenah wie möglich programmieren -> Assembler, denn > nur so kann ich die vollen 2 Kibibyte (kiB statt kB, 1024 statt 1000 für > die die es nicht kennen) nutzen. > > Das beim Arduino nenne ich mal "indirekten Zugriff" auf den RAM Meine Vermutung: ... ohne dass du eine Idee hast, wie es tatsächlich funktioniert. > Manipuliere ich durch Assembler-Befehle irgendein beliebiges Byte im > RAM, funktionieren diese Arduino-Funktionen wie int, ich würde es fast > schon "RAM-Disk" oder "Dateisystem im RAM" nennen, nicht mehr korrekt. Das hat nix mit Dateisystemen zu tun. Der Compiler bzw. Linker muss sich aber natürlich eine Zuordnung merken, also wo welche Variable steht. Das musst du in Assembler aber genauso. Zur Laufzeit ist davon im Programm aber nichts mehr drin. Wenn du dem Compiler aber dazwischen pfuschst und irgendwelche Speicherstellen überschreibst, die er schon für was anderes vorgesehen hat, ohne ihm das mitzuteilen, dann geht das natürlich schief. > Deshalb möchte ich jetzt nicht mehr diesen C++ C Arduino Mix an > Programmiersprache nutzen, sondern die volle Kontrolle über die > Register, RAM, EEPROM,... haben > > Also keinen indirekten Arduino-Zugriff mehr, sondern "raw-access" > insofern, dass ich nicht mehr > > uint8_t variable=0xFF; > > schreibe, sondern direkt z.B. Byte 0x2E auf den Wert 0xFF setze. Die Zeile macht nix anderes. Der Unterschied ist nur, dass du in deinem Quellcode einen sprechenden Namen hast (wenn er nicht gerade sowas wie "variable" ist) und dass der Linker sich automatisch darum kümmert, der Variable eine Adresse zu geben. Der Code, der da nachher rausfällt, ist genau der gleiche. Da ist am Zugriff nix indirekt oder weniger effizient. Willst du denn in Assembler auch keine Namen verwenden? Schreibst du dir auf einen Zettel, an welcher Adresse was steht, oder wie stellst du dir das vor? Also: 0x2E ist der Speicherort für "variable"? > Finde ich effizienter und leichter, als mit den Namen und nicht > glasklaren Speicherorten, hardwareabstrahiert herumzuspielen. Warum musst du denn die Adresse als Zahl vor dir haben? Welchen Vorteil bringt dir das? > Ich halte nicht viel von Hardwareabstraktion. Auch wenn du es nicht glaubst: Man kann Hardware-Abstraktion auch sehr effizient gestalten. Meiner Meinung nach lohnt es sich heute nur noch sehr selten, sich die Mühe zu machen, alles in Assembler zu schreiben.
Rufus Τ. F. schrieb: > Pascal schrieb: >> Beim Arduino wird man ja gelehrt, immer nur mit den RAM verschwendenden >> int-Befehlen etc. darauf zuzugreifen. > > Was meinst Du damit? Ich wette, du würdest diese Frage jetzt gerne zurückziehen wollen ;) Der TO ist entweder vollkommen verblödet oder ein begnadeter Troll. So lange ich mich da nicht entscheiden kann, sage ich mal lieber gar nichts zur Sache, sondern lehne mich zurück und genieße das Kino :D
Hallo, > Pascal schrieb: >> Bei den Arduinos (mit denen ich in Sachen Mikrocontroller den Einstieg >> fand) hat man ja keinen direkten Zugriff auf den RAM. Man nutzt diesen >> durch Befehle wie z.B. auch innerhalb der Arduino Umgebung und der IDE hindert Dich niemand, direkte Ram-Zugriffe in ASM zu machen. Es ist ein GCC drunter, die Syntax ist da dann etwas gewöhnungsbedürftig, aber es geht. Innerhalb von C und C++ aber oft nur einmal, wenn man da nicht zusätzlichen Aufwand treibt. Ich würde auch keinerlei Grund dafür finden. Rolf M. schrieb: >> Ich halte nicht viel von Hardwareabstraktion. > > Auch wenn du es nicht glaubst: Man kann Hardware-Abstraktion auch sehr > effizient gestalten. > Meiner Meinung nach lohnt es sich heute nur noch sehr selten, sich die > Mühe zu machen, alles in Assembler zu schreiben. Stimme ich Dir zu, ich mache es höchtens noch für ein Mini-Projekt zum Spaß, selbst meine Sensor-Software von 2009 habe ich irgendwann nach C portiert und inzwischen sogar schon mal in die Arduino-IDE mit fertigen Libs, weil es bequemer war. Was da die Folge sein könnte: die CR123A hält jetzt nur noch 2,5 Jahre statt 3 weil er vermutlich etwas länger wach ist zum Daten senden... Gruß aus Berlin Michael
Angehängte Dateien:
Pascal schrieb: > Finde ich... Genau das ist dein Fehler! Du setzt auf Gefuehle anstatt auf Fakten. Sorry, aber ich habe selten so einen Kaese gelesen. Pascal schrieb: > und kann dadurch keine wirklich effizienten Programme schreiben. Bitte informier dich erstmal, bevor du solchen unsinn schreibst. Pascal schrieb: > Das beim Arduino nenne ich mal "indirekten Zugriff" auf den RAM Ach, Junge...
> da fragt man sich im 21. Jahrhundert, was der Scheiß (indirekte Adressierung)
soll?
Nun, das nennt man RISC Controller. Wenn du einen Chip suchst, wo jede
Operation mit fast jedem denkbaren Operanden möglich ist, musst du zu
Intel gehen.
In der Praxis ist die Reduktion auf indirekte Adressierung ein guter
Kompromiss, denn in den allermeisten Fällen will man mehrere aufeinander
folgende RAM Zellen ansprechen.
Hallo, dann gleich was ordentliches: Bei der X-indizierten Zeropage-Adressierung wird immer der Inhalt der Speicheradresse ($ll+X) angesprochen. https://www.c64-wiki.de/wiki/Adressierung#Zeropage_X-indizierte_Adressierung Das waren noch Zeiten... Gruß aus Berlin Michael
Michael U. schrieb: > dann gleich was ordentliches: Wenn wir schon dabei sind: Sieh Dir mal den Befehlssatz des 6809 an. Der war noch mal ein paar Größenordnungen schicker als der 6502; die Zero-Page war beispielsweise verschiebbar (dazu gab es das "direct page"-Register, das die oberen 8 Bit der Adresse enthielt, die beim 6502 fest auf 0 liegt), die Index-Register X und Y waren 16 Bit breit und es gab nebem dem Akku "A" auch noch den Akku "B" oder beide als 16-Bit-Akku zusammengefasst als "D" ...
Rufus Τ. F. schrieb: > Der > war noch mal ein paar Größenordnungen schicker als der 6502; Gerade im Punkt "Indirekte Adressierung" ist der 6502 zum Teil doch noch etwas flexibler. 16-Bit Index-Register beim 6809 sehen zwar erstmal toll aus, aber z.B. sowas wie "(zp_addr,X)" oder "(zp_addr),Y", beim 65C02 auch "(zp_addr)", wodurch die Zeropage praktisch als ein großer Satz von vielen 16-Bit Index-Registern genutzt werden kann, gibt es beim 6809 nicht. Das haben seinerzeit auch oft die Verfechter des Z80 nicht kapiert, die so stolz auf ihre zwei 16-Bit Index-Register gegenübert den nur 8-Bit Registern des 6502 waren.
:
Bearbeitet durch User
Thomas E. schrieb: > wodurch die Zeropage praktisch als ein großer Satz von vielen 16-Bit > Index-Registern genutzt werden kann Da spart man gegenüber "extended indirect" ein Byte (und einen Zyklus). Das ist natürlich richtig, aber diesen Nachteil dürfte der 6809 an anderen Stellen locker 'reinholen. Um beispielsweise komplett relokatiblen Code zu produzieren, kann man konsequent PC-relativ adressieren und auch alle Sprünge PC-relativ ausführen (mit 8- oder 16-Bit-Offset). Denk' noch mal drüber nach, ob Du wirklich "nicht kapieren" schreiben möchtest. Das ist ... etwas ruppiger Tonfall, meinst Du nicht auch?
Pascal schrieb: > weiß jemand nochmal, wie man in Assembler bei einem AVR direkt auf jedes > einzelne Byte im RAM zugreifen kann? Wusste es mal, habe es aber > vergessen. Danke! Hier würde ich mal sagen: Es gibt ca 130 ASM Kommandos. Man sollte schon in der Lage sein diese Liste zu finden, zu lesen und zu verstehen. Sonst wirds derbe schwierig, mit der Asm Programmierung. Ich, für meinen Teil, weiß, dass ich mich da auf Kompetenzstufe 2 bis 3 bewege. https://de.wikipedia.org/wiki/Kompetenzstufenentwicklung Dieses Beitrag "Re: RAM raw Zugriff" Würde ich dann eher der Stufe 1 zuordnen. Was man relativ leicht, an den irrigen Beurteilungen erkennen kann. Aber das ist ja alles nicht dauerhaft fixiert. Darum heißt es ja auch Kompetenzstufen Entwicklung Stetes Anwenden/Üben führt von 1 zu 3 Also, @Pascal: Du hast noch einen weiten Weg vor dir. Genieße es. Es gibt viel zu lernen. Auch über Compiler, und wie effektiv sie mittlerweile arbeiten (können, wenn man ihnen die Chance gibt). Horst schrieb: > Die Effizienz von Arduino hängt nicht an der Verwendung eine > Hochsprache, ... Unterscheib! Ein Beispiel hatten wir hier letztens noch... Schnellstmöglicher Pintoggle in einer Endlosschleife. Egal ob ASM, C oder OOP in C++, schneller als 3 Takte geht nicht. Aber das geht in allen 3 Sprachen gleich gut.
Rufus Τ. F. schrieb: > Da spart man gegenüber "extended indirect" ein Byte (und einen Zyklus) und "extended indirect" entspricht dann auch nur "(zp_addr)". Wenn man das Index-Register auch noch indizieren will "(zp_addr,X)", wirds beim 6809 doch etwas komplizierter. Aber das sind natürlich nur Einzelaspekte, ich wollte damit nicht behaupten, daß der 6502 insgesamt besser als der 6809 ist. Rufus Τ. F. schrieb: > Denk' noch mal drüber nach, ob Du wirklich "nicht kapieren" schreiben > möchtest. Ok, ist wohl etwas ruppig formuliert. Statt "haben oft nicht kapiert" wäre wohl besser sowas wie "war manchen so nicht bekannt". Mit "Verfechter" hatte ich dabei aber sowieso eher die "Glaubenskrieger" vor meinem geistigen Auge, als die, die sich tatsächlich objektiv mit den Stärken und Schwächen der jeweiligen Prozessorfamilien auseinandergesetzt haben. Ich wollte damit keinesfalls alle Z80-Fans als inkompetent hinstellen - sorry, wenn es vielleicht so 'rübergekommen ist!
:
Bearbeitet durch User
Thomas E. schrieb: > Wenn man das Index-Register auch noch indizieren will "(zp_addr,X)", > wirds beim 6809 doch etwas komplizierter. Nun, da verwendet man eine der indizierten Adressierungsarten, die zwei Register addieren und das Resultat als Adresse verwenden. Das ist wegen des wegfallenden Speicherzugriffs zum Auslesen der zero/direct page dann auch etwas flotter. Letztlich ist ein 1:1-Vergleich bestimmter Konstrukte nicht zielführend, weil bestimmte Aufgaben auf den unterschiedlichen Architekturen auf andere Art und Weise gelöst werden können. > Ich wollte damit keinesfalls alle Z80-Fans als inkompetent hinstellen Akzeptiert; danke für die Reaktion. Mich hättest Du damit zwar nicht persönlich getroffen (mein erster Computer war zwar ein Z80-System, aber mein erster selbstgebauter ein 6809-System), aber es ist sehr schön, hier Leuten zu begegnen, die Umgangsformen noch zu schätzen wissen. Insgesamt dürfte es mindestens ein Vierteljahrhundert her sein, daß ich das letzte Mal irgendwas in 6809-Assembler geschrieben habe ... und mein 6809-Rechner steht auch schon lange im Regal.
Hallo, Rufus Τ. F. schrieb: > Wenn wir schon dabei sind: Sieh Dir mal den Befehlssatz des 6809 an. Der > war noch mal ein paar Größenordnungen schicker als der 6502; die... Meine erste Bekanntschaft mit µP und Programmierung ware in 6800. AkkuA, AkkuB, 16Bit Indexregister, Stackpointer, Programmcounter, Statusregister. Danach kam bei mir der Z80. Gruß aus Berlin Michael
Rufus Τ. F. schrieb: > Letztlich ist ein 1:1-Vergleich bestimmter Konstrukte nicht zielführend, > weil bestimmte Aufgaben auf den unterschiedlichen Architekturen auf > andere Art und Weise gelöst werden können. Genau! Am Ende nutzt einem dann die Erfahrung mit der jeweiligen Architektur, schon beim Austüfteln des Lösungswegs die Stärken zu nutzen und die Schwächen zu meiden... Rufus Τ. F. schrieb: > (mein erster Computer war zwar ein Z80-System, aber > mein erster selbstgebauter ein 6809-System) Ich bin sozusagen mit dem 6502 aufgewachsen: Einstieg mit Rockwell AIM-65, 1979 (kurz vor'm Abi). Anfang der 80er war bei mir bzw. uns (ein paar interessierten Mitstudenten) der 6809 auch ein heisser Kandidat für ein Selbstbausystem, dann wurde über 68000 nachgedacht, realisiert wurde aber letztendlich doch nur ein 6502-System aus Eurokarten im 19"-Gehäuse, mit angepasster/aufgebohrter Software des AIM-65 und Eigenkreationen (DOS, Video-Treiber etc.). Damals gab es natürlich auch die teils lebhaften Diskussionen, ob und warum nun der Z80 oder 6502 die "bessere" CPU ist - zumindest rückblickend habe ich das aber eher als befruchtende Fachsimpeleien in Erinnerung. Heute habe ich hier manchmal den Eindruck, daß es es bei fachlichen Diskussionen gleich aggressiver zugeht, was sicher auch einfach an der Natur so eines Forums liegt. Wie man am Beispiel meiner "nicht kapiert"-Bemerkung sieht, kommt so ein etwas unüberlegt formuliertet Satz geschrieben doch ganz anders 'rüber, als in einem lockeren Gespräch! :)
Michael U. schrieb: > Meine erste Bekanntschaft mit µP und Programmierung ware in 6800. Auch schön, aber ist mit dem 6809 nur verwandt; genauer: der '09 kann deutlich mehr. Noch schicker war übrigens die CMOS-Variante von Hitachi (6309), die hatte etliche leider sehr lange unbekannte Erweiterungen: http://fms.komkon.org/comp/CPUs/6309.txt Thomas E. schrieb: > Heute habe ich hier manchmal den Eindruck, daß es es bei fachlichen > Diskussionen gleich aggressiver zugeht, was sicher auch einfach an der > Natur so eines Forums liegt. Wahre Worte. Sehr wahre Worte.
zwar ist dieser Thread scheinbar zu so einer Art "C vs Assembler" Diskussion geworden, aber mich würde mal interessieren, wie man diese Instruktion (ld/ldi/lds) nutzt ... also wie man auf den RAM zugreift ohne für jedes Byte jeweils einen eigenen Namen festzulegen. Wenn ich z.B. aus dem n-ten Byte des RAMs den Wert auslesen möchte - aber die Zahl n noch nicht kenne, sondern z.B. aus dem EEPROM auslese - wie kann ich dann in Assembler diesen auslesen? Und nebenbei: wie greift man auf den EEPROM in Assembler zu?! Das ist mir alles irgendwie unverständlich, die Adressen von RAM, EEPROM, den Registern,... wie lauten die? woher soll man das wissen?
ATtiny13A geek schrieb: > Das ist mir alles irgendwie unverständlich, die Adressen von RAM, > EEPROM, den Registern,... wie lauten die? woher soll man das wissen? So etwas findet man im Datenblatt des Controllers. Klingt wie eine oft wiederholte Binsenweise à la "RTFM", trifft aber zu.
Nur wo?! das sin über 200 Seiten... und zudem macht das Englisch alles noch schwerer da ich kein C2 Englisch-Sprachler bin
ATtiny13A geek schrieb: > Wenn ich z.B. aus dem n-ten Byte des RAMs den Wert auslesen möchte - > aber die Zahl n noch nicht kenne, sondern z.B. aus dem EEPROM auslese - > wie kann ich dann in Assembler diesen auslesen? Erst den Wert n aus dem EEPROM in das Z-Register lesen, dann mit LD die entsprechende Speicherstelle aus dem RAM holen. Letzterer Schritt wird in AVR-Tutorial: SRAM gezeigt. > Und nebenbei: wie greift man auf den EEPROM in Assembler zu?! Das ist mir > alles irgendwie unverständlich, die Adressen von RAM, EEPROM, den > Registern,... wie lauten die? woher soll man das wissen? Dazu gibt's eigentlich Datenblätter, AppNotes und Tutorials. Im Datenblatt deines Namensvetters ist ein Stück Beispiel-Assemblercode drin, das man direkt hernehmen kann, um ein Byte aus dem EEPROM zu lesen.
ATtiny13A geek schrieb: > Nur wo?! das sin über 200 Seiten... Bevorzugt im Kapitel über EEPROM. Wenn wir dir vorkauen müssen, wie du deine Arbeit zu tun hast, dann solltest du sie vielleicht nicht machen.
> ... à la "RTFM" ...
Da dieser Thread seltsame Wege geht, möchte auch ich zu einem Abstecher
beitragen, angeregt durch dieses ständig wiederholte RTFM "Read The
Fucking Manual" (was mir, gelinde gesagt, auf die Nerven fällt, von IIRC
IMHO &c ganz zu schweigen):
Sollten Sie, geneigte Leserin, besonderen Wert darauf legen, von ihren
amerikanischen Schwestern als wahrhaft emanzipiert und frei angesehen zu
werden, so muß ich Ihnen schweren Herzens den Rat geben, sich im
Gebrauch der Kraftwörter shit und besonders auch fuck zu üben. Aus
Gründen, denen ich als Angehöriger der älteren Generation nicht folgen
kann, gilt dies heutzutage als wesentlicher Beweis dafür, daß Sie die
Fesseln des männlichen Chauvinismus abgeworfen haben und daher imstande
sind, Ausdrücke zu verwenden, die bisher das fragwürdige Privileg
ordinärer Mannsbilder waren. Aber bitte - auch fuck bloß nicht in
seiner wahren Bedeutung! Wundern Sie sich also nicht, wenn Sie aus
zartem Frauenmund etwa die groteske Formulierung vernehmen : "My
neighbour [pardon, gemeint ist natürlich neighbor] was fucking mad
because my dog went to the bath room on his sidewalk [dem englischen
pavement, also Gehsteig]."
Paul Watzlawick: Gebrauchsanweisung für Amerika
S. R. schrieb: > ATtiny13A geek schrieb: > Nur wo?! das sin über 200 Seiten... > Wenn wir dir vorkauen müssen, wie du deine Arbeit zu tun hast, dann > solltest du sie vielleicht nicht machen. Eine sehr positive Einstellung, was das Teilen von (potentiell vorhandenem) Wissen betrifft. Danke dafür! Rolf M. schrieb: > > Im > Datenblatt deines Namensvetters ist ein Stück Beispiel-Assemblercode > drin, das man direkt hernehmen kann, um ein Byte aus dem EEPROM zu > lesen. Sorry, ich habe im Datenblatt noch nie bewusst gesehen, dass mehrere Zeilen Beispielcode vorhanden ist. Danke für den Hinweis!
> diese Instruktion (ld/ldi/lds) nutzt ... also wie man auf den RAM zugreift
Da ist dem abgeneigten Datenblatt-Leser also auch hier im Thread nicht
aufgefallen, dass ldi rein gar nichts mit dem RAM zu tun hat. Das
lässt mich jetzt etwas ratlos zurück.
ATtiny13A geek schrieb: > Nur wo?! das sin über 200 Seiten... Wenn man von den über 200 Seiten alles überblättert, das ganz offensichtlich mit der gestellten Frage nichts zu tun hat (z.B. Electrical Characteristics, Timers, ADC, Ports, Interrupts, Gehäuseausführung usw...), bleiben von den vielen Seiten nur noch ganz wenige übrig...
ATtiny13A geek schrieb: > Eine sehr positive Einstellung, was das Teilen von > (potentiell vorhandenem) Wissen betrifft. Ich weiß, wo ich Informationen, die ich aus dem Kopf nicht fehlerfrei rezitieren kann, herbekomme. Diese altbekannte und oftmals hochgeschätzte Technik könnte auch für dich hilfreich sein. Allerdings habe ich wenig Interesse daran, jemandes Arbeit zu übernehmen, der offensichtlich kein Interesse an seiner eigenen Arbeit hat.
S. Landolt schrieb: > ... à la "RTFM" ... > > Da dieser Thread seltsame Wege geht, möchte auch ich zu einem Abstecher > beitragen, angeregt durch dieses ständig wiederholte RTFM "Read The > Fucking Manual" (was mir, gelinde gesagt, auf die Nerven fällt, von IIRC > IMHO &c ganz zu schweigen): > Amen! (auch wenn ich nicht gläubig, sondern der Physik verschrieben bin) Mich nervt das auch, deshalb mal drei knallharte Antworten: RTFM! ......... DIY! IIRC, ............ O RLY? NVM. IMHO ........... AAMOF not a NPOV ;) diese Abkürzungen lassen das Deutsche echt verkommen...
S. R. schrieb: > Allerdings habe ich wenig Interesse daran, jemandes Arbeit zu > übernehmen, der offensichtlich kein Interesse an seiner eigenen Arbeit > hat. Wieso Arbeit?
Mitunter ist auch die Beschreibung der einzelnen AVR-Befehle hier nützlich: https://www.microchip.com/webdoc/avrassembler/avrassembler.wb_instruction_list.html (k.A. ob/wie die einzelnen Befehle auch so im aktuellen DB beschrieben werden)
S. R. schrieb: > der offensichtlich kein Interesse an seiner eigenen Arbeit > hat. ich bin froh, wenn ich neben dem Studium pro Woche 1h Zeit für Mikrocontroller & analoge Elektronik habe ... S. Landolt schrieb: > diese Instruktion (ld/ldi/lds) nutzt ... also wie man auf den RAM > zugreift > > Da ist dem abgeneigten Datenblatt-Leser also auch hier im Thread nicht > aufgefallen, dass ldi rein gar nichts mit dem RAM zu tun hat. Das lässt > mich jetzt etwas ratlos zurück. ICH WEIß WAS LDI MACHT Es ist einer der ersten Befehle die ich erlernte. könnte aber auch sein, dass es ein Spezialregister gibt, welches immer aktuell den gesuchten Wert mit sich führt, dessen Adresse in einem anderen Register gespeichert wird. Weiß ich doch nicht. Außerdem gibts 2 LDS - beim tiny10 wie beim 13 Load SRAM oder bei anderen AVRs Load Data Segment oder so
> macht das Englisch alles noch schwerer > der Physik verschrieben bin > neben dem Studium Habe ich das richtig verstanden - ein Physikstudent, der größere Schwierigkeiten mit Englisch hat? Das geht auf Dauer nicht zusammen und muss dringend geändert werden (ich weiß, wovon ich rede, auch wenn es Jahrzehnte zurückliegt).
PS: Musste ich doch in der Oberstufe eines von beiden abwählen, was für ein Widersinn! Natürlich behielt ich Physik.
ATtiny13A geek schrieb: > ich bin froh, wenn ich neben dem Studium pro Woche 1h Zeit für > Mikrocontroller & analoge Elektronik habe ... Ach herrje, die Tränendrüse ;) Wenn ich mich recht erinnere, haben wir damals (TM) nicht unwesentliche Zeit des Tages (bzw. der Nacht) zur Erkundung von nicht-fachlichen Themen (Frauen, Drogen, ...) "verbraucht", trotzdem die Prüfungen bestanden und uns - ganz nebenher, ohne Internet - noch selbst den Z80 und M68000 beigebracht (ganz abgesehen davon, daß irgendwo ja noch das Geld für das Studium herkommen musste). Jetzt könntest Du ja behaupten, daß Studieren heutzutage wesentlich schwieriger wäre. Wenn da was dran wäre, würden nicht gar so viele Pfeifen (die offensichtlich nix gelernt haben) von der Hochschule in der Industrie ankommen. Ich glaube ja, dass wir das hauptsächlich aus zwei Gründen hinbekommen haben: - weil's uns wahnsinnig interessiert hat - weil wir noch kein Internet hatten, das uns das selber Denken abgenommen hätte Denk' mal drüber nach ;)
Ich bin sehr dafür, selber zu denken. Nur wird heutzutage vorausgesetzt, dass jeder Zugang zum Internet hat. Und es nutzt. Aber leider erfüllt das www nicht mehr den sinnvollen Zweck wie früher am CERN, sondern ist nur noch ein Haufen Müll (mikrocontroller.net zählt natürlich zum "besseren Teil" des Internets ;)
ATtiny13A geek schrieb: > könnte aber auch sein, dass es ein Spezialregister gibt, welches immer > aktuell den gesuchten Wert mit sich führt, dessen Adresse in einem > anderen Register gespeichert wird. Weiß ich doch nicht. Wenn es dich zu einem AVR mit möglichst schräger Adressierungsart zieht, dann ist der ATtiny40 etwas für dich: Der hat die Register RAMAR (RAM Address Register) und RAMDR (RAM Data Register) über welche die ersten 0x100 Bytes des RAM-Adressbereichs zugegriffen werden können, d.h. der I/O-Bereich von 0 bis 0x3f und der RAM-Bereich von 0x40 bis 0xff. Die 0x80 RAM-Bytes von 0x40 bis 0xbf können auch via LDS / STS zugegriffen werden. Und indirekte Adressierung gibt's natürlich auch noch, allerdings nur ohne Offset, d.h. es gibt kein LDD und STD.
ATtiny13A geek schrieb: > zwar ist dieser Thread scheinbar zu so einer Art "C vs Assembler" > Diskussion geworden, aber mich würde mal interessieren, wie man diese > Instruktion (ld/ldi/lds) nutzt ... also wie man auf den RAM zugreift > ohne für jedes Byte jeweils einen eigenen Namen festzulegen. Warum sollte man das wollen? Im Normalfall will man nicht auf irgendein Byte des RAM zugreifen, sondern auf ein ganz bestimmtes. Und dann ergibt es absolut Sinn, dem einen Namen zu geben und es über den Namen anzusprechen. Wenn du auf www.mikrocontroller.net einen Post absetzen willst, verwendest du ja auch den Hostnamen und tippst nicht die IP-Adresse in deinen Browser. > Wenn ich z.B. aus dem n-ten Byte des RAMs den Wert auslesen möchte - > aber die Zahl n noch nicht kenne, sondern z.B. aus dem EEPROM auslese - > wie kann ich dann in Assembler diesen auslesen? In C modelliert man so etwas als Array, in dem Fall als Array von Bytes (vulgo uint8_t). Und für den Zugriff wird einfach n zur Startadresse des Array addiert. Der C-Compiler macht das für dich, einfach indem du den *[]* Operator verwendest. In Assembler wirst du die Startadresse in ein geeignetes Register(paar) laden müssen, z.B. Z und dann den Index n addieren. Das ist keine Raketentechnik. > Und nebenbei: wie greift man auf den EEPROM in Assembler zu?! So wie es im Datenblatt steht. Oder alternativ was das API deiner Programmierumgebung bereitstellt. Die AVR-libc kommt z.B. mit vorgefertigten Funktionen zum Zugriff auf das EEPROM. Schneller kriegst du das auch in Assembler nicht hin.
ATtiny13A geek schrieb: > ich bin froh, wenn ich neben dem Studium pro Woche 1h Zeit für > Mikrocontroller & analoge Elektronik habe ... Dann machst du was falsch. Sei es das Studium oder deine Zeitplanung.
ATtiny13A geek schrieb: > zwar ist dieser Thread scheinbar zu so einer Art "C vs Assembler" > Diskussion geworden, aber mich würde mal interessieren, wie man diese > Instruktion (ld/ldi/lds) nutzt ... also wie man auf den RAM zugreift > ohne für jedes Byte jeweils einen eigenen Namen festzulegen. > > Wenn ich z.B. aus dem n-ten Byte des RAMs den Wert auslesen möchte - > aber die Zahl n noch nicht kenne, sondern z.B. aus dem EEPROM auslese - > wie kann ich dann in Assembler diesen auslesen? Und nebenbei: wie greift > man auf den EEPROM in Assembler zu?! C und Assembler sind dich kein Widerspruch. Probates Mittel in solchen Fällen ist, C-Code vom Compiler in Assembler übersetzen zu lassen und das im asm-Projekt zu verwenden wenn's denn um jeden Preis Hochsprache zu vermeiden gilt: Beispiel:
1 | #include <stdint.h> |
2 | #include <avr/eeprom.h> |
3 | |
4 | uint8_t ee_val EEMEM = 42; |
5 | uint8_t array[20]; |
6 | |
7 | uint8_t func (uint8_t val) |
8 | {
|
9 | eeprom_write_byte (&ee_val, val); |
10 | val = eeprom_read_byte (&ee_val); |
11 | return array[val]; |
12 | }
|
und das dann compilieren mit -mmcu=attiny13 -save-temps -fverbose-asm -Os und voilà, da ist der Assembler-Code:
1 | func: |
2 | ; foo.c:9: eeprom_write_byte (&ee_val, val); |
3 | mov r22,r24 ; , val |
4 | ldi r24,lo8(ee_val) |
5 | ldi r25,hi8(ee_val) |
6 | rcall eeprom_write_byte |
7 | ; foo.c:10: val = eeprom_read_byte (&ee_val); |
8 | ldi r24,lo8(ee_val) |
9 | ldi r25,hi8(ee_val) |
10 | rcall eeprom_read_byte |
11 | ; foo.c:11: return array[val]; |
12 | mov r30,r24 ; val, val |
13 | ldi r31,0 ; val |
14 | subi r30,lo8(-(array)) |
15 | sbci r31,hi8(-(array)) |
16 | ; foo.c:12: } |
17 | ld r24,Z ; , array |
18 | /* epilogue start */ |
19 | ret |
Anlegen der Objekte spar ich mal, dass kannst selber nachlesen. Und die Funktionen der avr-libc können selbstverständlich auch von Assembler aus verwendet werden — kein Grund, die selber für jedes Device nachzuklöppeln! Einfach avr-gcc zum Linken verwenden und schon sind alle Funktionen der avr-libc verfügbar!
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.