Dicker Fehler in der RP6I2CmasterTWI.h der RP6Lib + Bugfix

[RolfD]

@SlyD
Hm.. hm... auch wahr. Ok, da auf den Schaden zu schließen funktioniert nicht. Sehe ich ein.
Für das I2C Protokoll ist es jedoch von Bedeutung wenn der Master den Bus nicht verfolgt und nach einem Stop "wild" ein Start bzw Daten sendet. Im "schlimmsten" Fall müsste er arbitieren und/oder ein Buserror kriegen...davon hatte ich beides reichlich beim testen. Das kann ich damit evtl. (hoffentlich) reduzieren. Ich werde mich hüten, die Leitungen aktiv zu steuern ... mir ist schon nicht wohl bei der Umsetzung wie in dem Bugreport die Leitungen abzufragen. Geht zwar aber irgendwas werden sich die Entwickler bei Atmel dabei gedacht haben... die Frage ist nur was. Da bin ich mit dem (N)ACK nach STOP wohl näher dran.... hoff ich.

Andere Frage, wie kriege ich zuverlässig raus, ob noch weitere Devices was abbekommen haben? Reicht es, die Diodenstrecken von SDA und SCL zu messen? Mein M32 Modul und das I2C LCD device sehen nach dieser Messung gesund aus aber ich will mir mein Board nicht gleich wieder zerlegen weil ich was nicht beachtet hab.

EDIT: Mir ist grade aufgefallen, das ich bei einer meiner letzten Umräumaktionen im code eine wichtige Abfrage verschusselt habe.
Und zwar fehlt in task_I2CTWI um das ganze Switch Konstrukt die Zeile:
if bit_is_clear(TWI_statusReg,STR_isr) {
und unten dann }
Ohne die Abfrage überrennen sich natürlich die Befehle wieder... was zu Allem führt.. nur nicht zu einer geordneten Datenübertragung. Sorry. Wirklich lauffähig ist der Code aber auch dann noch nicht. Ich wieder einige Problemstellen gefunden.
Es hat sich auch sonst wieder einiges getan im Source. Es gibt jetzt einen speziellen 400KHz Mode für den 100KHz Bus, eine Fehlerbehandlung mit Zähler und Retry, ein Timeout bei Fehlern, syncrone/asyncrone Ausführung ... ich hoffe mein Board ist schon unterwegs da ich so vieles nicht wirklich testen kann. Hab zwischenzeitlich WinAVR ausprobiert aber der SIM ist nicht besonders geeignet um ISRs zu debuggen, sonst aber ganz nett.

EDIT: Ein netter Mensch hier aus dem Forum ist bereit mir sein RP6 zu verkaufen, demnächst hab ich also 2 Stück... und kann besser vergleichen. Mal sehen was zuerst eintrifft. Das Ersatzboard oder der Zukauf. Und dann gehts endlich weiter...

EDIT: Da mein Board noch nicht hier ist, Suche ich diverse Schaltungen und Knowhow zum Thema AVR und I2C. Nun ist mir aufgefallen, das manche die Pullups bis 470 Ohm - also auf 10% dessen runter setzen was aktuell im RP6 anliegt - allerdings dann mit einer LED im Zweig gegen VDD. Namentlich z.b. die ATmega8 ASM Treiber im www.mikrocontroller.net für Master/Slave Betrieb mit Schaltplan. Dies bedeuet natürlich ordentlich Laststrom in der Ausgangsstufe des AVR, zieht die Leitung aber bei high weiter nach VDD. Sie baumelt ja bei mir normal derzeit so um 2 V, mit der LED zum testen nun bei 3V -3,5V im Highzustand.

Ich hab mal ein Filmchen davon gemacht.
http://home.arcor.de/rolf.diesing/daten/P1100529.MP4 (fliegt die Tage wieder raus... )

Die CPU befindet sich zu dieser Zeit GARANTIERT in einer While (true) Schleife, es finden keine Datenbewegungen statt und wenn die CPU SDA auf low schaltet also aktiv Daten schiebt, leuchtet die LED erwartungsgemäß kräftig. Die gelbe 5mm LED flackert hier schwach obwohl der AVR nichts auf den Ports macht. Mein Oszi zeigt ebenfalls oben die grade laufende SCL Leitung bei 5v und unten die flackernde SDA Leitung (Oszi im Dual chopper Mode, 1V/cm 20ms/cm). Und das Ganze mit 470 Ohm Pullup an der LED. Mit der Schaltung kriege ich übrigends fast zuverlässig Daten auf ein I2C LCD mit PCF8574 geschrieben da ich nun halbwechs definierte Logikpegel habe. Die Störungen/Flackern tritt jedoch auch bei der Datenübertragung auf und einlesen kann der Port damit immer noch nicht richtig. Ohne die LED und nur mit R32 flackert der SDA Port sonst irgendwo bei 1,2V und 2,2V ... ich hätte aber ehrlich gesagt nicht mal damit gerechnet, das es mit der LED klappt, denn da muss ja irgendwo in der CPU ein angeschlagener Transistor sein und der kriegt nun locker 10mA ab.

EDIT: So... mein 2ter RP6 steht auf dem Tisch, heute war der Paketbote da, es kann weiter gehen. Das Ersatzboard aus Holland ist leider noch nicht da. Die M32 ist auch wieder angeflanscht und die Hardware ist damit jetzt erst mal wieder soweit ok das ich Base und Master zugleich testen kann. Erste Messungen an SDA/SCL ergeben erwartete Werte und ordentliche Pegel. Ich werde zusehen, das ich Dirks letztes Programm ans laufen bekomme und bald eine neue beta rausbringe. Ich habe durch den 2.ten Bot nun auch 2 USB-Adapter. Man kann zwar 2 Robotloader starten aber wenn man Verbindung zum ersten USB Adapter aufbaut, verweigert der Loader beim 2. dann mit Hinweis das die Schnittstelle "in use" sei. Base und M32 gleichzeitig debugen geht also immer noch nicht aber ich brauche zumindest nicht mehr umzustecken. Wäre schön wenn man den Loader (ich hab 1.5h) da noch anpassen kann.

EDIT: Mein Ersatzboard von AREXX ist da Das ist die Gute Nachricht... die schlechte - man hat bei AREXX das Board in einen wattierten Umschlag gepackt und die Post hatte nix besseres zu tun als da massenweise Stempel mit "Priority mail" draufzukloppen.... 8-9 Stück... beidseitig.... und das ganze für eine Strecke von unglaublichen 231 Km und min. 1 Woche unterwegs... Ich muss leider erst testen ob das Board das überlebt hat ... mit grade biegen von Teilen isses da leider nicht mehr getan. Der Schalter, der sich schon durch die Briefhülle gedrückt hatte ist jedenfalls hin... aber da kann ich den aus dem alten Bord umlöten. Oh man... nur Ärger!

EDIT: Das I2C treibt mich noch in den Wahnsinn...