Motorsteuerung über Sensorik

[HaWe]

Das ist in orignal Arduino viel simpler implementiert, ich habe gerade mal in den Sourcen nachgesehen.

Hier Auszüge aus Wiring.cpp

int TwoWire::available(void)
{
  return rxBufferLength - rxBufferIndex;
}

available gibt nur zurück, wieviele von den vom Bus geholten Bytes noch nicht vom Sketch verarbeitet wurden.

Alle Funktionen, die vom Bus lesen, warten bis sie fertig sind. Hier requestFrom (siehe Pfeil für die Wartestelle)

uint8_t TwoWire::requestFrom(uint8_t address, uint8_t quantity, uint32_t iaddress, uint8_t isize, uint8_t sendStop)
{
  if (isize > 0) {
  // send internal address; this mode allows sending a repeated start to access
  // some devices' internal registers. This function is executed by the hardware
  // TWI module on other processors (for example Due's TWI_IADR and TWI_MMR registers)

  beginTransmission(address);

  // the maximum size of internal address is 3 bytes
  if (isize > 3){
    isize = 3;
  }

  // write internal register address - most significant byte first 
  while (isize-- > 0)
    write((uint8_t)(iaddress >> (isize*8)));
  endTransmission(false);
  }

  // clamp to buffer length
  if(quantity > BUFFER_LENGTH){
    quantity = BUFFER_LENGTH;
  }
  // perform blocking read into buffer             <------------------------------  Da wartet er
  uint8_t read = twi_readFrom(address, rxBuffer, quantity, sendStop);
  // set rx buffer iterator vars
  rxBufferIndex = 0;
  rxBufferLength = read;

  return read;
}

Eine Wire Implementierung, die im Hintergrund arbeiten kann, hat z.B. der Teensy. Aber da heißt das nicht wartende requestFrom sicherheitshalber sendRequest, um es von der blockierenden Arduino kompatiblen Variante zu unterscheiden.

was also unter dem Strich ebenfalls bestätigt, dass man hinter dem while(Wire.available()....) keinen {code} mit delays - oder was auch immer - einfügen muss, was i_make_it verlangt oder ansonsten als schlechten Programmierstil ("quick and dirty") verunglimpft - und dann sogar zum Weglassen rät, was dann angeblich auch keinen Unterschied machen würde.
Und was ebenfalls bestätigt, dass die Konstruktion
Wire.requestFrom(CMPS10Addr , 4); // Abfrage von 4 Bytes vom CMPS10
while (Wire.available() < 4); // Warten, bis 4 Bytes verfügbar
völlig korrekt ist und verwendet wird, um zu warten, bis die i2c-Daten im Puffer soweit zur Verfügung stehen, dass sie anschließend von Wire.read() gelesen und weiter verarbeitet werden können.

Wenn der OP also Probleme mit dem cmps10 hat und auch nicht von sich aus einen Fehler findet, würde ich, wie teilw. schon oben angeführt, zusammengefasst dazu raten:
- den cmps10 Teil prüfen, ob er wirklich dem verwendeten Original-Example Code (meist wohl ursprünglich von James Henderson) entspricht, aber dann lassen wie er ist (s.z.B.: http://www.robot-electronics.co.uk/f...cmps11_i2c.ino)
- erstmal dann diesen isolierten cmps10-Code laufen lassen, wie er im Original cmps10/11 Beispiel-Code steht, ob er dann auch wirklich wenigstens isoliert funktioniert
- in den Code Serial.println() einzufügen, wobei dann verschiedenste Variablenwerte schrittweise zur Kontrolle ausgegeben werden. In diesem Fall sollte man mal das Heading zur Kontrolle anzeigen lassen, und natürlich auch den ganzen Rest zu Debug-Zwecken.
- ggf bei Fehlern im i2c-auslesen die verwendeten Pullups überprüfen: welcher Arduino wird verwendet (manche haben ausreichende Pullups bereits intern verbaut, manche nicht) und ggf welche externen Pullups wurden gesteckt?

Anm. (Thema "Nikolausi" und "Osterhasi" ):
im Original-Code von James Henderson steht fälschlicherweise immer "bearing", das ist der falsche Name für das, was hier ausgelesen wird:
Es handelt sich um "heading", auf deutsch "Kurs";
bearing hingegen ist die Peilung eines (externen) Objektes relativ zum momentanen Kurs.
Das nur zur Erklärung, warum ich immer "heading" eingesetzt habe, wo der O-Autor "bearing" verwendet hat. Das tut dem Algorithmus aber ntl keinen Abbruch.