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
> 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
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.
Mit welcher Programmiersprache arbeitest Du ? Das TRIS-Register für den betreffenden Port wird während der Übertragung nicht angerührt ?!?!
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.