Hi Leute,
wie der Titel schon vermuten lässt, geht es um das TWI oder auch I²C Bus genannt.
Und zwar sind mein Bruder und ich an den WE's wieder aktiver an unserem Quadrocopter dran, passt also vlt. nicht 100%ig hier rein, aber ich versuche es dennoch erstmal hier!
Zur ersten Frage: Kennt sich jemand mit dem TWI überhaupt aus??
Ich habe mich die letzten zwei Wochen intensiv mit dem Thema auseinandergesetzt, (und habe nebenbei eeeendlich das TWI-Protokoll ziemlich gut gerafft! ) aber komme einfach nicht auf die Lösung, bzw. auf keine Erklärung warum das so ist, wie es ist...
Zum Problem: Wir haben ja den Rasberry Pi, meinen uC, die vier Flugregler und den Gyro im TWI-Bus.
Der Raspi ist der alleinige Master, alle anderen, unter anderem halt der uC, fungieren als Slave.
Und nun meint mein uC nach einigen Sekunden, die SDA-Leitung auf Low zu ziehen, und vor allem da zu lassen...
Das lässt sich auch erst mit einem kompletten Reset des uC's beheben. Dann aber nach ein paar (mal mehr, mal weniger) Sekunden, das gleiche Problem.
Warum ich so sicher bin das mein Prozessor der Übeltäter ist?
Ich kann alle Teilnehmer (Hardware- und Softwaremäßig) von dem Bus entfernen, sodass nur noch der Raspi und mein uC mitspielen. Aber keine Veränderung...
Der Raspi ist auch nicht das Problem, da zum einen auf dem Oszi-Bild zu sehen ist, das dieser versucht, seine Bits weiter zu senden, es aber wegen den Open-Collector-Ausgängen nicht schafft die Leitung nach "oben" zu ziehen.
Zudem ist es so, das wenn alle Busteilnehmer wieder im Spiel sind, und ich nur meinen TWI deaktiviere, also mein uC virtuell vom Bus getrennt ist, funktioniert alles ganz wunderbar...
Um die ganze Sache noch etwas zu erschweren gibt es da noch das Detail, das alles bis vor zwei Wochen Tipp-Top funktionierte. Wir haben das Ding bestimmt 0,5-1h am Laufen gehabt und schon ein paar Startversuche gemacht. Das Ding stürzte natürlich aus bis zu 1-1,5m ab. Aber dass das die Ursache sein soll, bezweifle ich. Den Ausleger hat es ein paar mm nach oben verzogen und der Raspi hat zweimal eins auf den Deckel bekommen aber die Platine hat nichts mitgekriegt und sieht optisch absolut iO aus...
Dann, eine Woche später halt das Problem, das der ganze Bus geschrottet wird und, wie gesagt, nach einem uC-Reset wieder für einige Sekunden tut...
Ich hab schon alles rausgeschmissen aus dem Programm und schicke dem Pi nur noch eine Konstante rüber...
Was auch gegen eine Hardwaremäßige Beschädigung spricht: Wenn der Bus verreckt, dann ausschließlich an der selben Stelle! Der Pi (Master) sendet die gewünschte Adresse. In meinem Fall 0100001 -> adr33 und nach der ersten "1" wars das, also quasi 01 00000000000000...
Hier mal ein Bild wie der Fehler aussieht...
Wie gesagt, man sieht noch eine leichte Erhebung bei den "high's"auf dem Bildschirm. So erkennt man noch die korrekte Datenübertragung, wenn die SDA-Leitung nicht auf Low gezogen wäre:
start_condition_0100001_0 _1__00001010 1_repeatet start_0100001_1_1__11001000_1_stop_condition
______________Adr33___W_A*_Wert 10_A*______________Adr33___R_A*_Wert 200_A*
Adr: Meine Adresse im Bus
W: Write-Anforderung des Masters
R: Read-Anforderung des Masters
A*: Acknowledge, eig ist eine 0 ein Ack, aber da mein uC nicht mehr reagiert, gibt es eine 1. Da der Pegel aber so klein ist, erkennt der Pi das als 0 an und sendet munter weiter...
Wert: Der Wert ist im ersten Fall 10, da der Pi mir erst einmal eine Buffer-Adresse schicken muss, der Wert 200 ist der Wert, der in der Buffer-Adresse 10 zu finden ist. Dort kommt später die gemessene Empfängerpuls-Länge 0-255 (1-2ms) rein.
Hier als Referenz das richtige Signal, das die ersten Sekunden über die Leitungen geschoben wird:
Was mir schon aufgefallen ist, ist das zum einen die "high's" der Datenleitung zweistufig zu sein scheinen...
Sprich erst hoch, dann geht der Pegel etwas runter.
Als nächstes ist deutlich zu erkennen, das auch die clk-Pegel unterschiedlich hoch sind, wenn auf der Datenleitung ein "high" liegt. So kann man quasi an der SCL-Leitung die Datenleitung ablesen... *lol*
Der uC bleibt btw. nicht hängen, wenn ich LEDs blinken lasse o.ä. macht der das auch fleißig weiter...
Für die TWI-Übertragung nutze ist übrigens die Lib von dem Kollegen hier:
http://www.jtronics.de/avr-projekte/l…-twi-slave.html
Soo, ich hoffe wirklich seeeehr, das ihr mir da etwas helfen könntet. So langsam ist es frustrierend, nach zwei Wochen lesen, goggeln, denken, Kopfschmerzen_vom_denken_kriegen immer noch keine Lösung gefunden zu haben...