Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum

Wichtig: Bevor Du wegen einem Problem mit der CC2 postest, stelle sicher, daß Du
die neueste OS-Version, die neuseste Compiler-DLL und die neuesten Modulversionen benutzt!
Beachte, daß sich auf der CD zur CC2-Unit/Station auch jetzt noch die ältesten Dateien befinden!
Es gelten folgende Anleitung und Regeln: Regeln CC2Net.de-Forum
Zurück zum Artikel  (Blaue Felder sind Pflichtfelder)


Name:   UserID: 
 E-Mail:
Kategorie
Betreff
Homepage:
Link-Titel:
Link-URL:
Cookie für Name, UserID, E-Mail, Homepage-URL setzen
(Erspart die Neueingabe bei Beiträgen und Antworten)
(Zum Löschen des Cookies hier klicken)
Ich nutze:
C-Control II Unit
C164CI-Controllerboard
C-Control II Station
CCRP5 mit CC2-Unit (Conrad Roboter)
CC2-Application-Board
CC2-StarterBoard
CC2-ReglerBoard
eigenes Board
original OS     OSOPT_V2     OSOPT V3.0 OSOPT V3.1

Kommentar:
Einfügen von HTML im Kommentar:

Link einfügen: <a href="LINKURL" target="_blank">LINKTITEL</a>
Bild einfügen: <img src="BILDURL">
Text formatieren: <b>fetter Text</b>  <i>kursiver Text</i> <u>unterstrichener Text</u>
Kombinationen sind auch möglich z.B.: <b><i>fetter & kursiver Text</i></b>
C2 Quellcode formatieren: <code>Quellcode</code>
ASM Quellcode formatieren: <asm>Quellcode</asm>
(Innerhalb eines Quellcodeabschnitts ist kein html möglich.)
Wichtig: Bitte mache Zeilenumbrüche, bevor Du am rechten Rand des Eingabefeldes ankommst !  

> Besten Dank Rolf für Deine ausführliche Beschreibung! Das habe ich verstanden. > 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 > >
Dateianhang: (.gif, .png., .jpg, .zip, .rar)
max. 256kB
max. 256kB