|
Home -
Gallery
Geology
Music
Software
Hiking
Links
Sport
What?
Projects Sources V4 Flightsim Joystick Workshop 1 2 3 4 5 6 7 8 Anl |
Page 346 of 401
< > |
Hier eine lose Sammlung von Ergänzungen rund um das Thema Joystick.
Überlegung (# 19980713.1800)
In geplante Tabelle "Klassifikation der Fehlerquelle" verschieben.
Spontane Ansatzpunkte:
(1) Die Analog/Digital-Wandlung. Egal auf welchem Weg, bedingt sie einen Informationsverlust ähnlich wie der, den in C eine Zahl beim Casting von Double oder Float zu Int erleidet, nämlich Abschneiden der Nachkommastellen. Dadurch entstehen folgende Effekte:
(1.1) Eine Signalschwankung im Nachkomma-Bereich wirkt sich gar nicht aus, wenn das Signal dabei im Vorkomma-Bereich der Zahl bleibt.
(1.2) Eine Signalschwankung im Bereich weit hinter dem Komma wirkt bis vor das Komma (also vergrößert), wenn das Signal auf der Grenze zwischen zwei Ganz-Zahlen liegt.
Beide Effekte zusammen bewirken eine stufenförmigen Verlauf der Weg/Zeit-Kurve.
(2) Die genaue Dauer der Kondensator-Entladung hängt z.B. von der Dauer der Aufladung ab. So kann vielleicht durch eine zu häufige Joystick-Abfrage die Mindest-Dauer bis zur Sättigungs-Ladung unterschritten werden.
CHECK - Weitere Parameter für Entladezeit?
CHECK - Wodurch wird das Ende der Entladezeit bestimmt?
(3) Aufgrund (1) der Existenz einer Analog/Digitalwandlung und (2) der Art dieser Wandlung (ohne Beweisführung) denke ich: Eine am Port gelesene Achse flackert verfahrensbedingt immer mindestens um plusminus eins.
Verbesserungsvorschlag. Das Flackern der Achse ließe sich evtl. mit einem unkomplizierten Alorithmus eliminieren, der irgendwie die vorausgegangenen Werte in den aktuellen einfließen läßt. Primitiv-Algorithmus: Mittelwert über die zurückliegenden 4 bis 10 Werte verwenden, das glättet die Wogen. Achtung - reine Theorie.
(4)
.
Achtung. Dieser Kommentar ist geschrieben ohne jegliche praktische Erfahrung. Was sind das genau für Schwächen, die beseitigt werden sollen?
Vergleiche Kapitel "Fragen und Antworten" - Frage "Eventmanager - was ist das?"
Der Begriff Eventmanager aus Radtke/Lampton läßt aus den Wörtern "Event" und "Manager" gleich zwei Dinge ahnen: (ohne das Buch gelesen zu haben)
(1) die Aufgabe der so benannten Funktion
und (2) die Stellung innerhalb des Programm-Designs.
Der Begriff "Event" stammt aus der OOP (Objektorientierte Programmierung). Hier werden, anders als bei der rein prozeduralen Programmierung, von verschieden "Objekten" des Programms, völlig unabhängig voneinander, "Events" ausgelöst, das sind Botschaften an wieder andere Objekte, die dann als Antwort in irgendeiner Weise reagieren.
Das entscheidend Neue an diesem Design ist, daß die Objekte zeitlich unabhängig voneinander agieren können, was eine bessere Modellierung der Wirklichkeit erlaubt als die reine Prozedur. Allerdings muß jetzt das chaotische zeitliche Ineinandergreifen der Dinge koordiniert werden, das macht der Eventmanager.
Ein Eventmanager hat drei Aufgaben (unabhängig vom Buch)
(1) Alle von Objekten gesendeten Nachrichten einsammeln. In unserem Zusammenhang ist das speziell der Input von Geräten, speziell vom Joystick.
(2) Verwaltung der Nachrichten/Anforderungen. Z.B. Prioritäten setzen, Fehler erkennen, Warteschlange pflegen.
(3) Weiterleitung der Nachrichten an die Ziel-Objekte. In unserem Fall werden die Nachrichten vom Joystick an das Flugmodell weitergeleitet.
Bemerkung: In der Multi-Threading Technik wird die Unabhängigkeit der Objekte noch weiter gesteigert, indem Verwaltungsarbeit vom Compiler zum Prozessor hin verlegt wird.
Auszug aus Monadjemi 1991 (Seite 835)
Dieser Interrupt diente früher zur Ansteuerung eines Kassettenrecorders.
Während der Interrupt 15H beim AT eine neue Bedeutung erhalten hat,
ist er beim einem PC bzw. XT in der Regel nicht belegt.
Von den 18 Funktionen des Interrupts 15H werden im folgenden
die drei wichtigsten vorgestellt: ...
- Funktion 87H Block im Speicher verschieben
- Funktion 88H Größe des Extended-Memory ermitteln
- Funktion 89H In den Protected Modus schalten
Intersessant: der Joystick, also Funktion 84H des BIOS-Interrupt 15H, wird auch in diesem 952-Seiten-starken Buch nicht erwähnt, geschweige denn die Funktion beschrieben.
Fazit: Der Joystick, eine harmlose Eingabe, ist zusammen mit gefährlichen Systemfunktionen in einen Interrupt gepackt. Das ist ein Indiz dafür, daß die Entwickler nicht so recht wußten, was sie wollten, bzw. daß es nachträglich eingefügt wurde. Dieser Stil widerspricht der sonst üblichen Etikette, es ist ein Provisorium.
Beobachtung in dxsdk/sdk/bin/diQuick.exe - Karteikarte Joystick - Karteikarte Mode - Box Data Mode (# 19980713.1700)
Interessant: DirectInput läßt in den Joystick-Einstellungen den Anwender eine der beiden Einstellungen wählen:
(1) Data Mode = Polled
(2) Data Mode = Event-driven
(Vorsicht - erst ausprobieren, ob auch tatsächlich die Wahl frei gestellt ist.) "Polled" und "Event-driven" sind zwei grundsätzlich verschiedene Möglichkeiten des Inputs. Ein Gerät oder ein Programm selber beherrscht normalerweise nur eine dieser beiden Möglichkeiten.
(1) Polled. Hier richtet das Programm zu einem vom Programm bestimmten Zeitpunkt eine Anfrage an das Input-Gerät. Und bekommt eine Antwort oder nicht. Auslöser ist das Programm durch eine normale Funktion (prozedural), das Ereignis ist vorhersagbar.
(2) Event-driven. Hier geschieht etwas am Gerät, und das Gerät schickt den Event an das Programm. Das Programm muß zur Behandlung dieses Events eine Interrupt-Service-Routine (Real Mode) oder eine Callback-Routine (Protected Mode) zur Verfügung stellen. Diese Routine muß praktisch an jeder Zeile des Hauptprogrammfadens hineinplatzen dürfen. Das Ereignis ist nicht vorhersagbar.
MS-DOS hatte bereits einen Aspekt der OOP (Objektorientierte Programmierung), nämlich die zeitliche Unabhängigkeit gewisser Routinen, z.B. Treiber-Routinen. Dieser Aspekt war realisiert mit Hängen und Würgen in der TSR-Programmierung (Transient and Stay Resident) mittels des Interrupt-Mechanismus.
Hier ein leichter verständliches Beispiel (leichter als Joystick), in der beide Strategien vorkommen (weil zwei Software-Ebenen betrachtet werden). Ablauf-Beispiel:
(1) Tastatur. Zu einem beliebigen Zeitpunkt wird eine Taste gedrückt. Die Taste sendet via Bus und Port ein Signal an die Systemsoftware, genauer an den Tastaturtreiber. Das Signal muß dort sofort verarbeitet werden. Das geschieht "Event-driven" mittels der Hardware-Interrupts.
(2) Tastaturtreiber. Durch den Hardware-Interrupt geweckt, nimmt der Tastaturtreiber den Tastendruck jederzeit entgegen und legt ihn in seinem Puffer ab. Für die Laufzeit dieser Interrupt-Service-Routine liegt das aktuelle Programm still -- aber es merkt die Unterbrechung nicht! Zumindest nicht an den Systemtakten, höchstens wenn es auf die Systemuhr schaut. Aus dem Tastaturpuffer dann kann das Anwendungsprogramm den Tastendruck irgendwann abholen. Der Tastendruck gelangt also "Event-driven" in den Tastaturpuffer hinein und kann "Polled" daraus abgeholt werden.
p.s.: Zum Interrupt- bzw. Callback-Mechanismus gibt es weitere Hinweise im Papier. Das ist wichtig für das Verständnis der genauen Laufzeitverhältnisse. Einzelne Interrupts wären vielleicht zu bändigen, man könnt sich einhängen und mitmischen, aber die Sache verkompliziert sich dann in Stufen: (1) durch Protected-Mode, (2) durch Multitasking und (3) bei Multi-Threading.
p.s.: Unterscheide explizit Systemtakte und Systemzeit! Obwohl die Systemzeit natürlich mit Systemtakten gemessen wird - aber in einem dedicated Chip, der Systemuhr, und nicht mit Prozessorbefehlen. (Lit. zur Systemuhr z.B. PC-Intern 3 S.641, PC-Intern 4 S.857 ... CHECK genaue Plazierung der Uhr im System-Layout ...) Die Routine readstick() aus Radtke/Lampton mißt anhand von Takten und nicht anhand von Zeit - hier Verbesserung möglich. ;-> Wenn nicht, wie oft am PC, System-Quirks ein theoretisch korrektes Programm an unvorhersehbaren Nebenwirkungen scheitern lassen. Wer weiß, Radtke/Lampton werden schon gewußt haben, was sie tun. ;.) Wahrscheinlich hatten Sie in diesem Punkt einfach geringere Ansprüche. Die Zeit zu messen ist in Assembler gleich sehr viel aufwendiger, als eine Schleife zu zählen.
(3) Anwendung. Sobald die Anwendung das nächste Zeichen verarbeiten will, fragt sie beim Tastaturpuffer an, ob ein Zeichen vorliegt, und wenn ja, dann nimmt sie es. Das ist "Polling".
Hm ... was hat das mit Joystick zu tun? Wenn es um das Dämpfen und Filtern geht, ... dann ist es sicher gut, die oben fixierten Strategien Polling und Event-driven und den Unterschied zwischen Systemtakt und Systemzeit parat zu haben und alles explizit zu unterscheiden (BTW - Pluspunkt für DirectInput) ...
CHECK - einfügen obige Klassifizierung in Tabelle "Weg des Joystick-Signals".
Auszug aus Hans-Jochen Schneider 1991 "Lexikon der Informatik und Datenverarbeitung" (# 19980714.2300)
Bus. Teilgebiete: Schaltwerke und Schaltnetze; Rechnerorganisation.
Ein Bus ist ein Verbindungssystem zwischen n digitalen Schaltwerken (Teilnehmern) mit folgenden Eigenschaften:
(1) Alle Datenleitungen ... gehen an alle Teilnehmer und werden von allen genutzt. Zusätzliche Leitungen dienen der Verwaltung.
(2) ... Es gilt 2 < n <= N, wobei N die größte Zahl anschließbarer Teilnehmer ist. ...
(3) t Teilnehmer können senden, 1 < t <= n.
(4) r Teilnehmer können empfangen, 1 < r <= n.
(5) Zulässig ist zu jedem Zeitpunkt nur genau eine Verbindung ...
(6) Die Zahl der Teilnehmer an einem Bus ist ... im Rahmen von Schranken ... beliebig.
Beispiele
(1) EA-Bus in einem Minicomputer ...
(2) EA-Bus mit gesondertem Bus-Verwalter ...
(3) IEC-Bus ... besonders zur Kopplung von Meßgeräten entwickelt ...
(4) Der Bus findet Verwendung als Adreßbus, Datenbus, Kontrollbus.
...
Weitere Bussysteme sind z.B. in Sylvester/Weber/Wielsch S. 624 erwähnt.
.
Auszug aus Hans-Jochen Schneider 1991 "Lexikon der Informatik und Datenverarbeitung" (# 19980714.1310)
Port. Teilgebiet: Rechnerperipherie. Bei Mikroprozessoren versteht man unter einem Port die Schnittstelle zwischen den internen und den externen Bussystemen (-> Bus). ... speichernd oder nichtspeichernd ... unidirektional, bidirektional und semibidirektional ... bidirektionaler Betrieb durch zwei gegengeschaltete Threestate-Treiber, von denen immer einer im hochohmigen Zustand ist ...
Generelle Betrachtungen sind evtl. nützlich bei der Frage, wie es in anderen Systemen aussieht, nicht nur Linux, sondern z.B. auch Großrechner, Spiele-Konsolen, Tamagotchi, Waschmaschine.
.
.