Hallo zusammen, Leider habe ich keinen passenden Beitrag zu meinem Problem gefunden. Ich habe vor, zu Testzwecken und zum Ausprobieren, zwei PIC18F27Q83 miteinander über I2C kommunizieren lassen. Dazu soll der Host 4 Bytes (4 Übertragungen) vom Clienten empfangen. Das Ganze soll sich ca. alle 10ms wiederholen (Unterprogramm „I2CUebertragung“ wird aufgerufen). Das Problem, nach dem ersten erfolgreichen Durchgang wird nur noch das Adressebyte des Hosts im zweiten Durchgang gesendet und das wars. Wenn ich die Übertragung genauer mit dem Oszilloskop analysiere, stelle ich fest, dass beim neunten Takt des SCL die Datenleitung SDA hart auf 1 bleibt und vom Host gehalten wird, obwohl dieser ja eigentlich auf das Acknowledge-Singal vom Clienten warten soll (ich hoffe es wird durch die Anhänge verständlicher). Auch wenn ich den Adressbuffer deaktiviere (ADB = 0) und das Adressbyte in I2C1TXB schreibe, bleibt das neunte Bit auf 1. Wenn ich die entsprechenden Bits vom Clienten überprüfe, stelle ich fest, das dieser beim zweiten Versuch auf jeden Fall das Startsignal (SCIF = 1) sowie die Adressierung (ADRIF = 1) erkennt und das Acknowledge-Bit senden will (ACKDT = 0). Nur, er kann es nicht senden, der Host ist, warum auch immer, dagegen. Hat vielleicht irgend jemand eine Idee, warum der Host das Acknowlegde-Singal „blockiert“? Und warum funktioniert das beim ersten Durchgang und dann nicht mehr? Muss ich vielleicht noch irgendwas zurück setzen, was ich übersehen habe? Die Übertragung in die andere Richtung (Host sendet Bytes) funktioniert einwandfrei. Vielen Dank für eure Hilfe. Grüße Philip
Angehängte Dateien:
-
Zweiter_Durchgang.png
35 KB -
Erster_Durchgang.png
37 KB
Philip schrieb: > stelle ich fest, dass beim neunten Takt des SCL die Datenleitung SDA > hart auf 1 bleibt und vom Host gehalten wird Mit welcher Messung begründest Du diese Annahme?
Peter D. schrieb: > Was ist rtf, ich kann nur C. Vielen Dank für die Antwort. rtf ist ein Textformat, welches mein Mac standardmäßig verwendet. Ich wollte nur die relevanten Programmzeilen kopieren. Es sollte aber auch von Windows-Computern geöffnet werden können. Grüße Philip
Hmmm schrieb: > Philip schrieb: >> stelle ich fest, dass beim neunten Takt des SCL die Datenleitung SDA >> hart auf 1 bleibt und vom Host gehalten wird > > Mit welcher Messung begründest Du diese Annahme? Vielen Dank für die Antwort. Einmal begründe ich diese Annahme mit den angehängten Oszilloskopauswertungen, zudem habe ich die Messung auch mit einem Widerstand zwischen Host und Client auf der Datenleitung durchgeführt. Dabei konnte ich die Signale an den Ports der jeweiligen Pics vergleichen und somit feststellen, woher die Spannung (das Signal) kommt. Grüße Philip
Ein I2C-Sender oder Empfänger kann eine I2C Leitung niemals auf 1 blockieren, da die Leitungen Open-Collector sind. Dein Empfänger reagiert nicht. Ganz einfach.
Ali K. schrieb: > Ein I2C-Sender oder Empfänger kann eine I2C Leitung niemals auf 1 > blockieren, da die Leitungen Open-Collector sind. > > Dein Empfänger reagiert nicht. > Ganz einfach. Vielen Dank für die Antwort, stimmt, das klingt logisch. Aber warum reagiert dann der Client nicht, obwohl er das ADRIF und das ACKDT entsprechend richtig setzt? Das widerspricht sich ja eigentlich. Vor allem, weil ja auch der erste Durchgang funktioniert. Beide Pics sind, bis auf den Modus, gleich konfiguriert Grüße Philip
Philip schrieb: > Wenn ich die Übertragung genauer mit dem Oszilloskop analysiere, stelle ich > fest, dass beim neunten Takt des SCL die Datenleitung SDA hart auf 1 > bleibt und vom Host gehalten wird ... Das kann und darf nicht sein. Bei I2C ist der High-Pegel sowohl auf SDA als auch auf SCL rezessiv und wird durch Pull-Up Widerstände erzeugt. Wenn dein Host die Leitung auf 1 zieht, ist der GPIO grundlegend falsch konfiguriert.
:
Bearbeitet durch User
Angehängte Dateien:
Philip schrieb: > rtf ist ein Textformat, welches mein Mac standardmäßig verwendet. Ich > wollte nur die relevanten Programmzeilen kopieren. > Es sollte aber auch von Windows-Computern geöffnet werden können. So sieht deine Datei beim Öffnen auf meinem Samsung aus. LG, Sebastian
Philip schrieb: > rtf ist ein Textformat, Warum lädst du C-Quellcode als Datei im RTF hoch und nicht als C-Datei? Das verwirrt jeden Viewer. Jeder C-Compiler wird sich weigern.
:
Bearbeitet durch User
Philip schrieb: > rtf ist ein Textformat, welches mein Mac standardmäßig verwendet. Auch das Apple-Zeug kennt normale Textdateien. Die werden dann auch nicht im Office-Paket in 20pt-Blindenschrift geöffnet. Ich sehe darin auch keinen Source Code, nur zusammenhanglos zusammenkopierte Schnipsel. Philip schrieb: > Aber warum reagiert dann der Client nicht, obwohl er das ADRIF und das > ACKDT entsprechend richtig setzt? Das widerspricht sich ja eigentlich. > Vor allem, weil ja auch der erste Durchgang funktioniert. Hilfreich wäre mal eine Logic-Analyzer-Aufzeichnung der gesamten I2C-Kommunikation. Schickt der Host nach dem letzten empfangenen Byte standardkonform ein NACK?
Sebastian W. schrieb: > Philip schrieb: >> rtf ist ein Textformat, welches mein Mac standardmäßig verwendet. Ich >> wollte nur die relevanten Programmzeilen kopieren. >> Es sollte aber auch von Windows-Computern geöffnet werden können. > > So sieht deine Datei beim Öffnen auf meinem Samsung aus. > > LG, Sebastian Oke, danke für die Info. Ich habe die Dateien jetzt nochmal als .doc erstellt. Ein .txt Format wird leider zu sehr verzogen. Ich hoffe das klappt jetzt. Grüße Philip
Warum hängst du nicht einfach die .c Dateien an? Programmierst du in Word?
Rainer W. schrieb: > > Warum lädst du C-Quellcode als Datei im RTF hoch und nicht als C-Datei? > Das verwirrt jeden Viewer. Jeder C-Compiler wird sich weigern. Hallo Rainer, tut mir Leid, ich dachte die .rtf-Dateien kann jeder lesen. Leider besteht der Code nicht nur aus der I2C-Übertragung, sondern auch noch aus vielen anderen Unterprogrammen. Es wäre zu viel gewesen, die komplette C-Datei hoch zu laden. Oder gibt es eine Möglichkeit, ein Teil eines C-Codes zu exportieren? Grüße Philip
> Auch das Apple-Zeug kennt normale Textdateien. Die werden dann auch > nicht im Office-Paket in 20pt-Blindenschrift geöffnet. > > Ich sehe darin auch keinen Source Code, nur zusammenhanglos > zusammenkopierte Schnipsel. > Danke für die Antwort, Sorry, ich dachte die rtf-Dateien kann jeder öffnen. Im Anhang nochmal die Dateien als Dokument (ich hoffe das geht). Die Textdatei wird leider zu sehr "verzogen". Die komplette C-Datei beinhaltet leider zu viel Programmcode, was nichts mit I2C zu tun hat, deshalb die Ausschnitte. > Philip schrieb: >> Aber warum reagiert dann der Client nicht, obwohl er das ADRIF und das >> ACKDT entsprechend richtig setzt? Das widerspricht sich ja eigentlich. >> Vor allem, weil ja auch der erste Durchgang funktioniert. > > Hilfreich wäre mal eine Logic-Analyzer-Aufzeichnung der gesamten > I2C-Kommunikation. > > Schickt der Host nach dem letzten empfangenen Byte standardkonform ein > NACK? Einen Logic-Analyzer hat mein Oszilloskop leider nicht. Ja, ein NACK wird beim ersten Durchlauf nach dem letzten empfangenen Byte vom Host gesendet, ebenso eine Stopproutine. Danke für die Antwort. Grüße Philip
Philip schrieb: > Im Anhang nochmal die Dateien als Dokument (ich hoffe das geht). Die > Textdatei wird leider zu sehr "verzogen". Die komplette C-Datei > beinhaltet leider zu viel Programmcode, was nichts mit I2C zu tun hat, > deshalb die Ausschnitte. Das im Anhang sind Dateien von Apple iWork im .pages Format wie die Dateiendung sagt. Die können hier nur die Apple-Nutzer öffnen wenn sie eben Pages aus iWork installiert haben. Mach dich eine neue c Datei und kopiere da nur das rein was du hier mitteilen willst. Und dann lädst du hier eben diese c Datei hoch. Kein .doc, kein .pages, kein .rtf, kein .txt nur eine .c datei die den Code enthält. Das alles kannst du wunderbar im Finder oder noch besser mit dem Terminal das es auf jedem Mac gibt erledigen. Der Texteditor auf dem Mac, also was was bei Windows Notepad ist, heißt TextEdit. Der kann .c öffnen und der kann auch plaintext.
:
Bearbeitet durch User
> Das im Anhang sind Dateien von Apple iWork im .pages Format wie die > Dateiendung sagt. Die können hier nur die Apple-Nutzer öffnen wenn sie > eben Pages aus iWork installiert haben. > > Mach dich eine neue c Datei und kopiere da nur das rein was du hier > mitteilen willst. Und dann lädst du hier eben diese c Datei hoch. Kein > .doc, kein .pages, kein .rtf, kein .txt nur eine .c datei die den Code > enthält. Das alles kannst du wunderbar im Finder oder noch besser mit > dem Terminal das es auf jedem Mac gibt erledigen. > > Der Texteditor auf dem Mac, also was was bei Windows Notepad ist, heißt > TextEdit. Der kann .c öffnen und der kann auch plaintext. Oke sorry, ich habe jetzt den relevanten Programmcode, wie du vorgeschlagen hast, in eine Extra neu erstellte C-Datei eingefügt. Ich hoffe das klappt jetzt mal. Danke Grüße Philip
Du pollst die Interrupt-Flags (statt mit Interrupts zu arbeiten), aber clearst sie nie?
Hmmm schrieb: > Du pollst die Interrupt-Flags (statt mit Interrupts zu arbeiten), aber > clearst sie nie? Ja, tatsächlich bin ich nicht der Fan von interrupts. Habe diese nun mit I2C1PIR = 0 gelöscht, der Fehler ist immer noch vorhanden. Grüße Philip
Philip schrieb: > Habe diese nun mit I2C1PIR = 0 gelöscht Mir fehlt die Erfahrung mit PICs, das scheint aber nicht auszureichen, um alle I2C-Interrupt-Flags zu clearen: https://onlinedocs.microchip.com/pr/GUID-CA6B1F8F-E09D-4780-A52A-CBBF61902464-en-US-2/GUID-5968B4BD-0262-48DA-81B6-174488D5B92F.html
> > Mir fehlt die Erfahrung mit PICs, das scheint aber nicht auszureichen, > um alle I2C-Interrupt-Flags zu clearen: > > https://onlinedocs.microchip.com/pr/GUID-CA6B1F8F-E09D-4780-A52A-CBBF61902464-en-US-2/GUID-5968B4BD-0262-48DA-81B6-174488D5B92F.html Vielen Dank für die Antwort. Ich habe nun alle Register zurückgesetzt, wie in Initialisierung im Link. Wobei ich nicht ganz verstehe, warum das PIR-Register gelöscht wird, da es sich um only read bits handelt. Leider brachte dies auch keinen Erfolg. Zudem habe ich inzwischen festgestellt, dass das SMA-Bit (Client aktiv) nicht gesetzt wird, es liegt also definitiv am Clienten, der beim zweiten Durchgang nicht mehr auf die Adresse antwortet. Grüße Philip
Philip schrieb: > rtf ist ein Textformat, welches mein Mac standardmäßig verwendet. Ich > wollte nur die relevanten Programmzeilen kopieren. > Es sollte aber auch von Windows-Computern geöffnet werden können. Das geht in Windows mit Wordpad, das ist eine Textverarbeitung, oder mit einem anderen Textverarbeitungsprogramm. Wordpad ist EOL, soll angeblich bei einem der Updates sogar verschwinden. Und es gibt Leute, die lesen hier mit einem "Wischkästla", die schauen durch die Röhre. Auch Linux braucht dafür eine Textverarbeitung Bitte verwende künftig hier das TXT-Format, das kann wirklich jeder.
Ich verzweifle langsam und hänge schon seit Wochen an den Problem 😩. Egal was ich mache, zurücksetze, einstelle und ausprobiere, der blöde Client will im Transmission-Mode einfach kein zweites mal die Adresse erkennen. Hat denn sonst niemand eine Idee? Im Anhang nochmal der relevante Code als C-Datei. Bin für jede Hilfe dankbar. Grüße Philip
Angehängte Dateien:
-
Unbenannt.PNG
51 KB
Ich sehe nirgends wo du nach einem Empfang ein NACK sendest. Du musst schon einstellen, ob du ein NACK oder ACK senden willst. Das passiert nicht automatisch.
Ali K. schrieb: > Ich sehe nirgends wo du nach einem Empfang ein NACK sendest. > Du musst schon einstellen, ob du ein NACK oder ACK senden willst. Das > passiert nicht automatisch. Vielen Dank für die Info. Die Einstellungen für ACK und NACK haben tatsächlich noch gefehlt. Leider löste die Ergänzung das Problem auch nicht. Allerdings habe ich inzwischen festgestellt, dass ein zurücksetzen des TXU bist (Transmission unterflow) dazu führt, dass der Client die Adresse erkennt. Es wird also irgendwo ein underflow ausgelöst, obwohl, laut Oszi, die gesendeten Bytes überall korrekt vorhanden sind. Zudem beendet nur der Host im zweiten Durchgang nach einer Datenübertragung den Vorgang und beendet die Übertragung mit einem NACK. Das Problem wurde sozusagen zum Host verlagert. Grüße Philip
Thread beobachten
Seitenaufteilung abschaltenBitte 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.