Programmierbeispiele in Forth

passend zum ROBOprogy mit Q4c.exe

Man kann Prozessoren mit unterschiedlichen Verfahren beibringen, was sie machen sollen - das nennt man Programmieren.

Mit Assembler erreicht man die höchste Geschwindigkeit, allerdings ist die Sache recht fehleranfällig. Damit arbeitet man ungern. Die "firmware", die im ROBOprogy enthalten ist, ist vollständig in Assembler programmiert. Hier ein kleiner Ausschnitt, welche Befehle durchlaufen werden, wenn Sie mit dem Befehl

22 1MOT

die Geschwindigkeit des ersten Motors ändern wollen.

Das war aus dem Innenleben des ROBOprogy. Auf diese Weise einen Roboter zum Laufen zu bringen, ist ein echtes Kunststück. Im PC ist das Programm Q4c in Forth geschrieben, das sieht dann so aus:

So werden die Programmsteuerbefehle wie BEGIN und UNTIL in Bytes umgesetzt, die dann gleich seriell über die COM-Leitung zum ROBOprogy gesendet werden. Dieser Teil wurde zum freeware-Programm W32for42 von Tom Zimmer ergänzt, das Ergebnis heisst nun Q4c. Dort findet man auch viele Details, wie Forth funktioniert. Das Programm, mit dem Sie den Roboter steuern werden, ist auch Forth und sieht ähnlich aus. Ein erstes Beispiel:

Das ist das Editorfenster, das sich am rechten Rand des Bildschirms erscheint, wenn Q4c.exe mit angeschlossenem ROBOprogy gestartet wird. Die mitgelieferte Datei "test1.f" wird automatisch geöffnet, es fehlen aber noch die Ziffern im hellblau unterlegten Randstreifen. Die erscheinen erst dann, wenn das Programm mit STRG+A markiert und mit STRG+SHIFT+q zum ROBOprogy geschickt wurde. Während der Übertragung wird in Q4c zeilenweise der der Stackinhalt mitgerechnet und in diesem hellblauen Streifen angezeigt.

In der ersten Zeile liefert die 0 ein Byte auf das Stack. In der 2. Zeile liefert 5in einen weiteren Eintrag, den der Befehl 0= ändert. In der 3.Zeile nimmt IF auf jeden Fall ein Byte weg und prüft ihn. Wenn er ungleich 0 war (Eingang 5in offen), wird in dieser Zeile fortgefahren und der verbleibende Wert (vorher 0) wird durch den Befehl 1+ erhöht. Dann geht es hinter THEN weiter. Wenn das Byte, das IF geprüft hat, 0 war, springt das Programm zur Zeile mit ELSE. Dort wird das eine Byte auf dem Stack mit DROP entfernt und eine neues Byte mit dem Wert 0 draufgesetzt. Wenn der Eingang 5in geschlossen ist, beginnt also der Zähler von vorn.

Hinter THEN wird erst einmal 1 ms gewartet, weil der ROBOprogy zu schnell ist. In der Zeile über UNTIL wird das Zähler-Byte kopiert und nochmal auf das Stack gesetzt (das ist keine Verdopplung des Wertes!). Dann kommt als 3. Byte die 250 darüber. Nun nimmt der folgende Befehl = die obersten beiden Bytes und vergleicht diese. Das Ergebnis, entweder der Wert $ff oder 0, wird auf das Stack gesetzt, jetzt sind dort insgesamt zwei Bytes. UNTIL nimmt das oberste davon und prüft, ob es 0 ist. Wenn ja, springt das Programm zurück zu BEGIN. Das Zählerbyte darunter wird nicht angetastet. Andernfalls wurde 250 mal nacheinander festgestellt, dass ein Schalter am Eingang 5in offen ist, dass also mit Sicherheit kein Zufallsimpuls oder ein Wackelkontakt vorliegt. Das Zählerbyte wird mit DROP vom Stack entfernt, das Programm ist zu Ende.

Das Programm sollte TASTEZU heissen, wenn in der zweiten Zeile der Befehl 0= gelöscht wird. Beide Programme sind recht sinnvoll, sobald ein mechanischer Schalter von einer schnellen Elektronik abgefragt wird. Wenn Sie wissen wollen, wie lange die 250 Prüfungen ohne die 1 ms-Pause gedauert hätte, löschen Sie einfach diesen Befehl 1 MS. Dann fügen Sei zwischen TASTEFREI und BEGIN eine Uhr ein mit dem Befehl

255 AT1!

Unmittelbar vor dem ; (=Programmende) fragen Sie diese Uhr ab mit dem Befehl

AT1@ .

und schicken das Ergebnis (mit dem Befehl .) zum PC. Ich habe hier den Wert 255 erhalten. Das Programm hat also nicht einmal eine Millisekunde gedauert. In dieser Zeit wurde 249 mal die Schleife aus 8 Befehlen durchlaufen, das ergibt eine mittlere Verarbeitungszeit von maximal 1000us/(249*8) = 0,5 Mikrosekunden. Das ist nur wenig mehr als bei Assemblersprache, die den Temporekord hält.

Hier noch weitere Bilder ohne genaue Kommentierung. Wenn man selbst programmiert (und Fehler macht), sollte man auf jeden Fall die Zahlenreihen in der hellblauen Spalte genau studieren. Wenn diese Reihe plötzlich endet, wurde ein krimineller Fehler entdeckt, der korrigiert werden muss, bevor der ROBOprogy das Programm akzeptiert.

Das linke Bild zeigt ein Beispiel, in dem der ROBOprogy eine stundenlange Feuchtigkeitsmessung durchführt. Einer von acht Sensor-Kondensatoren wird von einem CMOS-Multiplexer 4051 an einen NF-Oszillator von etwa 100 kHz gelegt und ändert dessen Frequenz. Die Frequenz wird vom ROBOprogy gemessen und als 16-Bit-Wert zusammen mit der gerade eingestellten Kanalnummer an den PC gesendet. Dort werden die eintreffenden Werte von einem modifizierten Q4c-Programm gespeichert und mit Matlab ausgewertet. Dafür sind drei Teilprogramme erforderlich:

MESS holt laufend das neueste Ergebnis der Frequenzmessung, das immer dann vorliegt, wenn die Funktion FREQUENZ einen anderen Wert als 0 meldet. Dieses Ergebnis legt es auf das DatenStack.

Die acht Programme K0 bis K7 schalten den angeschlossenen Multiplexer 4051 um: Jedes der Programme erzeugt eine andere Dualzahl an den Ausgängen P1, P2 und P4.

Das Hauptprogramm heisst PLEX. Es beginnt mit Kanalnummer 0, sendet diese zum PC und wählt über AM! genau eines der acht Programme zwischen AMODEJUMP und JUMPEND aus. Wegen diese Umschaltung ist die nächste Frequenz unbrauchbar, das Ergebnis wird mit 2DROP gelöscht. Die folgende Messung wird an den PC geschickt. Zuletzt wird die nächste Kanalummer erzeugt und alles beginnt von vorn. Stundenlang. Da die im ROBOprogy eingebaute Funktion FREQUENZ eine Torzeit von 100 ms besitzt, wird alle 200 ms ein neuer Messwert geliefert. Der ROBOprogy kann also mehr als nur Roboter steuern.

Im rechten Bild sind kurze Hilfsprogramme für Roboter. MOTZ ist ganz brauchbar, wenn bei der Eigenprüfung vor dem Start oder während des Wettbewerbs etwas nicht stimmt. 2 MOTZ piepst zweimal und 4 MOTZ piepst viermal. Man prägt sich sehr schnell ein, nach welcher Ursache das Programm zweimal oder dreimal motzt.

BLINK ist genauso praktisch: Auf die höchste Stelle des Roboters baut man eine helle LED und schließt diese (über einen 200 Ohm Vorwiderstand) an den Ausgang 1OUT an. Auch hier lernt man sehr schnell, was es bedeutet, wenn die LED dreimal oder (bei 255 BLINK) immer blinkt.

Bei manchen Roboter-Wettbewerben ist es vorgeschrieben, ausser dem regulären Ein-Aus-Taster noch einen Not-Aus-Taster zu verwenden, mit dem bei Gefahr und unabhängig von der restlichen Elektronik die Motore stromlos geschaltet werden können. Das passende Programm MOT_EIN? liefert 255 oder 0, je nachdem, ob man vergessen hat, das Motorrelais einzuschalten oder nicht. Das folgende Bild zeigt eine bewährte Schaltung mit Thyristor und Relais, das dem ROBOprogy den Schaltzustand meldet. Es wäre seltsam, wenn das Programm nichts weiss von der Position des Relais.

Das Beispiel WINK links oben stammt aus der Abteilung Unsinn und bewegt nur ein Servo. Im Beispiel FARBEN wird sieben mal immer die gleiche Funktion A1 aufgerufen, trotzdem wechseln die Anzeigen in Dreiergruppen. Dieses Beispiel dient als Test für die Funktion AMODEJUMP. Die folgenden Funktionen QQ und YY und UHR sind ebenfalls Testfunktionen für unterschiedliche Arten der Wiederholung.

Ein wenig unüblich ist die Funktion SERVO. Sie erwartet einen Wert zwischen -120 und +120 auf den Stack und dupliziert ihn so oft, bis er insgesamt neun mal auf dem Stack liegt. Jede der folgenden Servofunktionen verbraucht einen Eintrag davon. Mit Rücksicht auf den begrenzten RAM-Speicher des MEGA32 ist das Stack für maximal 20 Bytes bemessen - benötigt werden selten mehr als acht.

Das Programm xx hat zwei Aufgaben: Es prüft den Frequenzzähler und die Logarithmusfunktion. Sie markieren diese Funktion mit STRG+a, kopieren sie zum ROBOprogy mit STRG+SHIFT+q und starten mit XX. Am PC erscheint eine Zahlenkette, die sich entsprechend der eingespeisten Frequenz (Rechteck; 0..+5 Volt) am Eingang 8in ändern muss. Die Messgenauigkeit ist nicht besonders groß, weil der RC-Oszillator des ROBOprogy temperaturabhängig ist.

Die untersten Funktionen des Bildes prüfen Berechnungen mit 16-Bit-Werten und diversen Kleinkram.