Nun werde ich mich erst einmal mit Threads beschäftigen um das Problem dann zulösen.
Das hat mir auf jeden Fall weitergeholfen, danke nochmal!
GruÃ? skontox
#########
> > Ein wunderschönen Tag!
> 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 Rolf - 4.08.2003 20:51)