Workshop: Programmierung in Assembler (Atmel ATM8)

kaeselok · #101

Wir haben zu danken für die Arbeit die Du Dir machst!!!

Viele Grüße,

Kalle

#102

SRAM adressieren, beschreiben, auslesen Teil 1 (reservierte Bytes)

Guten Morgen,

Wie schon angekündigt befassen wir uns vor Weihnachten noch mit dem Thema "SRAM" und auch wenn der Beitrag vermutlich recht gross werden wird, das Thema ist an und für sich einfach.

Bevor es losgeht ein Hinweis: Ich habe gestern ein paar Seiten gefunden, in denen der Zugriff auf den Flash des Controllers sehr wohl möglich ist. Da ich dafür allerdings keine Verwendungsmöglichkeit sehe lasse ich das Thema aus.

Nun, wie wir ja wissen beinhaltet unser Mikrocontroller neben dem Prozessor auch einen Flash, einen EEProm, sowie ein schnelles SRAM. Letzteres ist im Prinzip mit dem Arbeitsspeicher eines PC vergleichbar, wenn auch mit einem Unterschied:
Ein x86er besitzt intern eigene Arbeitsregister, die mit dem Arbeitsspeicher und/oder dem Cache nichts zu tun haben. Bei unseren Atmels sind die Arbeitsregister ein Bestandteil des SRAM und damit haben wir die erste von drei in diesem Workshop behandelten Möglichkeiten, das SRAM zu benutzen.
Nun folgt der oblikatorische und mittlerweile hoffentlich reflexartige

Blick ins Datenblatt, wo uns auf Seite 18 der Aufbau des SRAM offenbart wird. Hier seht Ihr in der kleinen Grafik nicht nur die ganzen Register und deren fest zugewiesenen Adressen im SRAM, auch die ganzen anderen bisher behandelten Steuerregister sind im SRAM zu finden.
Mit dem Befehl ldi r29, 0x00 machen wir also nichts anderes, als in die Adresse 0x001D des SRAM den Wert 0x00 hineinzuschreiben. Diese Art und Weise, das SRAM zu beeinflussen ist eigentlich längst in Fleisch und Blut übergegangen und muss sicher nicht mehr ausgeführt werden. Eigentlich grabscht so ziemlich jeder Befehl im SRAM herum, immerhin beeinflusst so ziemlich jeder Befehl ein Register...

Nun ist ja die Anzahl der direkt ansprechbaren Register ziemlich beschränkt, zumal einige Register, auf die wir später noch zu sprechen kommen, noch ein paar Sonderaufgaben haben und nicht immer frei zur Verfügung stehen. Es gibt aber durchaus Fälle, wo ich einfach mehr Register, eben Ablageplätze, brauche. Sei es, um viele Daten abzulegen oder auch im Konstanten in übersichtlicher Form zur Verfügung zu haben.

Greifen wir nochmal die Ampel an, diesmal allerdings in vereinfachter Form. Lasst uns einfach mal nur einen Signalschirm einer Ampelanlage betrachten. Wir finden hier die Zustände Rot, Rot/Gelb, Grün und Gelb. Programmtechnisch würden wir das derzeit so abbilden:

- Bitmuster Rot ausgeben
- lange Zeit warten
- Bitmuster Rot/Gelb ausgeben
- kurze Zeit warten
- Bitmuster Grün ausgeben
- lange Zeit warten
- Bitmuster Gelb ausgeben
- kurze Zeit warten
- springe zum Anfang

Das jeweilige Bitmuster würden wir jedesmal in der entsprechenden Zeile beschreiben, um es dann auszugeben, zumindest haben wir das bisher so gemacht.

Wenn wir uns jedoch ein komplexeres Programm vorstellen, wo eine gewisse Anzahl vordefinierter Bitmuster oder auch Konstanten, an vielen Stellen ausgegeben oder verarbeitet werden sollen, dann wird das Ganze nicht nur unübersichtlich sondern auch Fehlerbehaftet. Will man ein definiertes Bitmuster ändern, so muss man das an allen Stellen machen, wo dieses Bitmuster zur Verwendung kommt, viel Freude hat man damit nicht.

Nun könnten wir uns vier Register reservieren, ihnen tolle Namen geben und während der Initialisierung mit den Bitmustern beschreiben.