Hallo, hat von euch jemand Erfahrung mit der Verwendung von TWI / I2C mit dem Arduino Due? Ich benutze einen Atmega32U4 mit dieser I2C Bibliothek Beitrag "AVR TWI Master und Slave Funtionen in C" und einen Arduino Due mit dem Wire-Library. Eine von beiden verursacht bei mir Probleme, und ich vermute, dass es die Arduino-Library ist... Funktioniert die von Arduino mitgelieferte Library mit einem Arduino Due bei euch problemlos? Viele Grüße, Christian
Christian schrieb: > Funktioniert die von Arduino mitgelieferte Library mit einem Arduino > Due bei euch problemlos? Du solltest die Fehler erst einmal bei dir suchen, anstelle von einer Arduino Lib welche täglich Tausende von Menschen verwenden.
Die Wire library ist ziemlich buggy! http://forum.arduino.cc/index.php?topic=144700.0 https://github.com/arduino/Arduino/pull/1994
Kassiopeia schrieb: > Die Wire library ist ziemlich buggy! Bei einem Arbeitskollegen seit mehreren Montaten Fehlerfrei in Betrieb..
San Lue schrieb: > Christian schrieb: >> Funktioniert die von Arduino mitgelieferte Library mit einem Arduino >> Due bei euch problemlos? > > Du solltest die Fehler erst einmal bei dir suchen, anstelle von einer > Arduino Lib welche täglich Tausende von Menschen verwenden. Da in der Wire-Lib für den Due aber einige Fehler bekannt sind, wollte ich erstmal eure Erfahrungen hören, denn die Lib, die ich für den Atmega verwende wird auch von vielen Leuten verwendet und ich hatte mit dieser auch noch nie Probleme. Kassiopeia schrieb: >Die Wire library ist ziemlich buggy! >http://forum.arduino.cc/index.php?topic=144700.0 >https://github.com/arduino/Arduino/pull/1994 Genau auf die Fehler bin ich auch schon gestoßen und habe auf die Arduino 1.5.9 Version gewechselt, wo der Fehler gepatcht ist.
San Lue schrieb: > Kassiopeia schrieb: >> Die Wire library ist ziemlich buggy! > > Bei einem Arbeitskollegen seit mehreren Montaten Fehlerfrei in Betrieb.. Auch auf dem Arduino DUE ???
Christian schrieb: > Auch auf dem Arduino DUE ??? zu 99,9 % sicher. Schreibe ihm gleich noch ne SMS und Frage ihn noch kurz, bin derzeit nicht auf der Arbeit. Vielleicht lässt er mir paar Bilder oder Code zukommen, dann würde ich sie dir hier zur Verfügung stellen.
San Lue schrieb: > Du solltest die Fehler erst einmal bei dir suchen, anstelle von einer > Arduino Lib welche täglich Tausende von Menschen verwenden. Oder aber auch nicht! Bei den AVR basierten Arduinos mag das stimmen, der DUE hat leider noch nicht die Verbreitung, da klemmen noch ein paar Dinge. Das Problem ist wohl auch, das die Arduino-Libraries sich zunächst sehr an den Möglichkeiten des 328P orientiert haben, und der Kompatibilitätsanpruch auch hardwareseitig zu merkwürdigen Dingen führt. Zum Beispiel werden jeweils zwei Pins des SAM3X8E einfach kurzgeschlossen auf jeweils einen PIN des DUE geführt: PC29 und PA28 auf PIN 10 PA29 und PC26 auf PIN 4 Dies nur deswegen, dass somit auf diesem Pin sowohl PWM als auch SPI-CS angeboten werden kann. Keine Möglichkeit vorgesehen, eine der beiden Leiterbahnen wenigstens kontrolliert trennen zu können... Wenn nun beide PINs des SAM auf Output gesetzt werden, der eine High, der andere Low ..... Der DUE und seine Clones, insbesondere der DigiX sind interessante Boards, weit leistungsfähiger als die AVRs, aber die Arduino-Libs sind dafür in vielen Bereichen noch bestenfalls BETA
Christian schrieb: > Auch auf dem Arduino DUE ??? Gerade auf dem DUE, wie die Links zeigen! Kommt jeweils drauf an, was man damit macht. Bibliotheken, die z.B. den Returncode von Wire.endTransmission() nicht auswerten laufen. Bibliotheken, oder Programme, die das Auswerten haben Probleme. Bei mir laufen auch einige Dinge, andere liefen erst, als ich gepatcht habe.
Kassiopeia schrieb: > Christian schrieb: >> Auch auf dem Arduino DUE ??? > > Gerade auf dem DUE, wie die Links zeigen! Vermute die Aussage war eher auf mein Post bezogen. Melde mich, sobald ich Antwort vom Kollegen habe ;)
sorry, falsche Nachricht markiert ... ;-) Da der TO nun auf die 1.5.7 umgestiegen ist, wird er bald melden, ob es das war.
Kassiopeia schrieb: > sorry, falsche Nachricht markiert ... ;-) > > Da der TO nun auf die 1.5.7 umgestiegen ist, wird er bald melden, ob es > das war. Ja ich bin schon vor ein paar Tagen umgestiegen. Danach war ein Problem behoben. Aber das war scheinbar noch nicht alles. Der Arduino beendet das Senden von Daten scheinbar noch immer nicht sauber. Ich erstelle im Laufe des nachmittags mal ein Minimalbeispiel, das auch die Codes des Statusregiserts zeigt. Da wird mein Problem deutlich! Danke schonmal!
So ich konnte das Problem eingrenzen. Es passiert, wenn ich vom Arduino mehr als 1 Byte an den Atmega sende. Der Arduino fordert alle 500ms ein Byte Daten vom Atmega. Der Atmega sendet daraufhin Decimal 36 Wenn ich nun ein Zeichen in die Arduino-Konsole eingebe, soll der Arduino einmalig die beiden Bytes mit den Decimalwerten 37 und 38 senden Ausgabe des Atmegas (Slave):
1 | TWSR: 0xa8 // Slave soll Daten senden |
2 | Sende: 36 // Slave sendet Daten |
3 | TWSR: 0xa8 // Slave soll Daten senden |
4 | Sende: 36 // Slave sendet Daten |
5 | (...Hier bekommt der Arduino die Aufforderung, die Daten zu senden...) |
6 | TWSR: 0xf8 // TWI_NO_STATE |
7 | TWSR: 0x60 // Slave soll Daten lesen |
8 | Empfange: 37 und 38 // Slave liest Daten |
9 | TWSR: 0xa8 // Slave soll Daten senden |
10 | Sende: 36 // Slave sendet Daten |
11 | TWSR: 0x60 // Ab hier wirds merkwürdig: Der Arduino möchte weiterhin Daten senden, obwohl er dies gar nicht soll! |
12 | Empfange: 37 und 74 // Arduino sendet fehlerhafte Daten (2. Byte falsch) |
13 | TWSR: 0xa8 // und dann gehts immer so weiter... |
14 | Sende: 36 |
15 | TWSR: 0x60 |
16 | Empfange: 37 und 74 |
Der Arduino scheint irgendwie das Senden der Daten nicht korrekt zu beenden und sendet Byte 1 immer wieder und Byte 2 auch, aber mit einem falschen Wert... :-S Wenn ich nur ein Byte sende, ist alles Prima! Übersehe ich etwas?
Okay ich bin noch einen Schritt weiter: Das zweite "falsche" Byte ist immer das erste Byte*2. Das spricht dafür, dass irgendwie das Byte nach links geshiftet und nochmal gesendet wird. Das spricht für mich irgendwie dafür, dass der Arduino das zweite Byte als Adresse interpretiert. Die Adresse wird dann um 1 Bit nach links geshiftet und um 0 erweitert, sodass sich SLA+R (Slaveaddress und Read-Bit) ergibt.
in der Wire.cpp von Arduino hat die Funktion Wire.EndTransmission den parameter sendStop. Diesen kann man zwar übergeben, aber er wird nirgends verwendet :-S Was ist denn das für ein Murks?
1 | //
|
2 | // Originally, 'endTransmission' was an f(void) function.
|
3 | // It has been modified to take one parameter indicating
|
4 | // whether or not a STOP should be performed on the bus.
|
5 | // Calling endTransmission(false) allows a sketch to
|
6 | // perform a repeated start.
|
7 | //
|
8 | // WARNING: Nothing in the library keeps track of whether
|
9 | // the bus tenure has been properly ended with a STOP. It
|
10 | // is very possible to leave the bus in a hung state if
|
11 | // no call to endTransmission(true) is made. Some I2C
|
12 | // devices will behave oddly if they do not see a STOP.
|
13 | //
|
14 | uint8_t TwoWire::endTransmission(uint8_t sendStop) { |
15 | uint8_t error = 0; |
16 | // transmit buffer (blocking)
|
17 | TWI_StartWrite(twi, txAddress, 0, 0, txBuffer[0]); |
18 | if (!TWI_WaitByteSent(twi, XMIT_TIMEOUT)) |
19 | error = 2; // error, got NACK on address transmit |
20 | |
21 | if (error == 0) { |
22 | uint16_t sent = 1; |
23 | while (sent < txBufferLength) { |
24 | TWI_WriteByte(twi, txBuffer[sent++]); |
25 | if (!TWI_WaitByteSent(twi, XMIT_TIMEOUT)) |
26 | error = 3; // error, got NACK during data transmmit |
27 | }
|
28 | }
|
29 | |
30 | if (error == 0) { |
31 | TWI_Stop(twi); |
32 | if (!TWI_WaitTransferComplete(twi, XMIT_TIMEOUT)) |
33 | error = 4; // error, finishing up |
34 | }
|
35 | |
36 | txBufferLength = 0; // empty buffer |
37 | status = MASTER_IDLE; |
38 | return error; |
39 | }
|
weitere Frage: Wie sind die beiden Controller verbunden? Hast Du einen Levelconverter/Zenerdiode etc. dazwischen? Ich gehe mal davon aus, dass der AVR mit 5V betrieben wird.
Die laufen beide auf 3,3V. Die Pullups sitzen auf dem Board vom Atmega. Die Massen der beiden Controller sind verbunden. Levelconverter und Dioden gibs nicht.
Kenne mich mit I2C nur sehr flüchtig aus, hatte aber mal ein ähnliches Problem. Lag daran dass ich nicht bedacht hatte, dass beim ersten Byte das Bit 0 für R/W steht. Vielleicht hilft dir ja das irgendwie weiter... Vielleicht ist es auch totaler Müll was ich erzähle, aber ein versuch ist es wert hehe
TWI schrieb: > Kenne mich mit I2C nur sehr flüchtig aus, hatte aber mal ein > ähnliches > Problem. Lag daran dass ich nicht bedacht hatte, dass beim ersten Byte > das Bit 0 für R/W steht. Vielleicht hilft dir ja das irgendwie weiter... > Vielleicht ist es auch totaler Müll was ich erzähle, aber ein versuch > ist es wert hehe Damit hast du schon recht, aber das sollte normalerweise nur bei der Übertragung der Adresse eine Rolle spielen. Die anschließenden Datenbytes sind volle 8 Bit.
Fehler gefunden -.- Nach Wire.Read() darf kein Wire.EndTransmission() stehen!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.