I²C Übertragungsfehler?

[Jan H. (heine)]

Hallo,

ich habe eine Platine, bei der zwei PICs miteinander über I²C 
kommunizieren. Bisher waren das ein PIC16F876 und ein PIC16F818. Nun 
habe ich aber die Platine (wegen enormer Auslastung des 876er PICs) auf 
einen PIC18F erweitert und die Programmierung angepasst.

Seitdem treten bei der Übertragung über die I²C-Schnittstelle immer 
wieder Übertragungsfehler (?) auf und die ganze Schaltung landet im 
Watchdog.
Nun zu meiner Frage, sind es wirklich Übertragungsfehler (ausgelöst 
durch Relais oder Ähnliches) oder woran kann es noch liegen? Ich habe 
das Ganze mal mit dem Oszi aufgenommen und einen Screenshot gemacht (Im 
Anhang). Der erste schmale Peak im Bild gehört da meines Wissens nach 
eigentlich nicht hin. Beim 16er PIC ist Dieser nie aufgetreten. Reicht 
dieser kurze Peak bereits aus (Dieser tritt übrigens häufiger auf) um 
meine Übertragung zu behindern oder benötigen die Sendeimpulse eine 
gewisse Impulsbreite?

MfG
Jan Heynlein

[Xor (Gast)]

Schema ? Hast ne Groundplane ? Blockkondensatoren ?

[Olaf (Gast)]

> Reicht
> dieser kurze Peak bereits aus (Dieser tritt übrigens häufiger auf) um
> meine Übertragung zu behindern oder benötigen die Sendeimpulse eine
> gewisse Impulsbreite?

Zum Glueck musste ich nie mit PICs rummachen, aber wenn das SPI bei dir
in Hardware vorhanden ist dann sollte ein zu kurzer Clock unmoeglich 
sein,
weil die Hardware ihn garnicht erzeugen kann.
Dann waere es also mit Sicherheit eine Stoerung von ausserhalb, also
aus deiner restlichen Schaltung.

Eventuell koennte ich mir noch vorstellen das ein Programmierfehler
vorliegt, du also den Port in einer anderen Programmstelle fehlerhaft
als I/O benutzt.

Machst du SPI in Software wuerde ich mal verstaerkt drueber nachdenken
was du alles im IRQ laufen hast.

Und natuerlich ist sowas auf der Clockleitung absolut stoerend und darf 
nicht sein!

Olaf

[Benedikt K. (benedikt)]

Jan Heynlein wrote:
> Nun zu meiner Frage, sind es wirklich Übertragungsfehler (ausgelöst
> durch Relais oder Ähnliches) oder woran kann es noch liegen?

Eher nicht. Abgesehen davon, dass er etwas schmaler als die anderen 
Impulse ist, sieht er dennoch genauso aus. Außerdem ist er positiv. 
Normalerweise sollte der Master die Leitung nach GND kurzschließen. Man 
bräuchte also schon ordentlich Strom um die Leitung dennoch auf 5V zu 
bekommen. Für einen Spike ist er viel zu breit. Zu >99% ist es ein 
Softwarefehler.

[Bernd R. (Firma: Promaxx.net) (bigwumpus)]

Mit welcher Programmiersprache arbeitest Du ?

Das TRIS-Register für den betreffenden Port wird während der Übertragung 
nicht angerührt ?!?!

[BL (Gast)]

Hallo,


ich mach' an Jan's Problem weiter.
Folgendes zur Präzisierung:
In dem dargestellten Oszillogramm ist links der Mitte eine Spitze zu 
sehen. Das ist komischerweise der erste Takt auf der SCL-Leitung. Master 
ist ein 18F2685, Slave ein 16F818. Programmiersprache C, Compiler CC8x.

Früher war statt 18F2685 ein 16F876A(pinkompatibel) eingesetzt. Die 
Kommunikation klappte da recht ordentlich. Der Code wurde eins zu eins 
übernommen.

Dadurch, dass das erste Takt-Bit so kurz ist, reagiert der 818 nicht 
immer. Manchmal schon, zu oft aber klappt's nicht. Ein am gleichen Bus 
operierender PCF8583(Uhrenbaustein) ist da unempfindlicher.

Die eigentliche Fehler-Ursache ist aber ganz offensichtlich die Kürze 
dieses ersten Bits.
Während des Sendenvorganges macht der Master nicts anderes, weshalb das 
TRIS-Bit nicht umgestellt wird. Auch in den ganzen 9K des weiteren 
Programmes wird nichts an den TRIS-Bits gemacht.


Hat da nicht jemand eine Idee, wo man suchen kann?


BL