Zitat Zitat von linux_80
...schaut mal hier im Wiki vorbei -> https://www.roboternetz.de/wissen/index.php/TWI_Praxis
für jeden Fall ein kleines Beispiel.
Hatte selber schon ein paar Experimente gemacht, und rausgefunden das es an dem Stopbit liegt.
Es liegt nicht _nur_ am Stopbit bzw. ist das Stopbit im letzten Byte nur ein Symptom..
Ich bekomm das TWDR auch nicht zwischendurch mit dem richtigen Byte ausgelesen, sondern immer nur das nachfolgende, weil das ACK eben schon gesendet wurde und der Master (berechtigterweise) fröhlich weiter macht...

Zitat Zitat von linux_80
Und man kann natürlich auf das TWDR zugreifen bevor man das ACK/NACK abgibt, denn es muss erst das richtige Flag in TWCR gesetzt werden, damits überhaupt weiter geht, automatisch gehts auf jeden Fall nicht.
Was ebend so nicht richtig sein kann, denn sonst würde ja auch das Stop-Bit zum Schluss nicht stören

Ich werd mal meine derzeitige Auffassung der Dinge geben:

Das, was der TWI machen soll, wenn Daten/Adressen kommen sagt man ihm mit dem TWCR.
In dem Basom-Beispiel hat man nichts anderes gemacht als ich auch, nur dass ich zusätzlich noch 'nen Interrupt aufrufen lasse, in dem ich dann eigentlich das TWDR auslesen wollte..

Bascom-Bsp:
Twcr = &B01000100 ' TWI aktivieren, ACK einschalten
ich:
TWCR = (1<<TWINT)|(1<<TWEA)|(0<<TWSTA)|(0<<TWSTO)|(0<<TWW C)|(1<<TWEN)|(1<<TWIE);
// Flag gelöscht (TWI gestartet), ACK senden anstatt No-ACK nach Empfang, Pins an TWI angeschlossen und TWI-Interruptvektor
*) ob ich nun TWINT beschreibe oder nicht, dürfte null Auswirkung haben..

Interessant wäre nun die Diskussion um das TWEA-Bit..
Das Datenblatt des m168 sagt dazu folgendes:
• Bit 6 – TWEA: TWI Enable Acknowledge Bit
The TWEA bit controls the generation of the acknowledge pulse. [highlight=orange:5ea0e0b877]If the TWEA bit is written to
one, the ACK pulse is generated on the TWI bus if the following conditions are met:[/highlight:5ea0e0b877]
1. The device’s own slave address has been received.
2. A general call has been received, while the TWGCE bit in the TWAR is set.
[highlight=orange:5ea0e0b877]3. A data byte has been received in Master Receiver or Slave Receiver mode.[/highlight:5ea0e0b877]
By writing the TWEA bit to zero, the device can be virtually disconnected from the 2-wire Serial
Bus temporarily. Address recognition can then be resumed by writing the TWEA bit to one
again.
Meiner Auffassung und meinem Erleben nach passiert folgendes (in vollkommener Übereinstimmung mit dem hervorgehobenen):
Die TWI Unit empfängt ein Byte und quitiert den Empfang dann während des 9ten SCL Impulses vom Master entweder mit einem ACK oder einem No-ACK und dann kommt schon wieder das nächste Bit, weil der Master ja zurecht annimmt, dass der Sklave weiter machen will. Dazwischen kann man nix machen, das läuft AUTOMATISCH so ab!
Was ich eigentlich bräuchte, wäre das der Sklave die SCL-Leitung gegen Masse zieht und somit dem Master mittteilt, dass der noch auf das ACK oder No-ACK warten muss...

Nur wie mache ich das, wenn ich doch mit dem TWCR Register nur sagen kann, dass er nach dem Empfang eines Bytes ACK oder No-ACK machen soll, aber nicht, dass er die SCL-Leitung auf LOW ziehen soll?
Ich sehe diese Möglichkeit nirgends!!


Ich hab gestern und heut schon 2 Chips gegrillt, weil mein Aufbau mit dem JTAG ICE MK2 und dem Seriell-I²C-Übersetzer irgend wie Mist bauen - zusammen mit dem Notebook und dem Netzteil..
Und das I²C-Terminal-Progg ist auch irgendwie instabil geworden seit neuestem..

Morgen werd ich, um meine 2 verbliebenen m168 zu schonen, erstmal tiny2313 nehmen müssen und versuch dann mal nen reines I²C Prog zum testen, weil mein Code von oben bisher in nem etwas größeren Temperatursteuerungsproggie steckt..

Ihr hört von mir..

Grüße
0tes_Gesetz


PS: vielleicht sollte ich meine Daten lesen, sobald ich Case 1: erreicht hab, also die Adresse erkannt wurde, ACK gesendet wurde und schon die richtigen Daten im TWDR stehen, nur eben eine Runde zu früh (nach meiner Auffassung)..
Hm.. das macht auf eine ganz verrückte Art sogar irgendwie einen verdrehten Sinn.. oder?

Master sagt:
SklaveXXX, ich beschreibe dich!

SklaveXXX:
oh, ich bin gemeint, Geht klar Master!

Master schreibt Datenbyte:
Blablabla..bla..

SklaveXXX:
alle Daten in den TWDR und Flagge setzen wenn fertig, Bing!

Das Interrupt im SklavenXXX findet daraufhin in TWDR das erste Datenbyte und im Statusregister TWSR steht drin, dass sich der SklaveXXX erkannt hat und alles bestens ist (Auslöser des Interrupts war die Adresserkennung!!)

Nun kann der Interrupt in TWCR die Flagge zurücksetzen & löst damit ein "Geht klar Master!" als Meldung an den Master aus, so dass dieser das nächste Datenbyte raufschiebt...

Hm..
Hoffentlich geht das so..
Die Kausalität die dahintersteckt ist mir zwar irgendwie noch suspekt, aber eine andere Möglichkeit seh ich ehrlich gesagt nicht mehr..

Man liest die Daten aus, obwohl man sie eigentlich noch gar nicht erwartet (das im Hinblick auf TWSR, welches ja den "eigentlich" vorherigen Status enthält).. das macht Kopfschmerzen, hoffentlich gewöhnt man sich daran..