TSL2591 TWI falsche Sequenz?

[Attila C. (attila)]

Hallo !

Ein TSL2591 soll mit einem Atmega8 über TWI "sprechen".

Meine Abfolge laut Oszi ist:

W29-00-A0-W29-12-R29-12

Am Ende sollte aber 50 (Die Device ID) rumkommen und nicht 12.

Ich habe das ganze so aufgebaut wie im Datenblatt des Atmega8 und halte 
mich auch an die Abfolge (START / SLA+W  a  Data  a  STOP)
Das ( wie ich finde: dürftige) Datenblatt des TSL2591 beschreibt auch 
diese Sequenz. Zumindest verstehe ich es so.

Ich habe im Netz Code gefunden der einen 8 bit read so durchführt:
beginTransmission(I2C_ADDR)
write(Cmd)
endTransmission()
requestFrom(I2C_ADDR,)
read()

Was bedeutet "endTransmission" hier? Mit einem STOP an der Stelle habe 
ich bereits experimentiert, das hat nicht geklappt.

Ich habe gestern mit einem MPL3115 "gesprochen" Es sollte also nicht am 
grundsätzlichen Code oder an der Hardware liegen.

Vielen Dank schon mal!

[John Doe (Gast)]

Attila C. schrieb:
> Hallo !
>
> Ein TSL2591 soll mit einem Atmega8 über TWI "sprechen".
>
> Meine Abfolge laut Oszi ist:
>
> W29-00-A0-W29-12-R29-12

Warum stellst Du nicht Deinen Code ein? Den kann man viel besser lesen 
als diese kryptische Ausgabe.


> Am Ende sollte aber 50 (Die Device ID) rumkommen und nicht 12.
>
> Ich habe das ganze so aufgebaut wie im Datenblatt des Atmega8 und halte
> mich auch an die Abfolge (START / SLA+W  a  Data  a  STOP)
> Das ( wie ich finde: dürftige) Datenblatt des TSL2591 beschreibt auch
> diese Sequenz. Zumindest verstehe ich es so.

Da das "Standard-I2C" ist, braucht auch nicht mehr im Datenblatt zu 
stehen. Wie I2C funktioniert, steht in der Spec.


> Ich habe im Netz Code gefunden der einen 8 bit read so durchführt:
> beginTransmission(I2C_ADDR)
> write(Cmd)
> endTransmission()
> requestFrom(I2C_ADDR,)
> read()
>
> Was bedeutet "endTransmission" hier? Mit einem STOP an der Stelle habe
> ich bereits experimentiert, das hat nicht geklappt.


Schau Dir nochmal an, wie I2C funktioniert, dann erledigen sich einige 
Fragen. Und stell den Code ein.

[Attila C. (attila)]

Bitteschön John Doe! Dieser Code lief , entsprechend angepasst, bereits 
mit einem MPL3115A2, MPXV7002DP, PCA9685, DS1307 und HMC5883L.

Ich war jetzt 5 Jahre raus und bin daher gespannt was ich übersehen 
habe!

[Planloser (Gast)]

Bin jetzt kein AVR-Spezialist, aber:

TWDR = 0x52;  // Slave address ist 0x29

[Oliver S. (oliverso)]

Bei TWI bedeutet 0x52 schonmal 0x29 ;)

Passt schon.

Oliver

[Oliver S. (oliverso)]

Wenn du am Oszi erkennen kannst, daß dein Schreib- und Lesezyklus 
komplett durchlaufen wird, dann ist der generelle I2C-Ablauf ja schonmal 
in Ordnung. Wenn nicht, dann nicht.

Laut Datenblatt wird das CMD-Register über das gesetzte Bit 7 im 
Datenbyte angesprochen. Das finde ich in deinem Ablauf oben aber nicht.

Oliver

[John Doe (Gast)]

Oliver S. schrieb:
> Wenn du am Oszi erkennen kannst, daß dein Schreib- und Lesezyklus
> komplett durchlaufen wird, dann ist der generelle I2C-Ablauf ja schonmal
> in Ordnung. Wenn nicht, dann nicht.
>
> Laut Datenblatt wird das CMD-Register über das gesetzte Bit 7 im
> Datenbyte angesprochen. Das finde ich in deinem Ablauf oben aber nicht.

Eben. Bit 7 und 5 müssen gesetzt sein. Also zur Adresse noch 0xA0 
dazuaddieren und es läuft.

[Attila C. (attila)]

Naja 0x29 "mit" dem Write bit wird dann ja zu 0x52, respektive 53 bei 
Read. Beim Atmega TWI steht dann "SLA + W oder SLA + R.

Zumindest bei meinen bisherigen Experimenten war es so dass, wenn ich 
das TWI "vergeigt" hatte keine Kommunikation stattfand. Jetzt findet ja 
eine Kommunikation statt , es stimmt nur die Antwort nicht.

Daher ja auch die Vermutung das in der Abfolge etwas nicht stimmt und 
nicht in der TWI Kommunikation an sich.

[John Doe (Gast)]

John Doe schrieb:
> Oliver S. schrieb:
>> Wenn du am Oszi erkennen kannst, daß dein Schreib- und Lesezyklus
>> komplett durchlaufen wird, dann ist der generelle I2C-Ablauf ja schonmal
>> in Ordnung. Wenn nicht, dann nicht.
>>
>> Laut Datenblatt wird das CMD-Register über das gesetzte Bit 7 im
>> Datenbyte angesprochen. Das finde ich in deinem Ablauf oben aber nicht.
>
> Eben. Bit 7 und 5 müssen gesetzt sein. Also zur Adresse noch 0xA0
> dazuaddieren und es läuft.

Also 0xB2 anstelle 0x12 an die Empfangsfunktion übergehen, damit keine 
Missverständnisse verstehen ;)

[John Doe (Gast)]

Steht im Datenblatt auf Seite 11 (Datasheet - Apr. 2013 - ams163.5).

[Attila C. (attila)]

Also ich habe in der while Schleife unmittelbar vor dem Read 
"I2Csend(0x00,0xA0);" stehen.
Ich habe es so verstanden dass das Register 0x00 das Command Register 
ist in jenes ich ja "0xA0" also Bit 7 und 5 setze/schreibe.

[Oliver S. (oliverso)]

Attila C. schrieb:
> Zumindest bei meinen bisherigen Experimenten war es so dass, wenn ich
> das TWI "vergeigt" hatte keine Kommunikation stattfand. Jetzt findet ja
> eine Kommunikation statt , es stimmt nur die Antwort nicht.

Weil du die falschen Daten sendest.

Oliver

[Attila C. (attila)]

"Eben. Bit 7 und 5 müssen gesetzt sein. Also zur Adresse noch 0xA0
dazuaddieren und es läuft."

Ahaaaaaa! Puh, da soll mal einer drauf kommen! Vielen vielen Dank! Ihr 
seid die Größten! :-)

[Oliver S. (oliverso)]

Attila C. schrieb:
> ist in jenes ich ja "0xA0" also Bit 7 und 5 setze/schreibe.

Eine Sequenz zum lesen der Device ID wäre

Start
Adresse 0x29 Write
Data 0xB2 (=0xA0 | 0x12)
Repeated start
Adresse 0x29 Read
Data read (dann kommt dann die ID)
Stop

Oliver