"Abstürzen" ist wohl etwas übertrieben... diese TWI Errors besagen das was in der Kommunikation nicht stimmt. Was - läst sich da nicht so genau sagen.
Als Ursachen kommt verschiedenes in Betracht - mir fällt auf das du z.B. I2CTWI_initMaster nicht aufrufst. Somit wird das Bus-Speed-Register nicht gesetzt. Eine falsche Zieladresse wäre aber auch möglich.... oder Verdrahtungs- bzw. Kabelsalat... weis der Geier.
TW_MR_SLA_NACK und TW_MT_SLA_NACK ( 0x20, 0x48 , man beachte das T für Transmit und R für Receive, so oder ähnlich in der .h definiert) sind "unerwartete" Nack Events im TWI Mastermodul... da passiert also was auf dem Bus (oder eben nicht), was nicht passieren soll... allerdings fängt die RP6Lib dieses auch nicht ab und es kommt eben zu diesen "Fehlerketten" im Log. "unerwartet" in so fern, das der TWI Treiber so straight geschrieben ist, das er auf bestimmte Situationen nich reagieren kann und nur stur ein bestimmtes Schema ab arbeitet, was die meisten.. aber eben auch nicht alle Devices können. Quasi eine Minimalversion. TW_MT_SLA_NACK bedeutet z.B. Master sendet und Slave antwortet nicht mit Ack. (wobei das quasi für "Device nicht erreichbar" steht, korrekter Weise bricht man hier die Übertragung schon ab und restauriert den Bus mit STOP bzw. benachrichtigt das aufrufende Programm über "device not found".) Auf die Art kann man sogar ein I2C Bus "durchpingen" wie man es von Netzwerken kennt.. vorausgesetzt man wertet solche Ereignisse auch richtig aus... Es gibt noch ein paar Dinge, die diese TWI Lib nicht kann, die aber Funktionsumfang von I2C/TWI sind... spielt aber hier allgemein und für das spezielle Problem keine gesteigerte Rolle.
Da die TWI Lib nun aber von dem Gerät auch Daten lesen will, was im ersten Anlauf schon nicht angesprochen werden kann, ... und das immer wieder.... ohne jede Fehlerprüfung... *schulterzuck
Gruß Rolf
Zitieren
Lesezeichen