Anfänger mit STK500 und Assembler

Hallo mare_crisium,
lang hats gedauert... (hatte leider nicht so viel Zeit - Sorry)
Aber nun moechte ich mein Werk wieder einmal vorstellen.
Vieles von Deinem Posting habe ich uebernommen, aber auch manches abgeaendert.
Aenderungen:
- Habe nun fuer High und Low-Flanken je ein Register rTAST_High_FLANKEN und rTAST_Low_FLANKEN(wird aber noch nicht ausgewertet)
- das marco _FLANKEN_SICHERN habe ich mit Abfragen auf HIGH und LOW erweitert
!!! wobei mir das noch nicht ganz gefaellt !!!
??? in der ISR wollte ich abfragen, ob eine Flanke anliegt und nur dann diese sichern

Code:

---

  sbrc r16,3                    ; Abfrage ob Flanke ansteht
  _FLANKEN_SICHERN(LED_TASTE_0)  ;

---

Das funktioniert nur leider nicht, musste ich feststellen.
Ist aber klar, wenn man sich anstelle des Aufrufs die Instruktionen vorstellt.
-> springe ich ja nur eine Instruktion weiter und nicht ueber das komplette macro
??? Kann ich bei rcall-Aufrufen auch ein Parameter mit uebergeben aehnlich wie beim _macro(@0) ???

- Register rLED_Update-Sprr ist ersetzt durch rIO_config
rIO_config soll mehr Infos aufnehmen als nur die Sperrung der Prozedur LED_Update
z.B. angedacht Lesen und Schreiben des EEPROM als Bit 1 und 2 usw...
- GET_HIGH_NIBBLE habe ich auch ein wenig veraendert
anstelle von
andi r16,0x0F ; unteres Nibble freistellen
kam:
andi r16,0x07 ; unteres Nibble freistellen und Flankenbit loeschen
die Zeile "andi r16,0x07" kam in der ISR im naechsten Schritt und wird somit ueberfluessig.
- den Kommentar habe ich auch angepasst und hoffe das es nun lesbarer ist - lese es am Besten in 3 Tagen noch einmal, um zu sehen ob es nun passt ;-)
// im grossen und ganzen muss ich sagen, wurde der Code durch das Auslagern der Unterprogramme wesentlich ueberschaubarer

so nun aber hier der Code:
diesmal angehaengt - wegen der 20.000er

robo_wolf,

Zitat:

---

Zitat von robo_wolf

Ist aber klar, wenn man sich anstelle des Aufrufs die Instruktionen vorstellt.
-> springe ich ja nur eine Instruktion weiter und nicht ueber das komplette macro

---

esatto, so ist es. Wenn Du wüsstest, wie oft und wie lang ich schon nach Fehlern diesen Typs gesucht habe ;-) ! Das ist einer der Gründe, derentwegen ich möglichst nur Sprünge zu Labels verwende und keine relativen.

Ja, durch die Auslagerung ist Dein Quelltext jetzt schön übersichtlich und kompakt. Gefällt mir schon richtig gut :-) . Jetzt können wir noch versuchen, Programmplatz sparen, indem wir die Tastenabfrage im Interruptdienst auf eine Schleife umstellen.

Ja, prinzipiell kann man sich ein Macro schreiben, mit dem man die Parameterübergabe z.B. in die Form "_rcall(ProzedurName,Param1Byte,Param2Byte)" bringt; z.B.:

Code:

---

.macro _rcall
  ldi r16,@1                ;
  ldi zl,low(@2)        ;
  ldi zh,high(@2)        ;
  rcall @0        ;
.endmacro

---

Im laufenden Quelltext veranlasst die Anweisung

Code:

---

_rcall PROZEDURA, 0xFE, 0xABCD
 _rcall PROZEDURB, 0xEF, 0xDCBA

---

dass Register r16 mit 0xFE, zl mit 0xCD und zh mit 0xAB geladen werden und anschliessend die Prozedur PROZEDURA aufgerufen wird. Anschliessend wird PROZEDURB mit 0xEF in r16 und 0xDCBA in zh:zl aufgerufen. Man muss nur aufpassen und die Veränderungen in r16, zl und zh nicht vergessen. Sehr gern passiert einem sowas

Code:

---

  ldi r16,0x01
  ldi zl,0x00
  ldi zh 0x00
  _rcall PROZEDURA, 0xFE, 0xABCD
  or zl,zh
  brne Nirwana

---

und man wundert sich, warum das Programm nach der "brne"-Anweisung nie nach "Nirwana" springt, obwohl es das ja tun müsste ;-) ... Das kommt davon, dass das Macro die Benutzung der Register r16, zl und zh versteckt. Umgehen liesse sich diese Gefahr, indem man die Sicherung der Register ebenfalls in das macro übernimmt, z.B. durch

Code:

---

.macro _rcall
  push r16
  push zl
  push zh
  ldi r16,@1                ;
  ldi zl,low(@2)        ;
  ldi zh,high(@2)        ;
  rcall @0        ;
  pop zh
  pop zl
  pop r16
.endmacro

---

Wenn man solche Vorsichtsmassnahmen trifft, kann man sich eine Macrosammlung aufbauen, mit der man Assemblerprogramme schreiben kann, die schon sehr einer Hochsprache ähneln.

Ausführlicherer Kommentar zu LernProgram_4g_V02 kommt später.

Ciao,

mare_crisium

Hallo are_crisium,
mit der rcall-Aufrufen hatte ich nicht gemeint ein macro mit dem Namen rcall und Parameteruebergabe sondern ein Sprung zu einem Unterprogramm.
rcall FLANKEN_SICHERN
...
FLANKEN_SICHERN:
...
ret
Die Idee dahinter war, dass ich ebenfalls wie im macro _FLANKEN_SICHERN den Parameter(LED_TASTE_0) anhaengen wollte...
Trotzdem Danke fuer diese Erklaerung.
Wollte eh schon fragen:
Wenn man ein Paramter uebergibt, dann geht es auch mit mehr...?

robo_wolf,

Zitat:

---

Zitat von robo_wolf

Hallo are_crisium,
Wenn man ein Paramter uebergibt, dann geht es auch mit mehr...?

---

ja, natürlich. Nur ist die Parameterübergabe immer implizit - damit meine ich: Der Benutzer muss vorher wissen, welcher Parameter in welchem Register steht. Solche praktischen Aufrufe, wie z.B. FLANKEN_SICHERN( LED_TASTE0), gibt's meines Wissens nur in Hochsprachen wie Pascal, aber in keinem Assemblerdialekt. - Deshalb muss man ein Macro gebasteln, um die Pascal-ähnliche Schreibweise zu simulieren.

Wenn man der Prozedur die Parameter in Registern übergeben muss, ist es hilfreich, eine Beschreibung der Prozedur zu haben, die angibt, welche Parameter in welchen Registern stehen müssen. Deshalb hat in meinen Programmen jede Prozedur so einen ausführlichen Vorspann. Andernfalls muss man erst den ganzen Quelltext der Prozedur wieder durchlesen und verstehen (;-)!) , bevor man sie benutzen kann.

Alternativ kann man der Prozedur auch Parameter übergeben, die im RAM stehen: Entweder auf dem Stack (so macht das Pascal) oder in einem Datenblock. Diese letzte Methode verwende ich auch in der angehängten Version Deines Lernprogramms. Da geht es nämlich um das Auslagern von Daten ins RAM :-) .

Dann man viel Spass!

Ciao,

mare_crisium

Hallo mare_crisium,
wie sagte das Spitzohr bei StarTrek "fazinierend".... ;-)
Hast Dir wieder extrem viel Muehe gemacht. Danke
Auf den ersten Blick, gar nicht so leichte Kost fuer mich.
Da kommen garantiert noch ein paar Fragen auf Dich zu.
Da ist schon eine banale:
Was bedeutet die Abkuerzung TASTCLT? TAST ist klar..aber CLT
Banal, ich weis aber ich verstehe es sich leichter, wenn ich es weis.
LNG - laenge so was erklaert sich von selbst.

PS. bin leider 2 Tage auf Reisen und kann mich erst am Sonntag wieder melden.

robo_wolf,

TASTCLT ist ein Dreckfuhler :-). Gemeint war TASTCTL (Tastensteuerung).

Ciao,

mare_crisium

P.S.: Wieso leider auf Reisen? Ach so: Dienstreise...

so da is er wieder...
ah TAST en C on T ro L l

.db "...LernPrgm4g1_K01.asm..."
Den Gedanken finde ich gut.
aber wo finde ich den String im Simulator wieder? oder ist es nur nach dem Deassemblieren gemeint? Wenn man de nCode warten muss?
(TBL_UEBERGANG_01: - ist klar gehe mit dem Mauszeiger ueber den Eintrag und sehe die Speicherstelle
Nun kann ich mir gut vorstellen das der String davor steht, aber wenn er das tut, kann ich ihn nicht lesen...?)

Die RAM-Einteilung noch einmal zusammenfassend:
3 Bytes pro Tasten im RAM - Die Inistialisiereung mit "0" kann man im Simulator schoen erkennen.
??? Die Belegung ist so gemeint:
TASTCTLx Byte0 TASTCTLx Byte1 TASTCTLx Byte2
xxxx xxxx xxxx xxxx xxxx xxxx
TASTCTL_FLAGS TASTCTL_MASKE

----------------------
??? kann man den Code mit den Tasten0 - 7 nicht noch etwas schrumpfen in den man

Code:

---

; Taste0 einrichten
        ldi yl,low(TASTCTL0)        ; yh:yl := Zeiger auf ersten Datenblock
        ldi yh,high(TASTCTL0)
        ldi r17,(1<<TASTE0_PIN)        ; Anschluss-Pin einstellen
        std y+TASTCTL_MASKE,r17        ;

---

ihn eine weitere Schleife packt und darin alle Tasten durchlaeuft?

Code:

---

    ldi TASTCTL_X, TASTCTL0        ; vorladen mit TASTCTL0      :=0
    ldi TASTE_X_PIN, LED_TASTE_0  ; vorladen mit LED_TASTE_0  :=0
; TasteX einrichten

TasteX_Einrichten:
    ldi yl,low(TASTCTL_X)                        ; yh:yl := Zeiger auf ersten Datenblock
        ldi yh,high(TASTCTL_X)
        ldi r17,(1<<TASTE_X_PIN)                    ; Anschluss-Pin einstellen
        std y+TASTCTL_MASKE,r17        ;
        ldi TASTCTL_X, TASTCTL_X + TASTCTL_LNG, ; Datenbereich um eine Tastenlaenge verschieben
        ldi TASTE_X_PIN,TASTE_X_PIN + 1        ; TASTE_X_PIN um 1 erhoehen
        cpi TASTE_X_PIN, TASTEN_ANZAHL          ; TASTEN_ANZAHL erreicht dann fertig
        breq TasteX_Einrichten                  ; Schleife solang durchlaufen, bis TASTEN_ANZAHL erreicht
ret

---

Das ist jetzt nur sinngemaess dahin geschrieben und kann man sicher noch viel eleganter loesen.(War eben so ein Gedanke)

Aber im nochmal zu Deinen geposteten LernPrgm4g1K01:
Bei den ersten Zeilen habe ich mich noch etwas schwer getan, aber nachdem ich alles durchgearbeitet hatte,
finde ich es doch sehr gelungen und sehr uebersichtlich.

robo_wolf,

macht Spass, Dir beim Lernen zuzugucken :-) ! - Den Versionstext „......LernPrgm4g1_K01.asm... „ findest Du wieder, wenn Du Dir den Inhalt des Flashspeichers ansiehst. Das geht entweder im Simulator (über das Menu: „View“->“Memory“ im Memory-Fenster in der Combobox „Program“ anwählen. Den String erkennst Du in der rechten Fensterhälfte; dort wird der Speicherinhalt als ASCII angezeigt) oder, wenn das Programm in einen ATmega geflasht wurde, indem Du den Inhalt des Flashspeichers in den Disassembler hochlädst.

Dieser letzte Fall tritt auf, wenn Du mal anfängst, Dir eigene Schaltungen mit ATmegas drin zu bauen und zu programmieren. Mein erstes selbstgebautes Teil war ein RS232-TWI-Umsetzer (sehr nützliches Teil ;-) ). Die Schaltung hat einen Anschluss, über den ich das Program sowohl in den ATmega8 hinunter- als auch aus dem ATmega in den PC heraufladen kann. Natürlich kann man den Käfer auch sockeln, so dass man ihn herausziehen und zum Programmieren auf das STK500 umsetzen kann. Nur kann man dann keine SMD-Bauteile verwenden. Jedenfalls habe ich das Programm schon mehrfach hochgeladen und war froh, anhand des Versionstextes die Programmversion feststellen zu können. Früher hatte ich immer kleine Zettelchen mit der Versionsnummer auf die Chips geklebt. Aber heutzutage sind die SMD-Teile dafür zu winzig ... ;-) .

Die Speicherbelegung hast Du richtig verstanden. Eigentlich werden nur 2 Bytes pro Taste benutzt. Versuch' doch mal, was passiert, wenn folgende Änderungen machst

Code:

---

.equ        TASTCTL_MASKE        = 1                ; enthält die Nummer des Pins, an den die Taste
                                                                ; angeschlossen ist
.equ        TASTCTL_LNG                = 2                ; Pro Taste 2 Bytes reserviert

---

(Nur um die Flexibilität dieser Art der Speicheraufteilung auszuprobieren ;-) ).

Die Schleife beim Einrichten der TASTCTL-Blöcke lässt sich machen; bringt aber einen Nachteil: Die Nummern der Tastenpins müssten in der Schleife berechnet werden, d.h. es muss einen festgelegten Zusammenhang zwischen Schleifenzähler und PinNummer geben (z.B. Tastennummer = Pin-Nummer). Das engt aber die Flexibilität bei der Zuordnung der Tasten ein.

Den Zeiger auf den Beginn des TASTCTL-Blocks der Taste mit der Nummer X kann man leider nicht so berechnen, wie Du es vorschlägst. Der ATMEL-Assembler erlaubt meines Wissens nicht, die Labels als Variablen zu benutzen. Er besteht darauf, dass Dein Label TASTCTL_X immer denselben Wert hat. Deine Anweisung

Code:

---

ldi TASTCTL_X, TASTCTL_X + TASTCTL_LNG, ; Datenbereich um eine Tastenlaenge verschieben

---

wird er strikt ablehnen.

Versuch' doch mal, einen Programmabschnitt in die Hauptschleife einzufügen, (vorzugsweise mithilfe einer Prozedur), die Dir zurückmeldet, ob eine Flanke ansteht (z.B. im Carry- oder im T-Flag) und welche Tastenzustände gerade anstehen (z.B. im Register r16). In diesem Zusammenhang könntest Du auch in TASTCTL ein Byte TASTCTL_LED einzuführen, das die Position des LED-Pins angibt, der die Taste darstellen soll. Dann kannst Du das Byte aus r16 direkt an die LEDs ausgeben, wenn eine Flanke ansteht. - Es ist besser, die Tastenzustände aus Bit0 des Z-Wertes abzuleiten, als bei jeder Flanke umzuschalten. - Du hast ja selbst schon gemerkt, wie man da aus dem Tritt kommen kann, wenn einmal eine Flanke unbemerkt durchwitscht.

Ciao,

mare_crisium

Hallo mare_crisium,
bin leider noch nicht all soweit gekommen.
Zum Einen war ich auf Fehlersuche zum Anderen mach ich mir noch Gedanken, wie man die Tasten-Auswertung am Besten realisiert.
Der Fehler:
Bei gedrueckter Taste ist mir aufgefallen, dass ein Tabellenindexfehler erzeugt wurde.
Der Z-Wert sprang von 0x0F auf 0x00 anstatt auf 0x07(wo er dann ohne Pegelaenderung verharren sollte).
Bei losgelassener Taste natuerlich dann auch.
Ursache:
Das Flankenbit wurde in der vorhergehenden Programmversion in TAST_UTILS_V01.asm bei "GET_HIGH_NIBBLE:" geloescht.
..und das ist in der neuen Version nicht mehr eingebunden. Aus diesem Grund gibt es nun eine TAST_UTILS_V02.asm.
Dort wird es jetzt in "NEXT_TAST_ZST:" bei der Beschraenkung der Tabelleneintraegen von ehemals 127(0x7F) auf 119(0x77) geloescht.
Nun ja, da haette ich es auch gleich ablegen koennen.. ;-)

Gedanken zur Auswertung der Tasten und Flanken:

-----------------------------------------------
Daten im R A M

Code:

---

Bsp Taste0 bei gedrueckter Taste.:
-----------------------------------------------
TASTCTL0 Byte0  TASTCTL0 Byte1  TASTCTL0 Byte2
-----------------------------------------------
TASTCTL_FLAGS                    TASTCTL_MASKE
-----------------------------------------------
0000 0010        0000 0000        0000 0001
0x02            0x00            0x01
-----------------------------------------------
0000 0100        0000 0000        0000 0001
0x04            0x00            0x01
-----------------------------------------------
0000 0110        0000 0000        0000 0001
0x06            0x00            0x01
-----------------------------------------------
0000 1111        0000 0000        0000 0001
0x0F            0x00            0x01
-----------------------------------------------
0000 0111        0000 0000        0000 0001
0x07            0x00            0x01
-----------------------------------------------
  ||              ||              || 
----------------------------
Bsp Taste0 losgelassen(high bzw. gedrueckt voraus gegangen).:
-----------------------------------------------
0000 0111        0000 0000        0000 0001
0x07            0x00            0x01
-----------------------------------------------
0000 0101        0000 0000        0000 0001
0x05            0x00            0x01
-----------------------------------------------
0000 0011        0000 0000        0000 0001
0x03            0x00            0x01
-----------------------------------------------
0000 0001        0000 0000        0000 0001
0x01            0x00            0x01
-----------------------------------------------
0000 1000        0000 0000        0000 0001
0x08            0x00            0x01
-----------------------------------------------
0000 0000        0000 0000        0000 0001
0x00            0x00            0x01
-----------------------------------------------

---

Flankenbit - Bit3
Taste gedrueckt: Bit0 :=0 bis Flanke eintritt dann 1
Taste losgelassen: Bit0 :=1 bis Flanke eintritt dann 0

-> Taste gedrueckt Bit0 :=0 -> dann Flankenbit -> Bit0 :=1 == Taste als High(geschaltet) erkannt
-> Taste nicht gedrueckt Bit0 :=1 -> dann Flankenbit -> Bit0 :=0 == Taste als Low( nicht geschaltet) erkannt

===> Auswertung mit Flankenbit auf Bit0
liegt FlankenBit an und ist Bit0 :=0 dann Tasten nicht gedrueckt
liegt FlankenBit an und ist Bit0 :=1 dann Tasten gedrueckt

------------------------------------------------
im Programm "Tasten_4g_V02" wurden die Flanken mit einem macro in der ISR in ein Register gesichert.
neu soll:
in Main-Schleife - vorangegngene ISR setzt Bit(1) - in rIO_Config fuer Erlaubnis zum FlankenBit testen - Flanke (gesetzt) - Ausgang(LED)Update - Rueckehr in Main-Schleife
in Main-Schleife - vorangegngene ISR setzt Bit(1) - in rIO_Config fuer Erlaubnis zum FlankenBit testen - Flanke (n.gesetzt)- Rueckehr in Main-Schleife
in Main-Schleife - vorangegngene ISR setzt Bit(0) - Rueckehr in Main-Schleife
// bin noch an der richtigen Ausarbeitung und hoffe es bis zum WE noch verneunftig umzusetzen
// habe dann noch weitere Plaene mit der Schaltung :-) - mir schwebt eine Menuefunktion vor, mit der das LED-Update veraendert wird

PS. irgendwie verschwinden meine Leerzeichen im Posting :-( - deswegen das RAM im Code-Schnipsel.

robo_wolf,

Du bewegst Dich schon sehr souverän in unserem Programm :-) .

Am Beispiel des Flankenbit-Fehlers kann man gut sehen, wie wichtig es war, von vornherein die Tabellen-Indexprüfung einzubauen. Nur dadurch konntest Du die Fehlerursache sofort erkennen. Hätten wir die Prüfung weggelassen, hätte das Programm plötzlich komische Z-Werte geliefert und Du hättest sehr viel mehr Zeit gebraucht, um den Fehler ausfindig zu machen. Also: Die Programmiermethode "diesen Fall brauche ich nicht zu berücksichtigen, er kann ja gar nicht vorkommen" führt zu labilen Programmen. Was passieren kann, wird früher oder später auch passieren (noch ein Korollar zu Murphy's law ;-) ).

Die andere Lösung für das Flankenbit-Problem ist eine modifizierte Übergangstabelle

Code:

---

TBL_UEBERGANG_01:
.dw 0x0010    ; Tabellenlänge
;                      T = 1          T = 0
.dw 0x0200    ; Z=0 -> Z=2,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0308    ; Z=1 -> Z=3,Flanke=0 / Z=0,Flanke=1 /
.dw 0x0400    ; Z=2 -> Z=4,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0501    ; Z=3 -> Z=5,Flanke=0 / Z=1,Flanke=0 /
.dw 0x0602    ; Z=4 -> Z=6,Flanke=0 / Z=2,Flanke=0 /
.dw 0x0703    ; Z=5 -> Z=7,Flanke=0 / Z=3,Flanke=0 /
.dw 0x0F04    ; Z=6 -> Z=F,Flanke=1 / Z=4,Flanke=0 /
.dw 0x0705    ; Z=7 -> Z=7,Flanke=0 / Z=5,Flanke=0 /
.dw 0x0200    ; Z=8 -> Z=2,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000    ; Z=9 -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000    ; Z=A -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000    ; Z=B -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000    ; Z=C -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000    ; Z=D -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0000    ; Z=E -> Z=0,Flanke=0 / Z=0,Flanke=0 /
.dw 0x0705    ; Z=F -> Z=7,Flanke=0 / Z=5,Flanke=0 /
;

---

Du siehst, ich habe sie um 8 zusätzliche Zustände erweitert. Dadurch kann man jetzt festlegen, welcher Z-Wert bei gesetztem Flankenbit angenommen werden soll - man braucht es also nicht mehr per Programm zu löschen.

Das sieht zuerst ziemlich banal aus, es steckt aber mehr dahinter: Beim Programmieren gibt's immer den Dualismus zwischen Algorithmus und Datenstruktur; so ähnlich wie der Teilchen-Welle-Dualismus in der Quantenphysik. Der erste, der auf diesen Sachverhalt hingewiesen hat, war, meines Wissens, Prof. Niklaus Wirth von der ETH in Zürich. Er hat darüber ein bis heute sehr lesenswertes Buch verfasst (Niklaus Wirth, "Algorithmen und Datenstrukturen", B.G. Teubner 1983, ISBN 3-519-02250-8. ). Er zeigt, dass man beim Programmieren immer die Wahl hat, einen bestimmten Ablauf entweder in der Datenstruktur (z.B. in Tabellen) oder als Algorithmus (z.B. einer "case"-Abfrage) abzubilden. Eigentlich habe ich die Übergangstabelle in unserem Beispiel nur eingeführt, damit Du 'mal beide Seiten kennenlernst. Welchen der beiden Wege man wählt, hängt immer von der Anwendung und vom persönlichen Geschmack ab. Ich nehme öfters den Weg über die Datenstruktur, weil komplizierte Abläufe so oft übersichtlicher und wartungsfreundlicher darzustellen sind.

Im übrigen ist das Beispiel von Prof. Wirth auch ein lehrreiches Kapitel Technikgeschichte: Er entwickelte die Programmiersprachen Lillith, Pascal, Modula und Oberon. Unter seiner Leitung genoss die Informatikforschung der ETH Zürich einen weltweit führenden Ruf. - Aber es war die Zeit, als in Deutschland allen Ernstes eine Diskussion über die Einführung einer "Computersteuer" geführt wurde und die Mittel für die Informatikforschung (auch in Deutschland) stark eingeschränkt, wenn nicht gar zusammengestrichen wurden. - Na, schlussendlich war spätestens nach seiner Emeritierung die Informatikforschung in der Schweiz so gut wie nicht mehr existent. Genau wie in Deutschland zog man es vor, einmalige Gelegenheiten gemütlich zu verschlafen 8), mit den bekannten Folgen.

Bin gespannt auf Deine nächste Version!

Ciao,

mare_crisium