I2C Debugging

[Joh A. (jojoho)]

Hi zusammen!

Bin grad dabei eine I2C Verbindung näher zu untersuchen. Konkret gehts 
dabei um die Verbindung von einem Atmega644P zu einem FTDI FT201X Chip.

Die Verbindung funktioniert in sofern, dass Daten von dem 
Microcontroller an den FTDI Chip gesendet werden können, und dann per 
VCP am Computer empfangen werden können.

Was nicht funktioniert, ist die Abfrage an den Chip, wieviele Bytes im 
RX Buffer zu lesen bereit sind.

FTDI nutzt dafür die I2C Adresse 0x00 (Gereneral-Call) gefolgt von einem 
bestimmten Command.

Laut Application Note (s. 25):
http://www.ftdichip.com/Support/Documents/AppNotes/AN_255_USB%20to%20I2C%20Example%20using%20the%20FT232H%20and%20FT201X%20devices.pdf

Ensure the lines are Idle and then set the start condition
- Send the General Call Address (since a command to the FT201X will follow)
- Send the Data Available command
- Repeated Start - Ensure the lines are Idle and then set the start condition
- Send the device address 0x22 with read (R/W = 1)
- Read one byte from the FT201X and NAK this byte.

Was macht das für einen Sinn? Warum der General Call, was ist, wenn auf 
dem Bus noch andere Geräte hängen, die unter dem Command 0x0C dann etwas 
anderes verstehen?

Mit dem Development-Breakout Board für den FTDI funktioniert die 
komplette Kommunikation perfekt, auf dem eigenen Board bleibt der Atmgea 
beim Bytes Available checken beim "Read one byte from the FT201X and NAK 
this byte." hängen.

Also hab ich mal das Oszi angeschmissen und folgende Phänomene entdeckt 
(s. Bild). Takt Gelb, Data Blau. Was sind die kleinen Spikes da? Acks? 
Störungen? Ich dachte die müssen auch solange wie ein Takt sein? Der 
Takt sieht auch nicht regelmäßig aus, sondern ist manchmal zwei Takte 
lang?

Interessant ist dabei, dass diese auch nicht ganz den High-Level 
erreichen, und mit kleiner werdendem Pullup höher werden --> d.h. sie 
entstehen durch den Pullup am Bus (Daher eher keine äusseren störungen?)

Jemand irgendwelche Ideen zu dem ganzen?

Vielen Dank und Viele Grüße!
Johannes

[Mobilist (Gast)]

Vorab:
Was meinst du, wofür das DSO eine *HARDCOPY*-Taste hat?

Sicher nicht nur, aber auch, um das Forum hier vor rauschigen 3MB Photos 
zu bewahren.

Johannes H. schrieb:
> Was sind die kleinen Spikes da? Acks?

Über leg mal, wie I2C funktioniert. Wenn der Master seine Daten gesendet 
hat, gibt er SDA frei und je nach dem, wie schnell der Slave sein ACK 
schickt, zieht der Pull-Up zwischendurch die Leitung hoch.

[Klaus (Gast)]

Joh Annes schrieb:
> Mit dem Development-Breakout Board für den FTDI funktioniert die
> komplette Kommunikation perfekt, auf dem eigenen Board bleibt der Atmgea
> beim Bytes Available checken beim "Read one byte from the FT201X and NAK
> this byte." hängen.

Glaub ich nicht. Beim "Read with NAK" gibt der Master den kompletten 
Zyklus vor, wenn der Code nicht kaputt ist, darf er da nicht hängen.

Joh Annes schrieb:
> - Send the device address 0x22 with read (R/W = 1)

Wird das vom FTDI mit ACK quitiert?

MfG Klaus