Zitat von
HaWe
Ein delay ist in der while Schleife ebenfalls nicht nötig, Arduino-Standard-Beispiele fügen hier nie delays ein (ich wäre nicht überrascht, wenn die in der Funktion Wire.available() sowie so schon enthalten wären),
Das ist in orignal Arduino viel simpler implementiert, ich habe gerade mal in den Sourcen nachgesehen.
Hier Auszüge aus Wire.cpp
Code:
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)
Code:
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.
Zitieren
):
Lesezeichen