Auch so....
Du reagierst in Deinem Programm sofort auf Ã?nderungen der Lage des Glove.... sozusagen in Echtzeit.
Das OS des CC2 ist kein Echtzeitsystem.
Das hat zur Folge, das man entweder das Problem hat, das laufend Daten verloren gehen und nur die
Threadpriorität hochgesetzt werden kann (mit run 254) - was meist mehr Probleme verursacht als es löst - oder
man muÃ? sich damit auseinander setzen, das man ein Multithreadingsystem hat...
Das ist jedoch nicht einfach da der Mensch üblicher Weise linear, also in logischen Verkettungen
und Abfolgen denkt. "Just in Time" ist das beste Beispiel.. billig.. einfach.. aber wehe es gibt einen
Stau in der Verarbeitungskette... Das Gegenteil von JIT ist intelligente Lagerhaltung. Und das ist auch
die Lösung des Problems.
Du kannst dazu als ersten Schritt auf relativ niedriger Ebene die Buffer für die Schnittstelle erhöhen.
setbuf ( byte buf[], int length ) Dies wird aber die Probleme nur geringfügig verlagern. RTM
Du must einen Thread schreiben, der sich nur mit der Datenauswertung des Gove beschäftigt und den Status
in globalen Variablen schreibt. Dieser Thread sollte möglichst kurz sein und die Kontrolle an das System so
schnell wie möglich zurück geben. Man hat in den Variablen dann immer einen aktuellen Zustand und wenn
der Thread mal eine Datensequenz des Glove nicht mitbekommt, hat man immer noch relativ aktuelle Werte
aus dem vorherigen Lauf - das System ändert sich ja nicht schlagartig - dh. Richtungsänderung innerhalb 1 ms.
Nur sollte die CC2 nicht die Syncronisation mit dem Glove verlieren. (das sollte setbuf regeln)
Du hast dann keine Information mehr, "wie sich der Glove bewegt" sondern nur noch wie die aktuelle Lage ist.
Dieser Thread sollte evtl. hoch gesetzt werden - nach dem man die Buffer hochgesetzt hat- ich würde mal mit
run 64 anfangen... das ist das doppelte der normalen Priorität. Der Thread sollte aber dann nicht mehr als 10
c2-Befehle haben. Alles so über den Daumen geschätzt.
Dein Hauptthread wertet dann die globalen Variablen aus und steuert die Portleitungen.
Es würde ja reichen, wenn dieser Thread z.B. nur alle 10 ms ausgeführt wird - weil die Steuerbefehle mehr
als 100 mal pro Sek. ausgerechnet und ausgegeben wenig Sinn machen. Dazu kannst Du den Systemtimer
nutzen. Mit if !(system.timer() % 10) yield(); an Anfang des Threads wird der Thread nur alle 10 ms ausgeführt
und sonst die Kontrolle an das OS als an die Threadfunktion für die Glove-Auswertung abgegeben.
Nun bekommst Du sogar Zeit im Glove-Thread z.B. errechnete Tendezwerte global abzuspeichern und
Du must ihn ggf. nich mal mit run hochsetzen. Evtl. reicht es sogar, um alle Daten aus dem Buffer
auszuwerten. Das nennt man dann Quasi-Echtzeit. Wie man diesen Buffer dann auswertet, ist auch noch
einiges an �berlegungen Wert aber das würde hier zu weit führen.
Diese Ã?berlegung zeigt, das man durchaus Laufzeitprobleme gut in den Griff bekommt wenn man sich
von der sequenziellen Abarbeitung löst.
Der erste Grundgedanke in einem Threading-system ist nicht
"wie bekomme ich mehr Rechenleistung zugeteilt" sondern eher
"wie kann ich anderen Threads mehr Rechenleistung zukommen lassen".
Hier z.B. durch die Beschränkung von auf alle 10 ms, jedoch mu� der Buffer für die hwcom so gro� sein,
das er wärend der gesamten Laufzeit des Hauptthreads alle ankommenden Zeichen aufnemen kann.
9600 Baud = ca. 1000 Zeichen/sek. Braucht der Hauptthread also 1 Sek. must Du min. 1 KB Buffer zuweisen.
Erst dann - wenn man Rechenleistung "erwirtschaftet" hat - kann man mit Prioritäten die
überschüssige Rechnenleistung verteilen. Das macht ein Threadsystem erst leistungsfähig.
Je weniger man "sequentiell" arbeitet, um so mehr kann man Aufgaben verteilen (ggf. mit CAN sogar auf 2
oder mehr cc2's). Das klingt zwar alles nen bischen blöd aber nur so kommt man vorwärts!
GruÃ? Rolf
Antwort schreiben
Antworten:
Re: hwcom sync-Probleme? (von André H. - 5.08.2003 8:45)Re: hwcom sync-Probleme? (von Rolf - 5.08.2003 12:20)Re: hwcom sync-Probleme? (von Rolf - 5.08.2003 13:25)Re: hwcom sync-Probleme? (von Fischi - 5.08.2003 13:45)Re: hwcom sync-Probleme? (von Fischi - 4.08.2003 19:06)Re: hwcom sync-Probleme? (von Rolf - 4.08.2003 20:51)