Druckbare Version
Hallo mare_crisium,
habe mir gestern abend noch die 1.Version geladen. Bin aber nicht mehr dazu gekommen alles zu testen.
Werde mir gleich einmal die neue Version laden und sie mir zu Gemuete fuehren. Vorab erst einmal wieder ein grosses Daaaankeschoen.
Hallo mare_crisium,
habe mir nun mal alles im Simulator angeschaut.
Und bin gleich beim Start auf Probleme gestossen.
Was bewirkt ".device ATmega8515".Code:.device ATmega8515
.include "m8def.inc"
Durch die inc vom mega8 wurde sofort beim Sprung in eine Sub ein Fehlermeldung ausgegeben. ->nicht initialisierter Stack.
Mein Simulator simuliert den Mega8515 der hat nur halb so viel Speicher, wie der Mega8.
Habe deswegen die inc auf Mega8515 umgestellt.
Dann lief es auch normal durch.
melde mich erst wieder nach den Osterfeiertage - bin wieder mal auf Reisen
wuensche ein Frohes Osterfest
robo_wolf,
die beiden Anweisungen sind natürlich Kokolores. Wahrscheinlich sind die mir da 'reingerutscht, weil ich mit dem Projektmanager beim Anlegen der neuen Version nicht aufgepasst hab ;-). Einfach beide Zeilen löschen und durch
ersetzen. Dann klappt's wirklich... :-).Code:.include "m8515def.inc"
Geniess Ostern!
mare_crisium
mare_crisium,
will mich heute endlich mal wieder melden.
Habe nun Deinen Code schon mehrmals durch den Simulator getickert.
Leider ist bei mir der Groschen noch immer nicht am Boden angekommen.
Aber ich arbeite dran... ;.-)
Kann aber auch noch nicht 100%ig sagen woran das genau liegt.
Eventuell seh ich auch nur den Wald vor lauter Baeumen nicht.
Bin gerade dabei den Ablauf aus dem Code mit meinen Worten heraus zu schreiben, um Ihn letzlich komplett zu verinnerlichen.
Versuche bis heute Abend damit fertig zu sein.
robo_wolf,
nur nicht hetzen :-) ! Ich habe ja auch ziemlich viel daran herumgetüftelt.
Angefangen hatte ich mit dem naheliegenden Ansatz: Einem Algorithmus, der brav die verschiedenen Stadien des Einschaltens der Menusteuerung und später das Verhalten im eingeschalteten Zustand durchbuchstabiert.
Diese Lösung gefiel mir aber nicht, weil sie in einen Wust von Fallunterscheidungen ausuferte. Besonders verwirrend fand ich, dass während des Einschaltvorgangs einmal die Tastenflanke das auslösende Ereignis ist, und dann wieder das Ablaufen eines Warteintervalls. Auch die Zeitintervalle, die überwacht werden müssen, unterscheiden sich, abhängig vom Zustand der Menusteuerung: Beim Einschalten sind es T0, T1 und T2. Nachdem die Steuerung eingeschaltet ist, braucht man nur noch die Totmannzeit T2 überwachen.
Wie sich nach einigem Herumprobieren herausstellte, wird das Ganze übersichtlicher, wenn man die Zeitmessung (T0 -> T1 ->T2) immer gleich ablaufen lässt; sie also davon unabhängig macht, ob die Menusteuerung eingeschaltet ist oder nicht. Ganz entscheidend ist es, die Zeitmessung bei jeder Tastenflanke neu zu starten: Eine neue Tasteflanke wird dann durch das Zurückspringen des Zeitzählers auf Null angezeigt, bzw. dadurch, dass T0 (oder T1) abläuft. Dadurch braucht man nur noch die Zeitmessung zu überwachen, nicht die Tastenflanken.
Das ist die wesentliche Vereinfachung ;-).
Um festzustellen, was der Bediener mit seiner Eingabe bezweckte, braucht man nur noch bei T0 bzw. T1 den statischen (nicht den dynamischen) Zustand der Tasten abfragen: Die Tatsache, dass T0 bzw. T1 erreicht werden, zeigt ja schon an, dass mindestens eine der Tasten neu betätigt wurde. Bei Erreichen von T2 geht's immer auf direktem Weg zurück nach "Los" (Schrittnummer 0x00).
Viel Spass beim Nachtüfteln :-).
Ciao,
mare_crisium
Hallo mare_crisium,
je intensiver ich mich damit beschaeftige, um so mehr bewegt sich der Groschen dem Boden. ;-)
... aber der Kopf qualmt schon ein wenig... - macht aber nichts -
Meine Frau liest einen Krimi und finde es eben spannend mich durch den Code zu arbeiten.
Trotzdem bitte ich Dich mal das Untere zu lesen und ggf. zu korrigieren.
- bin aber noch nicht ganz fertig, mit dem Durcharbeiten und Verstehen -
Den kompletten "MNU8CTL_HANDLER" habe ich noch nicht durch...
Frage zum Ablauf:
In der Doku auf Seite 1 "Jedes Menu hat 8 Menupunkte, die durch Betätigen eines einzelnen Tasters
(Taste0 bis Taste7) ausgewählt werden."
-->> die Idee war ein Menue, in dem 8 Menuepunkte erkannt werden koennen. Meintest Du es so? oder meinst Du 8 Menues mit 8 Menuepunkten?
Doku mare_crisium(wie ich es verstanden habe - bitte verbessere mich, wenn es anders gemeint war):
A.0 Abfrage auf Ta0 oder Ta7 log 1
Rueckgabe 0 -> A.0
Rueckgabe 1 -> A.1
A.1 1.Abfrage auf Ta0 oder Ta7 log 1
Rueckgabe 0 -> A.0
Rueckgabe 1 -> 2. Abfrage
2.Abfrage auf Ta0 oder Ta7 log 1 nach Ablauf von T1
Rueckgabe 0 -> A.0
Rueckgabe 1 -> A.2
A.2 Abfrage aller Tasten(0-7)
Rueckgabe := Tasten-ID
Rueckgabe mehrere Tasten IDs = Fehlerfall ->Signalisierung + Start von A.2
T2 abgelaufen -> A.0
ICALL hatte ich bis jetzt noch nie verwendet - nun weiss ich, was es damit auf sich hat. :-)
############# meine Gedankenstuetze
Ablauf der Menuesteuerung nach mare_crisium
Bsp.:
MNU8CTL_CREATE:Code:Datenspeicher(Datensegement)
MNU8CTL = RAM_Anfang = 0x60
MNU8CTL_LNG = 12 = 0x0C (Byte im Datenspeicher reserviert)
MNU8CTL_TBL_LNG = 16 = 0x10 (Laenge der Zustandstabelle)
aktuelle Zustandsnummer der Menusteuerung
MNU8CTL_FLAGS = 0 (Flags)
MNU8CTL_AKTZUST = 1 (aktueller Zustand)
MNU8CTL_TASTZUST = 2 (Tastenzustand)
MNU8CTL_ZYTZHLRL = 3 (Zaehler-Adresse-Low)
MNU8CTL_ZYTZHLRH = 4 (Zaehleradresse -High)
MNU8CTL_TBLADRL = 5 (Adresse Zustandstabelle -Low)
MNU8CTL_TBLADRH = 6 (Adresse Zustandstabelle -High)
MNU8CTL_MAXNR = 7 (maximale Anzahl Datensaetz in Zustandstabelle)
-----------------------------------------------------------------------------------------------------------------------------------
0x60 0x61 0x62 0x63 0x64 0x65 0x66 0x67 0x68 0x69 0x6A 0x6B
-----------------------------------------------------------------------------------------------------------------------------------
y = MNU8CTL X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_LNG X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_FLAGS X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_AKTZUST X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_TASTZUST X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_ZYTZHLRL X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_ZYTZHLRH X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_TBLADRL X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_TBLADRH X
-----------------------------------------------------------------------------------------------------------------------------------
y+MNU8CTL_MAXNR X
-----------------------------------------------------------------------------------------------------------------------------------
reserve X X X X
-----------------------------------------------------------------------------------------------------------------------------------
im Datenspeicher ab 0x60 mit einer Laenge von MNU8CTL_LNG :=16 Byte reservieren und mit 0 fuellen
in Speichertstelle y+MNU8CTL_MAXNR(0x67) die Anzahl der max. Zustaende speichern
in Speicherstellen y+MNU8CTL_TBLADRL und y+MNU8CTL_TBLADRH den Zeiger auf die Zustandstabelle speichern(0x65 und 0x66)
MNU8CTL_ZYTRESET:
im Datenspeicher an y+MNU8CTL_ZYTZHLRL(0x63) und y+MNU8CTL_ZYTZHLRH(0x64) den Wert von T0 speichern
MNU8CTL_SETTASTEN:
im Datenspeicher an y+MNU8CTL_TASTZUST(0x62) die statischen( simulieret Tasten) Zustaende der Tasten speichern
MNU8CTL_ZYTCOUNT:
aus Datenspeicher an y+MNU8CTL_ZYTZHLRL(0x63) und y+MNU8CTL_ZYTZHLRH(0x64) den Wert von T0 lesen
MU8CT_ZTCT04:
im Datenspeicher an y+MNU8CTL_ZYTZHLRL(0x63) und y+MNU8CTL_ZYTZHLRH(0x64) den decr. Wert von T0 speichern
MNU8CTL_HANDLER:
1.Byte low =(0x18) und 2.Byte high =(0x01) aus Zustandstabelle lesen - Zeiger auf die auszuefuehrende Prozedur (icall)???? - zusammen das DoppelByte 0x0118
3.Byte low =(0x00) und 4.Byte high =(0x00) aus Zustandstabelle lesen - Folgezustand
icall ruft Prozedur welche an FlashAdresse (0x0118) vom Z-Zeiger auf
bis zum naechsten MAIN-Aufruf
##################
robo_wolf,
na, ich schliesse aus Deinen Fragen, dass der Groschen nicht mehr weit hat :-) !
Ja, bei der Beschreibung des Übergangskriteriums von A.0 nach A.1 habe ich in der pdf-Datei einen Fehler gemacht und eine Erklärung unterschlagen. Beides habe ich in der Version _V09 ausgebessert.
Zuerst ist das Kriterium für A.0->A.1 die Tatsache, dass von Ta0 oder Ta7 mindestens eine Tastenflanke ansteht (nicht, wie in Version _V08 geschrieben "keine der beiden"). Nachdem mir aber die Idee gekommen war, die Zeitmessung bei jeder Tastenflanke neu zu starten, habe ich das Übergangskriterium modifiziert, ohne das in der doku deutlich zu machen (ist jetzt in _V09 ergänzt). Und zwar genügt es ja, wenn die Zeitmessung neu begonnen und T0 erreicht hat, zu überprüfen, ob zu diesem Zeitpunkt Ta0 und Ta7 betätigt sind. Wenn das nämlich so ist, dann wurde eine von beiden zur Zeit t=-T0 neu betätigt. Fehlt zu diesem Zeitpunkt eine von beiden, oder sind ausser den beiden noch andere Tasten betätigt, geht's zurück nach A.0.
Deine Aufstellung muss also so aussehen:
A.0 Abfrage auf Ta0 und Ta7 nach Ablauf von T0 log. 1
Resultat "Nein" -> A.0
Resultat "Ja" -> A.1
A.1 Abfrage auf Ta0 und Ta7 nach Ablauf von T1 log. 1
Resultat "Nein" -> A.0
Resultat "Ja" -> A.2
Die Abfrage in A.2 hast Du so richtig dargestellt. Auch die Kurzbeschreibungen der Prozeduren ist so richtig. Nur bei MNU8CTL_ZYTCOUNT wird nicht nur der Wert von T0 heruntergezählt sondern auch der von (T1-T0) und der von (T2-T1). Bei MNU8CTL_HANDLER wird der Zeiger auf die auszuführende Prozedur aus den ersten beiden Bytes nach zh:zl geladen und dann mit der "icall"-Anweisung angesprungen, genau so, wie Du's beschreibst. Die Prozedur entscheidet mit dem Wert, den sie im T-Flag zurückgibt, welcher Folgezustand eingestellt werden soll. Das hast Du auch richtig.
Ciao,
mare_crisium
mare_crisium,
es geht immer noch langsam, aber weiter... :-)
schau mal, das kann doch nicht stimmen?
[Code]
MU8CTL_ZTCT02:
; ZYTZUST > 1
cpi r18,0x02 ;ist ZYTZUST = 2?
brne MU8CTL_ZTCT03
[Code/]
muss es nicht so heissen?
[Code]
MU8CTL_ZTCT02:
; ZYTZUST > 1
cpi r16,0x02 ;ist ZYTZUST = 2?
brne MU8CTL_ZTCT03
[Code/]
habe mal den kompletten Ablauf ohne Eingriff bzw. Bit-Manipulation aufgeschrieben(in Main "ser r16":
######
keine Taste gedrueckt:
| A.0
V
Zaehler an Adresse:(y+MNU8CTL_ZYTZHLRL) wird von 0x03 auf 0x00 herab gezaehlt
-> aktueller Zustand an Adresse:(y+MNU8CTL_AKTZUST) von 0x00(Zyt 0) auf 0x01(Zyt 1) gesetzt und Zaehler an Adresse:(y+MNU8CTL_ZYTZHLRL) auf T1-T0 = 5-3 = 0x02 gesetzt
| A.1
V
Zaehler an Adresse:(y+MNU8CTL_ZYTZHLRL) wird von 0x02 auf 0x00 herab gezaehlt
-> aktueller Zustand an Adresse (y+MNU8CTL_AKTZUST) von 0x01(Zyt 1) auf 0x02(Zyt 2) gesetzt und Zaehler an Adresse:(y+MNU8CTL_ZYTZHLRL) auf T2-T1 = 8-5 = 0x03 gesetzt
| A.2
V
Zaehler an Adresse:(y+MNU8CTL_ZYTZHLRL) wird von 0x03 auf 0x00 herab gezaehlt
-> aktueller Zustand an Adresse (y+MNU8CTL_AKTZUST) von 0x03(Zyt 3) wird erneut mit 0x03 geladen
|
V
Totmannzeit erreicht - Zustaende bleiben nun fix
######
// bin ich noch auf den richtigen Weg?
als Naechstes moechte ich in der Main r16 mit "0x01", "0x02", "0x80", "0x81", "0x82" laden...
robo_wolf,
ja, die Anweisung muss "cpi r16,0x02" heissen, nicht "cpi r18,0x02". Hab' die korrigierte Datei neu hochgeladen.
Den Ablauf, den Du in Deinem Posting darstellst, bekomme ich im Simulator auch. Er belässt den Zustand der Menusteuerung bei "0x00", weil ausser Ta0 und Ta7 noch mehr Tasten betätigt sind (simuliert). Am Ende landet der Ablauf im Zustand 0x03, d.h. Totmannzeit abgelaufen. Von hier aus geht's nur weiter, wenn eine neue Tastenflanke ansteht.
Ja, bist noch auf der richtigen Fährte :-) !
Ciao,
mare_crisium
mare_crisium,
die Menu8Stg habe ich so weit verstanden.
Aber warum laesst Du den Code immer bis zur Totmannzeit laufen?
Wenn keine Taste gedrueckt ist, kann der Code doch schon vorher abgefangen werden.
Was spricht gegen diesen Ablauf:
############
keine Tastenflanke erkannt (T-Flag nicht gesetzt) / A.0
! ->
keine Erkennung von Tasten 0 und 7 / kein A.1
Tastenflanke erkannt (T-Flag gesetzt)
! ->
Erkennung ob Taste 0 und 7 (0x81) anstehen / A.1
in der Zeitnachfuehrung immer wieder auf (0x81)ueberpruefen
-> wenn (0x81) vor Ablauf der Zeitnachfuehrung nicht mehr ansteht -> dann wieder zuzrueck zu A.0
-> wenn (0x81) am Ende der Zeitnachfuehrung noch antsteht -> dann in Tastenauswertung fuer Menuepunkt A.2
! ->
Tasten fuer Menuepunkte erkennen / A.2
in der Zeitnachfuehrung auf Tasten testen
-> wenn vor Ablauf der Totmannzeit keine einzelne Taste erkannt wurde fuer Menuepunkt erkannt wurde -> dann wieder zurueck zu A.0
-> Tasten erkannt -> "Menuepunkt gestetzt" -> dann zureuck zu A.0
############
Aber wahrscheinlich hast Du hier in Deinen Gedanken schon viel weiter gedacht als ich es ueberschaue... :-)
Du hast sicher nicht ohne Grund Platz fuer Erweiterungen gealssen ... ODER?
Aber wieder viel dazu gelernt und das ist wichtig,. ......wenn es auch etwas laenger gedauert hat.
Das Arbeiten mit Zeigern und das Verwenden des SRAM und Flash ist mir nun, Dank Deiner Hilfe, nicht mehr so fremd.
Guten Morgen, robo_wolf,
ja, es hat mich beim Schreiben des Programms auch öfter in den Fingern gejuckt, den Zeitzähler früher wieder zurückzusetzen. - Aber: Wenn keine oder nur ungültige Tasten betätigt werden, dann ist es nur logisch, den Automaten bis zum Zustand "Totmannzeit erreicht" laufen zu lassen. Denn genau das ist es ja, was passiert ist: Es gab keine rechtzeitige gültige Eingabe. - Ausserdem ist es einfacher, wenn es nur ein Ereignis gibt, das den Zeitzähler zurücksetzt.
Aber mein Programmentwurf ist nicht er einzig mögliche und sicher auch nicht der Beste ;-) ! Deshalb: Lass' mal die Finger wirbeln und versuch's mal so zu machen, wie Dir's vorschwebt! Der Vergleich konkurrierender Programmentwürfe ist eine sehr wichtige Quelle für Programmiererfahrung - besonders, wenn man die Entwürfe selbst geschrieben hat :-). Also, keine Hemmungen, meiner Mithilfe kannst Du gewiss sein.
Darauf kam's mir an! Freut mich :-) .Zitat:
Zitat von robo_wolf
Ciao,
mare_crisium
Guten Abend mare_crisium,
probiere schon in so mancher freien Minute, den Code so umzuschreiben, dass es meinen Vorstellungen entspricht. ... dauert noch :-)
Dabei ist eine Frage aufgetaucht:
Das Simulieren der Tastenflanke geschieht mittels T-Flag.
Damit wird ein Zeit-Reset gemacht oder man kommt damit wieder aus der Totzeit raus.
Aber...
eine Tastenflanke ensteht auch beim Druecken der Tastenkombi"0_7" ..
--- Im momentanen ProgrammCode wuerde immer ein Reset stattfinden.
Oder simulierst Du die Zustaende anders? Auch komme ich nicht in MNU8CTL_CHKTASTEN beim simulieren.
Kannst Du mir noch einen Tipp geben?
Guten Morgen, robo_wolf,
ja, die Tastenflanke setzt immer nur den Zeitzähler zurück. -
Aber gehen wir doch mal den Fall „Ta0 und Ta7 betätigt“ durch. Dabei mache ich's wie Du und verwende für die Zustände der Menusteuerung (Bits2 und 3 des Zustandsbytes) statt der 0b00 den Buchstaben A, statt 0b01 das B usw. - Also, los geht's:
Angenommen, Ta0 wird zuerst betätigt. Die Tastenflanke (T=1) setzt den Zeitzähler zurück, der neue Zustand ist A.0.
Der Zeitzähler erreicht T0, bevor Ta7 betätigt wird: Die Prüfung des statischen Tastenzustands (CHKT07) liefert ein "Nein" (T=0). Der neue Zustand der Menusteuerung bleibt A. Der Zeitzähler läuft weiter, die Zustände laufen über A.1 bis A.3. Im Zustand A.3 bleibt bis eine neue Tastenflanke kommt.
Jetzt wird Ta7 betätigt. Die Menusteuerung ist noch in Zustand A.X. Der Zeitzähler springt auf 0 zurück und fängt an, T0 abzuzählen; der neue Zustand ist A.0.
Wenn er jetzt T0 erreicht, liefert die Prüfung des Tastenzustandes mit CHKT07 ein „Ja“ (T=1) und - voila - die Menusteuerung springt in den Zustand B.1. Der Zähler wird mit der Differenz (T1-T0) geladen und fängt an abzuzählen.
Wird jetzt noch eine Taste betätigt. Der Zeitzähler wird zurückgesetzt, der neue Zustand ist B.0. Erreicht der Zeitzähler T0, dann liefert die Tastenprüfung ein „Nein“, weil mehr als Ta0 und Ta7 betätigt sind, der neue Zustand ist A.1 und die Steuerung läuft weiter bis A.3.
Wird keine weitere Taste betätigt, dafür aber Ta0 oder Ta7 losgelassen, dann liefert die Prüfung nach Ablauf von T1 (Zustand B.1) ein „Nein“ und wir landen in Zustand A.2 und die Reise geht weiter bis A.3.
Wenn aber beim Erreichen von T1 sowohl Ta0 als auch Ta7 weiterhin betätigt sind, dann liefert CHKT07 ein „Ja“ und die Steuerung geht in den Zustand C.2 über. Ab jetzt wartet sie auf Eingaben, die den gewünschten Menupunkt auswählen.
Angenommen, Ta2 wird vor Erreichen der Totmannzeit betätigt. Das löst eine Tastenflanke aus, die den Zeitzähler wieder zurückgesetzt (das hast Du, glaub' ich, in Deiner Simulation vergessen ;-) ). Der neue Zustand ist C.0. Nach Ablauf von T0 wird der statische Tastenzustand geprüft (CHK_TASTEN). Je nachdem was dabei herauskommt muss jetzt die gewünschte Aktivität angestossen werden. Der Zeitzähler läuft derweil weiter. Wenn er die Totmannzeit erreicht, geht die Steuerung in den Zustand A.3 über und wartet auf die nächste Tastenflanke.
Alles klar?
mare_crisium
mare_crisium,
wie Du editiert die Bits 2 und 3 des Zustandbyte bei der Simulation?
Sollten die Zustaende nicht selbst errechnet bzw. vom PC zugewiesen werden?
Die Simulation fuer die Ta0 und T7 Erkennung hatte ich bisher so gestartet:
Beim Initialisieren alle Prozeduren einmal komplett durch
Der RAM schaut dann so aus:
00 00 FF 02 00 9C 00 10
Dann setzen ich fuer Ta0 und Ta7 in der MAIN r16 auf 0x81 setze das T-Flag und los.
00 00 81 03 00 9C 00 10
Erwarten wuerde ich dann vom Programm das es bis zu CHK_Tasten kommt...
... ich bin auf dem Holzweg ODER???
hier noch einmal in einer anderen Darstellung den gewuenschten Programmablauf:
Code:>>> Zeitstrang >>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> Tastenflanke >>>
<<< nicht erkannt
>>>>>>>>> erkannt >>>>>>>>>>>>>>>>>>>>>>>>
-------------->>> Abfrage auf Ta0 und Ta7
<<<<<<<<<<<<<<<<< nicht erkannt
-------------->>> erkannt>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<< kuerzer 3 Zeiteinheiten
-------------->>> erkannt 3 Zeiteinheiten >>>>>>>>>>>>>>>>>>>>>> Menue erreicht
------------------------------------------------------------------>>> Totzeit 5 Zeiteinheiten gestartet >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Ta0 und Ta7 nicht losgelassen <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Totmannzeit abgelaufen <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
------------------------------------------------------------------>>> Einzeltaste erkannt >>>>
------------------------------------------------------------------------------------------>>>> Menuepunkt gewaehlt
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
robo_wolf,
nee, nee Du bist schon richtig ;-) ! Gehen wir anhand des RAM vor:
Wie Du schreibst, steht im RAM nach der Tatenflanke und wenn Ta0 und Ta7 betätigt sind
00 00 81 03 00 9C
So, jetzt musst Du das Programm einfach durchlaufen lassen. Es geht dann von selbst in den Zustand B.1 über. Im RAM steht dann
00 05 81 02 00 9C
05 ist das Zustandsbyte = 0b0101. Das bedeutet: Zeitzähler hat bis T0 gezählt. Deshalb steht in Bits1 und 0 die 0b01. Die Menusteuerung (Bits3 und 2) ist im Zustand 01. In Deiner Nomenklatur ist das Zustand B.1. Das Tastenbyte 0x81 bedeutet, dass weiterhin Ta0 und Ta7 betätigt sind.
Lass' das Programm einfach weiterlaufen. Der Zeitzähler zählt die Differenz T1-T0 ab. Wenn er die Null erreicht, wird er mit 0x03 nachgeladen. Bevor die Anweisung "rcall MNU8CTL_HANDLER" ausgeführt wird, steht nun im RAM
00 06 81 03 00 9C
Das Zustandsbyte ist jetzt 0x06, das entspricht B.2. 0x81 bedeutet, dass Ta0 und Ta7 immer noch betätigt sind. Jetzt wird die Anweisung
"rcall MNU8CTL_HANDLER" ausgeführt. Dabei wird "MNU8CTL_CHKT07" aufgerufen. Weil Ta0 und Ta7 noch immer betätigt sind, geht die Menusteuerung in den Zustand 2, also C über. Der RAM-Inhalt ist deshalb
00 0A 81 03 00 9C
Das Zustandsbyte ist 0x0A. Bits3 und 2 enthalten 0b10, also ist die Menusteuerung im Zustand 2 = C. Der Zeitzähler ist gerade mit derm Abzählen von T1 fertiggeworden, also steht in Bits1 und 0 die 0b10. Er fängt jetzt an, die Differenz T2-T1 abzuzählen.
Das ist genau der Zustand, in dem die Ta0 und Ta7 wieder losgelassen werden dürfen und Menu-Auswahl-Taste betätigt werden muss. Sagen wir mal, Ta2 wird betätigt. Also in der Simulation das T-Flag setzen (es wurde ja eine neue Taste betätigt, das Flankenbit steht also an) und in r16 musst Du 0x02 schreiben.
Wg. der Tastenflanke führt das Programm die Anweisung "rcall MNU8CTL_ZYTRESET" aus. Nachdem auch "rcall MNU8CTL_HANDLER" ausgeführt ist, steht im RAM
00 08 02 03 00 9C
Das Zustandsbyte ist 0x08, was dem Zustand C.0 entspricht. Das Programm läuft weiter bis T0 abgezählt ist, Im RAM steht jetzt
00 09 02 00 00 9C
Anschliessend wird vom "MNU8CTL_HANDLER" die Prozedur "MNU8CTL_CHKTASTEN" aufgerufen und die gewünschte Aktion angestossen. Im RAM steht danach
00 09 02 02 00 9C
So weit einverstanden ;-) ?
mare_crisium
Guten Morgen mare_crisium,
jetzt ist alles klar.
Wir sind teilweise unterschiedlicher Meinungen bezueglich der Tastenflanke gewesen. Ausserdem habe ich den nachfolgenden Zustand von 0x0A nicht bedacht. Ta0 und Ta7 3 sec erkannt - aber weiter gedrueckt gehalten. Habe hier auch das Posting vorher erweitert.
Guten Morgen mare_crisium,
habe nun endlich den Code so weit, dass ich ihn posten kann.
Aenderungen:
Ohne Tastenflanke - kein kompletter Durchlauf bis zur Totmannzeit
Einzeltastenabfrage zur Erkennung, ob nur eine Taste zur Auswahl ansteht.
Nach Tastenerkennung in CHKTASTEN ist jetzt eine Programmunterbrechnung eingebaut, die auf Anfangsbedingungen setzt.
Ergebnisaufnahme in Datensegment zur weiteren Verarbeitung abgelegt.
Menuesignalisierung eingepflegt-tut aber noch nichts.
Wenn ich mir das Programm so anschaue, bin ich nicht 100ig zufrieden damit.
Es gibt noch viel Optimierungspotential... :-(
mare_crisium,
wie ich schon geschrieben habe, mache ich mir noch weitere Gedanken zur Verbesserung.
Was haelst du davon, bespielsweise die Einzeltastenabfrage und /oder die Abbruchfunktion mit in die Tabelle einzubauen?
Kann man die Spalteneintraege in 3 oder gar mehr erweitern.. die natuerlich dann in dem Handler mit ansprechen?
z.B.:
.dw .dw MNU8CTL_NOP, 0x0000 ; MNU8CTL_TU_WAS; 0 ->
Hatte mir auch in die Richtung Gedanken gemacht:
Ein Umstricken der Tabelle und den zeitlichen Verlauf mit einbauen(bissel sehr gewagt - ich weiss)
Code:.dw MNU8CTL_NOP, 0x0000 ; 0 -> Tastenflanke erkannt
; Menusteuerung im Zustand 1 -> 3Zeiteinheiten
.dw MNU8CTL_CHKT07, 0x0001 ; 1 ->
.dw MNU8CTL_CHKT07, 0x0001 ; 2 ->
.dw MNU8CTL_CHKT07, 0x0011 ; 3 -> MenueEinstieg erreicht
; Menusteuerung im Zustand 2 -> 5Zeiteinheiten
.dw MNU8CTL_CHKTASTEN, 0x0002 ; 4 ->
.dw MNU8CTL_CHKTASTEN, 0x0002 ; 5 ->
.dw MNU8CTL_CHKTASTEN, 0x0002 ; 6 ->
.dw MNU8CTL_CHKTASTEN, 0x0002 ; 7 ->
.dw MNU8CTL_CHKTASTEN, 0x0022 ; 8 -> Totmannzeit erreicht
; Menusteuerung im Zustand x (vorerst unbenutzt)
.dw MNU8CTL_NOP, 0x0000 ; 9 ->
.dw MNU8CTL_NOP, 0x0000 ; 10 ->
.dw MNU8CTL_NOP, 0x0000 ; 11 ->
.dw MNU8CTL_NOP, 0x0000 ; 12 ->
.dw MNU8CTL_NOP, 0x0000 ; 13 ->
.dw MNU8CTL_NOP, 0x0000 ; 14 ->
.dw MNU8CTL_NOP, 0x0000 ; 15 ->
.equ MNU8CTL_TBL_LNG = 16 ;
robo_wolf,
hab's mir gerade runtergeladen, melde mich demnächst.
Ciao,
mare_crisium
robo_wolf,
so, hier sind meine Kommentare zu Deinem Programm. Mein Eindruck ist, dass Du ruhig die Zustandstabelle ändern solltest ;-) . Ich hab' Dir ein paar Vorschläge dazu in den Quelltext geschrieben.
Ciao,
mare_crisium
Guteen Morgen mare_crisium,
werde ich gleich mal durcharbeiten.
Vielen Dank ersteinmal.
Hallo mare_crisium,
Deine Kritiken den Programmabbruch habe ich verstanden.
Im fogenden Kommentar schreibst Du, das Nachteil sei, nur eine Tastennummer zu speichern.
??? Warum sollten mehrere Tastennummern abgelegt werden? Fuer die Menueauswahl brauche ich doch nur eine Nummern ,die die Aktion der Tasten bestimmt?
!!! Denken wir da in zwei Richtungen.. oder ueberseh ich wieder etwas..?
Das Thema mit der Warteschlange liest sich spannend.
- kommen garantiert noch mehr Fragen auf Dich zu :-)
Auch der neue Handler "MNU8CTL_4HANDLER" gefaellt mir.
Guten Abend, robo_wolf,
hier habe ich eine neue Version _04j, die aus _04i abgeleitet ist. Sie hat jetzt ein neues Modul "STACK8_V01.asm", das Software-Stacks bereitstellt. Man kann in seinem Hauptprogramm mehrere davon einbauen.
In _04j dient der "MENUSTACK" dazu, die Nummern der betätigten Menutasten zwischenzuspeichern. Die Gründe dafür sind folgende:
Man kann die Verarbeitung der Menutasten in die MAIN-Schleife verlagern und braucht nicht alles während des Timer-Interrupts zu erledigen. Ausserdem kommt es oft vor, dass jemand die Menutasten so schnell hintereinander betätigt, dass die erste noch nicht abgearbeitet ist, wenn die zweite gedrückt wird. Ohne Zwischenspeicherung ginge die zweite verloren. Noch ein anderer Grund ist, dass auf diese Weise die Verarbeitung der Menutasten von der Menusteuerung abgekoppelt wird. Das Modul "MENU8STRG_Vxx" braucht nichts über die Funktionen zu wissen, die die Tasten auslösen. Das Modul bleibt dadurch universell verwendbar ;-) .
Ciao,
mare_crisium
robo_wolf,
nach der ganzen Testerei wird's mal wieder Zeit, das eigentliche Ziel ins Auge zu fassen :-). Deshalb habe ich hier eine Version (LernPrgrm_04k) angehängt, die eigentlich alles können sollte: Tasten entprellen, die Menuaktivierung steuern und die angewählten Menupunkte ausführen.
Dazu habe ich den Timer2-Interrupt wieder aktiviert. Die Zeitkonstante habe ich von Dir übernommen (0,1s). Die Zeitintervalle für die Menuaktivierung habe ich provisorisch auf
T0 = 0,1s, T1 = 3s und T2 (Totmannzeit) = 5,1s eingestellt.
Wenn wir beim Austesten alle Fehler bemerkt und beseitigt haben ;-) müsste das Ding funktionieren... Probier's doch mal!
Ciao,
mare_crisium
Hallo mare_crisium,
langsam langsam :-)
Bin gerade noch beim Durchsehen des vorherigen Postings... da kommt schon das Naechste.
Im vorigen hattest Du .include "Menu8Strg_V04.asm" eingebaut.
Das war sicher ein Tippfehler.
In der Endversion ist es dann wieder _V03.
Auf jeden Fall erst einmal wieder ein grosses Danke an Dich zurueck.
Habe nun einiges zum Aufarbeiten .. :-)
mare_crisium,
bin nun Dein Programm durchgegangen.
Eine Sache ist mir gleich zu Beginn aufgefallen.
Der Mega8515 hat keinen Timer2.
In irgendeiner Version der letzten Postings hast Du die Interrupttabelle vom Mega8 eingebaut.
Muss ehrlich gestehen, ich habe das in Deinem letzten Posting zwar gelesen(Dazu habe ich den Timer2-Interrupt wieder aktiviert.),
mehr ueberlesen, aber beim 1.TimerCompare ist es mir dann aufgefallen.
Wenn sich Stoplersteine immer so leicht finden lassen wuerden.... :-)
Eine kleine Aenderung habe ich dann noch hier vorgenommen. Bringt nicht wirklich viel.. ein paar Takte
Der MenuStack ist ja ne schoene Sache. Aber waere es nicht einfacher die Tasterkennung in einem Register dezimal abzulegen?Code:STACK8_CREATE:
push r25
in r25,SREG
push r16
push r17
push xl
push xh
; reservierten Speicherbereich mit Nullen füllen
mov xl,r16
clr xh
adiw xh:xl,STACK8CTL_LNG
clr r17
STCK8_CRT00:
; 20100503 vor STCK8_CRT00 geschoben clr r17
st z+,r17
sbiw xh:xl,0x0001 ; Byte-Zähler abzählen
brne STCK8_CRT00 ; Sprung, wenn noch nicht fertig
; Zeiger wieder auf erstes Byte von STACK8CTL zurückstellen
sbiw zh:zl,STACK8CTL_LNG ; Länge des Steuerblocks subtrahieren
sub zl,r16
clr r17
sbc zh,r17 ; Kapazität des Stacks subtrahieren
; Stackkapazität speichern
std z+STACK8CTL_CAP,r16 ; Kapazität speichern
pop xh
pop xl
pop r17
pop r16
out SREG,r25
pop r25
ret
Was wuerde dagegen sprechen? - Ich meine als Lernobjekt ist die Sache mit dem Stack ja suuuuper.
... kann es natuerlich sein, dass Du in Deinem Hinterkopf schon weiter geplant hast, als ich es bisher ueberschauen kann?
robo_wolf,
huuch! Das mit dem Timer2 ist natürlich eine böse Falle. Ich hätte erwartet, dass der Assembler auf so einen groben Fehler hinweist. Wie machst Du's jetzt?
Deine Einsparmassnahme beim Stack ist berechtigt. Aber was meinst Du mitMan kann nie vohersagen, wann oder wie schnell hintereinander der Bediener die Tasten betätigt ;-) . Legt man die Nummer der betätigten Taste in einem Register ab, dann kann es vorkommen, dass ein ultrahibbeliger Bediener schon die nächste drückt, bevor die erste überhaupt ausgewertet ist. Dann wird der Inhalt des Registers mit der Nummer der zuletzt betätigten Taste überschrieben und die erste Eingabe war für die Katz. Sehr frustrierend für den Bediener ;-) ! Den Puffer betrachte ich hier als nützlich, weil es zu vermeiden gilt, dass nicht synchronisierbare Eingaben verloren gehen.Zitat:
Zitat von robo_wolf
Freut mich, das der Software-Stack Dir so gut gefällt :-). Gedacht war er auch, um Dir auf solche Schmankerl Appetit zu machen. Denn mein Vorschlag ist nun, dass Du als Nächstes mal versuchst, einen FIFO-Speicher zu bauen. Speichern soll er einzelne Bytes; die Kapazität soll einstellbar sein und bis zu 255 gehen dürfen. Es sollen mehrere FIFOs in einem Programm einzurichten sein. Natürlich soll alles in einem wiederverwendbaren Modul verpackt werden. Es soll die Prozeduren
exportieren. Als Muster, hatte dich mir gedacht, könntest Du den STACK8 verwenden; allerdings ist die FIFO etwas komplizierter, denn da es sind ein paar mehr Fälle zu berücksichtigen.Code:FIFO8_CREATE
Eingangsparameter:
zh:zl enthalten Zeiger auf den Beginn des Steuerblocks
r16 enthält die gewünschte Kapazität in Byte
Ausgangsparameter:
zh:zl unverändert
r16 unverändert
FIFO8_WRITE
Eingangsparameter:
zh:zl enthalten Zeiger auf den Beginn des Steuerblocks
r16 enthält das Datenbyte, das auf der FIFO abgelegt werden soll
Ausgangsparameter:
zh:zl unverändert
r16 unverändert
SREG (T-Flag): T = 0 Fehlschlag, FIFO war voll
T=1 Datenbyte erfolgreich auf der FIFO abgelegt
FIFO8_READ
Eingangsparameter:
zh:zl enthalten Zeiger auf den Beginn des Steuerblocks
Ausgangsparameter:
zh:zl unverändert
r16 enthält das Datenbyte, das aus der FIFO ausgelesen wurde
SREG (T-Flag): T = 0 Fehlschlag, FIFO war leer
T=1 Datenbyte erfolgreich aus der FIFO ausgelesen
FIFO8_ISTLEER
Eingangsparameter:
zh:zl enthalten Zeiger auf den Beginn des Steuerblocks
Ausgangsparameter:
zh:zl unverändert
SREG (T-Flag): T = 0 FIFO ist nicht leer
T=1 FIFO ist leer
FIFO8_ISTVOLL
Eingangsparameter:
zh:zl enthalten Zeiger auf den Beginn des Steuerblocks
Ausgangsparameter:
zh:zl unverändert
SREG (T-Flag): T = 0 FIFO ist nicht voll
T=1 FIFO ist voll
Mit so einem Ding in der Werkzeugkiste, könnten wir dann mal darangehen, eine RS232-Verbindung zwischen STK500 und PC einzurichten ;-). Was hältst Du davon?
Ciao,
mare_crisium
mare_crisium,
OK die Erlaeuterung mit dem hibbligen Bediener leuchtet mir ein.
An den FIFO moechte ich mich gern versuchen.
Eventuell kommt aber noch die eine oder andere Frage. :-)
robo_wolf,
nur zu mit Fragen :-) !
Für die nächste Aufgabe, die FIFO, habe ich etwas zusammengeschrieben, das - wie ich hoffe - Dir den Einstieg erleichtert ;-) .
Ciao,
mare_crisium
mare_crisium,
wo du gerade schreibst.
Hab da gleich ne Frage:
Den FIFO stell ich mir so vor, dass er je nach Anfrage geleert und befuellt werden kann, bis er eben voll oder leer ist.(kein Schieberegister)
Wenn ich keinen Lesezugriff mache, wird er sich bis zum max fuellen.
Aber es kann auch sein, es sind z.B. 10 Byte im FIFO und ich lese 2b raus, fuelle dann wieder 5b rein und lese 1b raus... usw. Oder..?
Wenn es so werden soll, dann ist es wirklich nicht so easy... :-)
robo_wolf,
ja, ja die Lese- und Schreibzugriffe erfolgen völlig unsynchronisiert. D.h. während ein Prozess Daten in die FIFO einschreibt kann ein anderer schon dabei sein, die Daten der Botschaft schon wieder auszulesen :-).
Das ist wie beim Fliessband an der Supermarktkasse: Die FIFO ist das Fliessband, der Kunde legt die Daten darauf und an der Kasse werden sie heruntergenommen. Je nachdem wer von den beiden schneller ist, kommt's zum Stau und Ärger beim Kunden oder zu gelangweilten Blicken von der Kasse ;-). Wichtig ist aber, dass jeder der beiden mit der ihm eigenen Arbeitsgeschwindigkeit werkeln kann, ohne dass der Gesamtprozess abstürzt. Genau das braucht man, wenn's z.B. darum geht, Geräte miteinander zu verbinden, die mit unterschiedlicher Geschwindigkeit Daten erzeugen bzw. verarbeiten.
Der Algorithmus, den ich in dem .pdf beschreibe, erledigt auch die Situtation, die Dir 'nicht so easy' vorkommt, mit Leichtigkeit (und ein paar "cli"s ;-) ), obwohl er so (verhältnismässig) einfach ist.
Ciao,
mare_crisium
Guten Abend mare_crisium,
lang hat es gedauert... aber nun habe ich einen Stand des FIFO-Moduls erreicht, den ich Dir vorstellen moechte.
Ich hoffe die Kommentare sind ausreichend und verstaendlich geschrieben.
Auf Deine Kommentare bin ich schon sehr gespannt 8-[
robo_wolf,
na, also 0h16' ist schon ziemlich früher Abend ;-) ! Hab' mir Deinen Entwurf heruntergeladen und werde mich demnächst melden.
Ciao
mare_crisium
robo_wolf,
chapeau! Das ist Dir gut gelungen :-) . Meine Kommentare sind alle im Quelltext des Moduls. Weil ich im Hauptprogramm nichts geändert habe, hänge ich es hier nicht an.
Wie Du sehen wirst, habe ich zwei Prozeduren vergessen, die man beim Verwenden von FIFOs häufig braucht. Die müsstest Du noch nachrüsten; ist aber einfach. Danach reden wir 'mal über das Protokoll, das wir für die Unterhaltung zwischen den RS232s verwenden wollen.
Hast Du auf der PC-Seite ein Programm, das die RS232 bedienen kann? Ich habe mir eins mit Delphi geschrieben, das die "Serial"-Komponente aus dem (sehr empfehlenswerten) Heft "Toolbox" verwendet.
Ciao,
mare_crisium
mare_crisium,
vielen Dank fuer die Blumen, Deine Kommentare und Verbesserungsvorschlaege.
Werde die Vorschlaege und Erweiterungen(2 Prozeduren) in meiner optimierten Variante demnaechst wieder vorstellen.
(ich hoffe, dass ich alles richtig verstanden habe)
"Hast Du auf der PC-Seite ein Programm, das die RS232 bedienen kann?"
Nein.... nur WindowsOnBoardmittel Hyperterminal
"Toolbox" kannte ich bis heute noch nicht... Danke fuer den Hinweis.
Guten Abend mare_crisium,
leider steh ich bei Deinem ersten Kommentar wieder ein wenig auf dem Schlauch:
"Alle Schweierigkeiten verschwinden, wenn die Kapazität als
Eingangsparameter übergeben werden."
Ist das aehnlich wie bei den macro.... xxx,@0..gemeint???
Ist mir irgendwie unklar :-k
Guten Feiertags-Vorabend, robo_wolf ;-) !
Deine Frage beantwortet sich am Besten anhand des Quellprogramms. Ich habe Dein Modul so umgebaut, dass es so läuft, wie ich mir das vorgestellt habe. War'n noch ein paar fette Fehler drin ;-) . Die in FIFO8_CREATE und FIFO8_WRITE habe ich beseitigt; FIFO8_READ überlasse ich Dir :-) !
Ciao,
mare_crisium
wuensche einen schoenen Feiertag,
mare_crisium,
Danke fuer die Files.
Da hatte ich wohl etwas zu kompliziert gedacht(Eingangsparameter uebergeben).
Wenn man das so sieht, ist es doch logisch un simple zugleich... ;-)
Ein, fuer mich gravierendes, Problem sehe ich jetzt noch:
Daduch das die RAM-Konstrukte auf Variablen basieren, kann folgendes passieren.
Ich stelle die beiden FIFOs auf max:=255 und der "Controller wirft Blasen"
Was ich damit sagen will: Das RAM-Ende wird ueberschritten und der Assembler merkt es nicht... zu mindestens bei mir.
RAM_NEXT_FREE :=0x027E und beim AtMega8515 ist bei 0x025F schon Schluss.
Nun um dem Ganzen im Programm vorzubeugen, moechte ich gern eine Uberwachung einbauen.
Also RAM_NEXT_FREE mit RAMEND( ist ja so in der *.inc festgelegt) vergleichen.
Da sehe 2 Probleme zum Einen muss man vom RAMEND noch die Stackverwaltung abziehen...
und zum Anderen moechte ich bei der Abfrage einen Assembler-Error bewirken.
robo_wolf,
hatte ich mir's doch gedacht, dass Du Dir das mit der Parameterübergabe irgendwie zu kompliziert vorgestellt hattest ;-) !
Ja, die Überprüfung des RAM-Haushalts ist nützlich. Allerdings sind die RAM-Bereiche in diesem Beispiel ja nicht dynamisch; will sagen: So wie sie zu Assemblierzeit eingestellt sind, so bleiben sie auch während der Laufzeit des Programms. Ich habe mich deshalb immer damit beholfen, nach dem Assemblieren einmal den Simulator laufen zu lassen und dort die Ausdehnung der RAM-Bereiche zu überprüfen (inkl. System-Stack).
Man könnte an noch ander Methoden denken, z.B. daran, zwischen Variablen-Bereich und Stack-Untergrenze sogenannte "Wächterbytes" einzubauen. Das sind zwei, drei RAM-Bytes mit vordefinierten Werten. Wenn die sich ändern, bedeutet es, dass der Stack in den Variablenbereich hineingewachsen ist. Diese Überwachung könnte in der IDLE-Schleife angesiedelt werden.
Ciao,
mare_crisium
mare_crisium,
habe noch einen Fehler in meinem Programm gefunden, den ich nicht nachvollziehen kann.
Wenn ich die Kapazitaet groesser 63(0x3F) setze, bekomme ich die Fehlermeldung
..\LernPrgrm_FIFO_TEST_V01\FIFO8.asm(122): error: Operand 2 out of range: 0x40
--> es gibt ne Grenze...und die liegt bei "<0x40" .... Oder???
das habe ich noch gefunden:
Code:FIFO8_WRITE:
/* KOMMENTAR_BEGINN!!!
...
cp r18,r17 ;
...
hier stimmt was noch nicht. Das zweite Byte wird nicht mehr geschrieben.
->>>(...wird schon geschrieben, ist aber beim ersten Mal "0x00")
KOMMENTAR_ENDE !!!
*/
cp r17,r18 ; die Operanten muessen vertauscht werden, weil es brge und nicht breq ist( :-() mein Fehler)
brge FIFO8_WR_EXIT ; Sprung, wenn FIFO voll ist