"QUIRL" - Assembler-Routine fr CC1 zur Auswertung digitaler Drehgeber


WAS KANN DIE ROUTINE?

Sie kann bis zu drei digitale Drehsignalgeber an beliebigen Digitalportpaaren der CC1 
erfassen.
Die Drehsignalgeber mssen eine Rechts-/Links-Kennung anhand um 90 Grad verschobener
Impulsphasen aufweisen. Die Routine ist - mangels "Thread"-Fhigkeit der CC1 - nur
in der Lage, jeweils EINEN Impuls von EINEM Drehgeber zu erkennen. Das heit, eine
GLEICHZEITIGE Erfassung aller Geber-Bewegungen ist so nicht mglich.
Die vorliegende Lsung ist gedacht zur Auswertung von Drehgebern, welche als
Eingabegert fr PCs dienen, also von Hand bedient werden.
Zum Beispiel als
- Jog-/Shuttle
- Drehrad zum schnellen Einstellen von Werten

Wenn also ein solches Eingabegert z.B. mit drei "Jog"-Rdern ausgerstet ist,
kann die CC1 das Mittel der Wahl darstellen, da im Handbetrieb kaum alle Rder
gleichzeitig bewegt werden. Genau fr diesen Zweck wurde die Routine auch
entwickelt. Siehe auch "Und sonst" weiter unten.

Die Erkennung der Geber-Richtung ist bei schneller Drehung nur zu ca. 95 Prozent 
zuverlssig - nicht zu 100%, da offenbar irgendwo immer noch Impulse verloren gehen. 
Meine Vermutung: Whrend der bertragung der Bytes ber die serielle Schnittstelle. 
Aber im beschriebenen "Handbetrieb" lt sich das verschmerzen.


WIE FUNKTIONIERT DAS PROGRAMM?

Ein Drehimpulsgeber hat blicherweise zwei Impulsausgnge (siehe oben). Diese mssen
auf je einem digitalen Input der CC liegen. Die Routine "pollt" nun sechs (3x2)
Digitalports, indem auf eine nderung des Port-Zustands gewartet wird. Sobald das 
passiert, ist quasi der "Interrupt" eingetreten - einer der Geber wurde bewegt. 
Dann mu die (hoffentlich im Datenblatt eingetragene) "Prellzeit" abgewartet werden, 
eine Phase von einigen Millisekunden, in denen der Impuls noch "schwankt" und nicht 
eindeutig dem Low- oder High-Pegel zugeordnet werden kann. Danach wird nochmals geprft, 
welcher Impuls nun eingegangen ist, und damit ist die Sache im Prinzip klar. Weiteres 
siehe Listing.
In der vorliegenden Form erwartet die Routine die Impulse auf folgenden Eingngen:
Geber 1, Impulsanschlu A 	- Port 9
Geber 1, Impulsanschlu B	- Port 10
Geber 2, Impulsanschlu A	- Port 11
Geber 2, Impulsanschlu B	- Port 12
Geber 3, Impulsanschlu A	- Port 13
Geber 3, Impulsanschlu B	- Port 14


WICHTIG!

Vor dem Aufruf der Routine mssen zwei Wiederholungswerte fr die Warteschleife
der Routine als Variablen in CC-Basic angelegt werden ("LoopV" und "Mult"). "Mult" ist
dabei der Multiplikator und gibt an, wie oft die innere Schleife durchlaufen wird,
welche wiederum pro Aufruf bis "LoopV" zhlt. Gute Werte sind z.B.:
LoopV = 190
Mult = 1
Dies reicht zum Abwarten einer Prellzeit von ca. 1 Millisekunde. (Die Wartezeit ergibt
sich aus den addierten Taktzyklen der Maschinensprache-Befehle, die in den Schleifen
durchlaufen werden.)
Die Variablen mssen in CCBasic als 12. und 13. Bytevariable angelegt werden (oder
in der Routine an den entsprechenden Platz gesetzt werden).


WARUM IN ASSEMBLER?

Geschwindigkeit. Die Ausfhrung von CC-Basic-Programmen ist (zumindest ohne bertaktung)
VIEL zu gering, um die Impulsgeschwindigkeit eines "handgedrehten" Jog-Rades zuverlssig
zu erfassen.


MIT WELCHEM ASSEMBLER MUSS DIE ROUTINE BERSETZT WERDEN?

Ich habe den TASM verwendet, aber es sollte jeder 6805-Assembler funktionieren, 
da keine Assembler-spezifischen Makros oder dergleichen benutzt werden.
Die "OBJ"-Datei kann direkt in der Entwicklungsumgebung eingebunden werden
(syscode "quirl.obj").


WARUM SCHICKT DIE ROUTINE BITMUSTER BER DIE SERIELLE SCHNITTSTELLE?

Nur um Platz zu sparen, sprich einige "LDA/STA"-Befehle zu vermeiden (Diese wrden
vor dem Aufruf des Unterprogramms "ImpWait" in jedem Auswertungsabschnitt fllig
werden, um jedem Geber/jeder Richtung einen Erkennungswert zuzuweisen). Anhand der
Bitmuster, die zur Portabfrage ohnehin gebraucht werden, kann das auswertende Programm 
am anderen Ende der Schnittstelle trotzdem eindeutig erkennen, welcher Drehgeber 
in welche Richtung bewegt wurde.


UND SONST?

Die Routine erlaubt es durchaus noch, etwa den Zustand einer kompletten digitalen 
Portleiste der CC zustzlich ber die serielle Schnittstelle als Bytewert zu schicken, 
vielleicht ist auch noch Platz fr mehr. Aber: Jede bertragung ber RS232 bremst 
wiederum das Programm ab, was die Fehlerrate beim Erkennen der Drehbewegung erhht.
Wer weniger Drehgeber an der CC betreiben will, erleichert die Routine einfach um
die entsprechend numerierten Programmteile und hat dann mehr Platz fr andere
Aufgaben.
In der jetzigen Form springt die Routine nach jeder Ausfhrung zurck nach CC-Basic
und mu dort "geloopt" werden. Damit knnen auch in CC-Basic noch (mglichst
wenige) Befehle whrend der Drehgeber-Auswertung abgearbeitet werden. Zuverlssiger
ist aber vermutlich, nach dem Start der Routine gar nicht mehr in CC-Basic zu
springen, sondern bis zu einem Reset in Assembler zu bleiben. Siehe Listing.

Im Projekt, das diese Routine ntig machte, werden die Zustnde der Drehgeber
brigens von einer M-Unit erfat und direkt ber die TTL-Schnittstelle an die
zweite (=Software)-Schnittstelle einer C-Control II geschickt. Die M-Unit dient
hier quasi als "unbelasteter Coprozessor" der CC2, um die zeitkritische Erfassung
der Drehgeber mglichst nicht durch andere Aufgaben zu stren, etwa durch die
Umfangreiche Kommunikation mit dem angeschlossenen PC und Ausgaben auf ein
LCD-Display. Eventuell geht das auch mit zwei "kleinen" C-Controls ber den I2C-Bus,
aber fr die etwas komplizierte PC-Kommunikation in diesem Fall - es werden auch 
andauernd Texte fr das Display bertragen usw. - war mir die komfortable CC2-Sprache
lieber. Vom Variablen-Speicherplatz ganz zu schweigen. Denkbar ist auch, die ganze
Sache umzudrehen - Geber und (eine Menge!) Taster mit der CC2 abfragen, Display ber 
die CC1. Aber ich habe noch nicht getestet, ob die CC2 im "Normalbetrieb" 
(d.h. ohne Assembler) dafr schnell genug ist. 

Ansonsten viel Spa - ich habe mir im Netz den Browser wund gesucht nach der Lsung
dieses Problems. Vergeblich. Jetzt gibt es eine mgliche Methode, immerhin.

Hartmut Grawe, Oktober 2003