I²C Master m328 kann Slave m328 nicht lesen

[PicNick]

Wirklich steckenbleiben kann er ja eigentlich nur bei

    i2c_write(0x00);            // Da kann man hängen bleiben, wenn der Slave mit "clock-stretch" den master auf das ACK warten lässt
    i2c_rep_start(SLAVE_ADRESSE+I2C_READ); // da bleibt man hängen, wenn der Slave den Bus nicht freigibt.

Ich weiss nicht, ob bei der Lib ein "Timeout" für diese zustände eingebaut ist. (offenbar nicht)
Baue zwischen den Befehlen erstmal irgendeine LED-Flunzlerei ein, damit du siehst, ob er bei "write" oder "rep_start" hängen bleibt.

EDIT: bei HW-TWI sollte so ein ewiger CLock-stretch eigentlich nicht möglich sein. d.h. der Verdacht richtete sich auf den Rep_Start.

[oberallgeier]

Erstmal danke, ich geh in ner Weile drüber (aktuell total lahme Hände/Arme, zuviel Kletterhalle).

[PicNick]

Du weisst ja, wenn's hinten weh' tut, soll man vorn' aufhören

[oberallgeier]

... ob ... ein "Timeout" ... eingebaut ist. (offenbar nicht) ...

Offenbar nicht. Ist nicht zu sehen. Und ich habe meine LED/Leuchtfeuer-Kommunikation weiter ausgebaut:

... Baue ... irgendeine LED-Flunzlerei ein ... Verdacht ... auf den Rep_Start.

Damit ist der "i2c_rep_start" als Missetäter überführt. Also drei i2c_readAck/Nak();// Bytes lesen haben das Koma verhindert. Jetzt schaue ich mal mit nem zusätzlichen USART nach was da gelesen wird (der gibt im Moment nur Schrott aus - seltsam.

Danke jedenfalls für den guten Tip, den rep_start zu verdächigen - das war ein Treffer.


[OT]"... wenn's hinten weh' tut, soll man ..." Ich klettere eigentlich immer Gesicht zur Wand . . . . [/OT]

[oberallgeier]

So. Es stimmt. Drei "i2c_readAck/Nak();// Bytes lesen" statt des "i2c_rep_start" haben das Koma verhindert.

Zum Glück habe ich mir über UART vom Master die nun gelesenen Bytes ausgeben lassen. Baaahhhh - die waren (nur) die übermittelten Adressen(offsets) des zu lesenden Bytes. Also noch schnell ein "i2c_start(SLAVE_ADRESSE+I2C_READ)"-Commando, aber nicht das "i2c_rep_start(SLAVE_ADRESSE+I2C_READ)"! eingefügt - und schon steht wieder alles.

Aktuell gilt u.A. dies:

Modul "master", defines + includes vor "main" enthält u.a.
 #define SLAVE_ADRESSE 0x70
Modul "i2cmasterl.h" (l=lokal) enthält u.a.
/** defines the data direction (reading from I2C device) in i2c_start(),i2c_rep_start() */
#define I2C_READ    1
/** defines the data direction (writing to I2C device) in i2c_start(),i2c_rep_start() */
#define I2C_WRITE   0
 

Fazit: I2C-Slave-Schreiben geht, I2C-Slave-lesen geht nicht ... und bin so klug als wie zuvor.

[oberallgeier]

Sooo, nun gehts.

Danke Robert für den Hinweis auf den möglichen Fehler. Mittlerweile habe ich den Code für den Test des Master geringfügig ergänzt und das Auslesen, auch mit "i2c_rep_start" funktioniert jetzt klaglos und sicher. Ich dagegen bin nicht sicher, dass der Code "... Testprogramm für den Master..." aus dem RNWiki bei anderen Anwendungen funktioniert (steht ja extra dort "... getestet ..." - allerdings heißt es nicht, dass der auch läuft *ggg*) - wie geschildert gings bei mir nicht. Ich meine trotz meiner bescheidenen Kenntnisse, dass der Codeschnippsel gerade für Testzwecke verbesserungswürdig ist.

Trotzdem danke Robert.

[Chypsylon]

Ich hatte heute das gleiche Problem (schreiben geht -lesen nicht), und auch in anderen Threads wird berichtet das lesen nicht funktioniert. Ich verwende jetzt die Library von http://www.jtronics.de/avr-projekte/.../twi-slave-avr , die auch auf Anhieb funktioniert hat und vom Aufbau relativ gleich ist...

[oberallgeier]

Hi Chypsylon,

Ich hatte heute das gleiche Problem (schreiben geht -lesen nicht), und auch in anderen Threads wird berichtet das lesen nicht funktioniert ...

Ja ja, die jtronics, nicht schlecht . . .
Die lib von PFleury ist sicherlich ok - und ob die andere Lib nen timeout hat, hatte ich noch nicht nachgesehen. Ich glaubs aber nicht. PFleurys lib läuft bei mir gut, ich habe jetzt nicht nur einen Beschleunigungsmesser gelesen und beschrieben (Einstellregister modifiziert) sondern auch meine mega328-mega328-Kopplung von Steckbrett/8Mhz-int zu Experimentierplatine/20MHz-Quarz problemlos in Funktion. Sowohl Schreiben als auch Lesen. Ausserdem hatte heute nachmittags mein Master-Testcode noch ne kurze, erfolgreiche Unterhaltung mit (m)einem EEPROM 24C16 gehabt. Einwandfrei. Nur das Beispiel im R N Wissen hat möglicherweise ne Macke - ich hatte ja erwähnt "... getestet ..." heißt noch lange nicht "erfolgreich getestet" - und bei Dir gehts ja auch prompt nicht.

[oberallgeier]

Um die Erledigung der Frage korrekt zu begründen, hier den aktuellen Stand.

Es werden vom Master (mega328/8MHz-intOsz) drei Bytes an den Slave (mega328bzw.168/20MHz-Quarz) gesendet. Je nachdem ob eine Taste gedrückt oder nicht gedrückt ist, werden zwei unterschiedliche Datensätze gesendet. Slaveadresse Schreiben x70, Slaveadresse Lesen x70+1. Schreibziel ist Position 2 bis 4 des Zielspeichers {von 1 bis 10 möglichen Plätzen}. Nach dem Senden des Datensatzes werden die drei Bytes zurückgelesen. Senden, Zurücklesen und evtl. Fehlermeldung werden im Terminal ausgegeben, siehe Beispiel der Ausgabe des Masters. Es ist eine Terminalverbindung des Masters (9600 Bd da ohne Quarz), des Slaves (128kBd) und des Sniffers (57600 Bd) eingesetzt.

......

Um die Unterhaltung der beiden Controller mitzuschneiden wurde ein Sniffer (klick) gebaut (Dank an PDannegger). Tiny2313 mit 16MHz-Quarz. Beispiel für einen Mitschnitt:

I2C-Sniff 2313:
...
s70a01a36a37a38ap<\r
...
s70a01a36a37a38ap<\r>

Der Sniffer ist noch verbesserungswürdig, die Ausgaben sind gelegentlich gestört. Der obige Mitschnitt zeigt zweimal :
Sende an Adresse x70 / Speicherplatz 01 {von 10} / Datum x36 senden mit ACK / Datum x37 senden mit ACK / Datum x38 senden mit NAK / Stop