Neues vom TWI Mastermode

Also zunächst bitte mein Edit im 1. Post beachten:
"Das mit dem "Delays entfernen" klappt nicht so ganz wie gedacht, bei der Aussage zum TWIE/TWINT bleibe ich aber."

Ohne Delays sind sind Befehlsfolgen wie:
I2CTWI_transmit3Bytes(I2C_RP6_BASE_ADR, 0, CMD_SET_ACS_POWER, ACS_PWR_MED);
I2CTWI_transmit3Bytes(I2C_RP6_BASE_ADR, 0, CMD_SET_WDT, true);
I2CTWI_transmit3Bytes(I2C_RP6_BASE_ADR, 0, CMD_SET_WDT_RQ, true);
problematisch da sie ohne Delay hintereinander weg auf das TWI geschrieben werden können wärend es noch aktiv ist (was nicht passieren darf!). Schüzen tut da ohne Delay nur das TWINT (ehemals das funktionslose TWIE) bit, was jedoch nach jedem übertragenem Zeichen "frei" meldet. Damit kann eine angefangene Befehlsfolge vom nächsten Transmit Aufruf nach Abschluß eines Bytes (aus der angefangene Befehlsfolge) platt geschrieben werden. Das passiert in der ungefixten Version scheinbar ab und zu auch wenn die Delays ansich zu kurz oder aus irgendeinem Grund die Übertragung zu lange für's Delay ist. (Z.B. wenn 2 Master Busarbitierung durchführen müssen)
Man kann sich an 3 Fingern abzählen das es da schon mal knallt wenn sich der Master sozusagen selbst ins Wort fällt.

Man hatte in den Request Funktionen schon mal versucht das Problem zu erschlagen in dem man ein Hilfsflag lastTransOK verwendet, in den Transmissionfunktionen fehlt das allerdings.

Zudem sind die Delays auf der Base und M32 wegen unterschiedlicher CPU-Clocks unterschiedlich lang. Ansich kein Problem aber die M32 wartet eben nur halb so lange bis es ein weiteres Zeichen sendet.

In meiner Version knallt es hier ohne Delays grade laufend... weshalb mir das auch aufgefallen ist. Das als Zwischenbericht meiner fummeleien hier - es erklärt vielleicht einige Probleme mit dem TWI.

@Fabian E.
Ja ich bin auch gespannt was SlyD sagt. Ich bin noch am debuggen aber du bekommst die Lib als erster zum testen.

LG Rolf