hm.... hm....
also erst mal danke für das "testsystem", das ist ein schöner Test und genau das was ich als Ansporn brauche um hier weiter zu basteln. Und ggf. auch ein Hinweis woran es liegen kann. Ich hab beide Sources compiliert und kann dein Ergebnis bestätigen, allerdings weis ich noch nicht wieso das so ist - es ist jedenfalls nicht gut das es so ist!

Mir drängt sich der Verdacht auf, das es mit anderen Interrupts im System zu tun hat, z.B. dem Timerinterrupt. Oder die Messung aller Sensoren... Das würde zumindest die relative Regelmässigkeit der Errors erklären. Die TWI-isr versucht ja alles anzunehmen was kommt aber wenn jemand extern mit cli/sei den Interrupt abdreht, kriegt die ISR das ja nicht mit, folglich schlagen Bytes auf, die in der isr nicht verarbeitet werden und schon meldet dein Programm ein Fehler oder die TWI rising Buserros oder so'n quark.
Würde man das jetzt perfektionieren wollen, würde man wie im Ethernet bzw. ISO-OSI Modell eine logische Netzwerkschicht mit Fehlererkennung einbauen.. sprich alle Daten mit CRC-Prüfsumme versehen. Dann kann der Client (Base) ein retransmit anfordern. Nur das ist beim TWI mit Kanonen auf Spatzen geschossen und für die Datenübertragung zu I2C Slaves auch garnicht machbar (und bei einer Fehlerquote von 33% eh witzlos). Das Problem betrifft vor allem den Slavemodus, mit dem Sender (Master) hat das nur so viel zu tun da er viel sendet, aber weit weniger als der TWI Bus zulässt. Es ist auch nicht auf die Geschwindigkeit allgemein zu schieben, die bewegt sich im Bereich wo auch jedes normale UART läuft. Als Master führt man den SCL-Takt, wird ein Timerinterrupt ausgeführt geht nichts verloren, der Slave merkt nur das der Master "ruckelt" beim arbeiten. Als Slave muss er aber immer und zu jeder Zeit alle Datenbytes annehmen können oder ein NACK senden worauf hin der Master normal die Übertragung abbricht. Im Fall von verlorenen Bytes kann der Slave aber nicht mal NACKen... Ist also auch keine Lösung.

Die resultierende Frage ist also.... : Wie bringt man dem Rest der Lib bei, die Füße still zu halten bzw. sich mit der TWI zu arrangieren so lange eine Übertragung am TWI läuft?

Zweite Frage: betrifft das nur den Slave oder ist auch der Master Receiver Mode betroffen (lesen von großen Datenmengen aus einem EPROM als Master z.B.) Ich vermute stark, es ist nur der Slave betroffen.
@Dirk, kannst Du dein Programm mal umschreiben so das der Master (M32) möglichst große Datenmengen beim Slave (Base) liest und verifiziert. Das wäre eine wichtige Frage das zu klären. Danke schon mal.

*kopfkratz
SlyD hast Du eine Idee bzw. kannst Du den Gedankengang bestätigen?
Ich grübel mal weiter. SO ist das TWI jedenfalls kein wirklicher Gewinn für den RP6 mit Zusatzboards. Aber ich bin sicher, das geht noch besser....

Ich schau mir das jetzt erst mal genauer an... ich habe übrigends mal
//#define TEXT_OUTPUT // Show text
im Slave ausgeschaltet und prompt habe ich auf ca. 3500 übertragene Werte nur noch ca. 20 Fehler... also unter 1% ... und nicht mehr jedes dritte Datum im Eimer. Ein Hinweis das auch die (Echtzeit)UART-Ausgabe hier nicht ganz unbeteiligt an der Fehlerdichte ist.
Ich hab nur leider keine wirkliche Idee, wie man das in den Griff bekommt... Slyds Worte oben bekommen grade einen ganz neuen Sinn für mich...

"This Code works OK, but it is not optimal! There is a lot potential for tuning!"

Man muss aber fairer Weise dazu sagen, das Amtel für Multiprozessorkommunikation den UART vorgesehen hat... und nicht das TWI, der UART hat sogar ein besonderen Modus dafür. Man könnte sich auch anders behelfen, z.B. indem man ein pcf8583.h mit immerhin 240 Byte RAM im System vorsieht auf den beide CPU's als Master zugreifen und dort Daten austauschen. Nur dafür ist ab Werk weder der RP6 noch die Software ausgelegt. Wenn man zuverlässige Ergebnisse erwartet, sollte man z.Z auf den Slavemode wohl eher verzichten - oder/und fehlertolerant proggen und tatsächlich sowas wie ne CRC vorsehen. Kommt halt auf den Zeck an.

*grins

Aber für uns Robotbauer wäre es immerhin schon mal interssant wenn der Multimastermode richtig funktioniert und die Daten zuverlässig ankommen wie sie abgeschickt wurden... das war bisher nicht immer der Fall und da lohnt es sich die Lib noch zu verbessern. Den Slavemode... tja... mal sehen aber ich denke das schaut nicht gut aus... vielleicht ists aber auch nur ein kleiner fieser Bug... mal sehen.

EDIT:
Für die Betatester eine kleine Änderung am Include File, bitte

#define I2CTWI_isBusy() ((TWCR & (1<<TWINT)))
durch
#define I2CTWI_isBusy() (bit_is_set(TWI_statusReg,STR_isr))

ersetzen. Hintergrund ist, das TWINT Bit spielt für die Übertragung eines kompetten "Satzbaus" im TWI (Start Daten Stop) keine Rolle, eine Aussage darüber ob die TWI frei ist gibt hingegen das STR_isr in TWI_statusReg (abhängig von der Stop condition) , folglich muss das geändert werden. Die Lowlevelfunktionen warten eh auf das STR_isr aber um festzustellen ob ein Task Rechenzeit braucht - wie in dem Master testprogramm - sollte es natürlich die richtigen Bedingungen abfragen.

Gruß RolfD