Hi bloodyDragon,

ich würde für dein Problem (Go und Turn Funktion benutzen und zusätzlich I2C Abfragen) anders vorgehen. Die I2C Abfrage nicht timergesteuert starten , sondern eher die Go und Turn Funktion umschreiben (bzw. neuschreiben) in ein Verhalten.

Das ganze wäre eine von Art Quasi Multitasking. In der Hauptschleife werden nacheinander folgende Funktionen aufgerufen.

Code:
  Init();
  InitI2C();
  InitBehaviour();          // Verhalten initialisieren
  while(1)
  {
    ReadSensors();        // einlesen der Sensoren und I2C 
    RunBehaviour();       // Verhalten ausfuehren
    SetActors();             // Aktoren setzen
    SendState();            // evtl. Status an PC senden
  }
Das ganze setzt voraus, dass alle aufgerufenen Funktionen auch in endlicher Zeit fertig werden. Längere Msleep Aufrufe in Funktionen sind deshalb pfui. Wenn eine Funktion in der vorgegeben Zeit nicht fertig wird, muß daraus ein Verhalten programmiert werden.

Ein Verhalten ist auch eine Funktion, die aber:
* mehrmals aufgerufen wird,
* ein wenig Verarbeitung macht,
* sich den Verarbeitungsstand merkt,
* und dann mit einer Statusmeldung zurückkehrt .
Programmtechnisch löst man so etwas mit State Machines.
In einer Verhaltensfunktion werden keine Sensoren direkt abgefragt und auch die Aktoren (Motoren) werden nicht direkt gesteuert. Alles geht nur über globale Variablen.

Die ReadSensors Funktion liest die Sensoren und speichert die Werte in den Sensor Variablen.

Die RunBehaviour Funktion verarbeitet die Sensor Variablen ruft die gewünschten Verhaltensfunktionen auf (Go, Turn, FollowLine etc.) und erzeugt die Aktor Variablen.

Die SetActors schließlich nimmt die Aktor Variablen und steuert die Motoren.

Wird diese Hauptschleife in 10-40ms durchlaufen, kann man von Quasi Echtzeit sprechen. Für einen kleinen Roboter ist das aber schnell genug, um auf Ereignisse zu reagieren.

Klingt nach viel Arbeit