Sinnhaftigkeit: i2c mit crc absichern ?

Sicher, daß kein Programmier- / Timingfehler voliegt? Wenn Dir CRC 
hilft, Fehler zu erkennen, dann kannst Du´s ja ruhig mit einbauen. 
Besser ist jedoch, Fehler zu vermeiden. 30cm Kabel auf I2C sind 
keinesfalls schon zu viel.

Najaa - ein bisserl genauer drüberschauen hat ja noch nicht geschadet. 
Ich denke nicht, daß es unbedingt an mistigem Layout liegt, oder? 
Nötigenfalls kannst Du ja mal die beiden PullUps am Bus von 10k auf 4k7 
verkleinern und gucken, ob es besser wird.

Und was meinst Du mit verdrillte Litze, welche Litzen sind miteinander 
verdrillt ?
Ein Flachbandkabel mit Gnd zwischen SDA und SCL hat bei 30cm keine 
Probleme, auch bei 400kHz.

30 cm ist nicht zuviel. Elektrisch stimmt alles? Pull-ups vorhanden und 
korrekt dimensioniert (http://www.mcc-us.com/i2cHowToUseIt1995.pdf)?

Tröste dich: Ein Oszi ist nicht das ultimative Tool zum I2C-debuggen 
(auf was willst du triggern und wie lang sind deine I2C Telegramme...). 
Besser wäre ein Logikanalyzer mit I2C Protokollhandling. Und das ist 
nicht mehr preiswert.

Tipp: In der Artikelsammlung zu I2C ist ein Link zu Cheapi2c. Das 
ist ein brauchbarer I2C-Sniffer, der Linux (irgendeine LiveCD reicht) 
und eine parallele Schnittstelle braucht. Zu den 30 cm: Beim Sniffen 
habe ich mit Cheapi2c den Datenverkehr zwischen einem µP und einem EPROM 
mitgeschnitten - mit einem 2m Druckerkabel zum Sniffer-PC.

Also zumindest die AppNote für I2C von Atmel in Assembler hatte Fehler! 
Einfach so sollte man die nicht als korrekt ansehen.

Gruß
Fabian

Ich betreibe hier I2C mit 33kHz auf 3m Telefonleitung in LKWs und 
Traktoren.
Das macht Spaß !
Ich habe jetzt auch eine CRC-16 eingeführt - Fehler sehe ich trotzdem, 
die sind aber nicht ganz so schlimm bei mir (reine Anzeige).

Bei 30cm sehe ich keine Chance für elektronische Fehler!
Die Pull-Ups kannst Du auf 2,2k ändern, aber das wird nicht wirklich 
viel bringen.
Hast Du evtl. einen Bug in der Software ?

Ich nutze den Po.Scope als Logicanalysator und I2C-Analyzer zum 
Debuggen. Ist schon nicht schlecht und sehr preiswert.

Das ist schade. Auf der Seite waren ein paar interessante Sachen auch 
ausserhalb XBox-Hacking drauf. Aber ich verstehe auch den Autor.

Hallo Stefb,


und Du bist ganz sicher, daß Du jetzt keinen Joint in der Hand hast ?
Wie erklärt sich sonst Dein Posting ?

Vielleicht einfach mal die Gegenprobe machen:
- Frequenz so weit senken wie's geht
- Leitung so weit kürzen wie's geht
Wenn dann die Fehler weniger werden hat die Schaltung zumindest eine 
Teilschuld. Bei so seltenen Fehlern ist vielleicht auch die andere 
Richtung interessant. Einfach mal die I²C-Frequenz erhöhen und schauen, 
ob dann nur noch Datenbrei ankommt.

Kann es sein, dass du dir von den Platinen hochfrequente Störungen 
einfängst? Ist ohne Oszi aber echt doof :(

Ach ja... rüttel mal ander ganzen Apparatur während des Tests... wenn 
das was am Fehlerbild ändert weißt du ja, wo du suchen musst ;) Denke 
nicht, dass das was bringt, kostet aber nur eine Minute und spart im 
Erstfall mehrere Stunden.

Gruß

Kai

Bernd Rüter wrote:
> Hallo Stefb,
> und Du bist ganz sicher, daß Du jetzt keinen Joint in der Hand hast ?
> Wie erklärt sich sonst Dein Posting ?

Rauchen tue ich nicht. Aber sind von Wasabi Coated Green Peas solche 
Nebeneffekte bekannt? Von denen habe ich eine halbe Dose intus.

Und auch mal ohne verdrillen probieren, denn SCL könnte SDA 
beeinflussen, und schon kommt ein andres Bit raus.

@ Tiny 80 (linux_80)

>Und auch mal ohne verdrillen probieren, denn SCL könnte SDA
>beeinflussen, und schon kommt ein andres Bit raus.

Wen der Slave halbwegs I2C konform ist, dann muss er Pulse kleiner als 
50ns ignorieren. Ich tippe mal auf Masseprobleme, unsaubere 
Versorgungsspanung oder last but not least einen Programmfehler. GGf. 
auch Störpulse von starken geschalteten Lasten, Relais, Motoren etc.

MFG
Falk