Hallo an alle Das Thema ist nicht neues, jedoch konnte ich nichts konkretes zu finden. Folgendes: Ich möchte mein PIC16F als I2C Slave betreiben. Orientiert habe ich mich an folgender Seite/code: http://www.stefan-buchgeher.info/elektronik/i2c_pic_slave/i2c_slave_pic_kap5.html Erstens was ich nicht verstehe: nirgends im Code(auch im weiten wwww) sehe ich kein Slave der ein ACK bzw. NACK sendet?! Wie kommts? Der Slave muss doch als Bestätigung für den Master ein ACK/NACK Senden. Übertragung funktioniert nicht. Es werden nur paar Taktzeilen gesendet und dann hört es auf bzw bleibt der Bus auf Low.. Die Codebeispiele online sehen alle ähnlich aus, nie ohne setzen von ACks. Aber keins davon funktioniert. Entsprechende TRIS/ANSEL und PPS sind richtig gesetzt. (Als Master funktioniert alles richtig) lG
derneue schrieb: > Der Slave > muss doch als Bestätigung für den Master ein ACK/NACK Senden. M.w. nein, es gibt kein Ack/Nack. Wenn der der Slave zu langsam ist s. I2C clock stretching.
Hallo, Welcher PIC ist es denn genau? Wenn du nur PIC16F schreibst, denke ich an so alte Gurken wie PIC16F684 oder ähnliche... Das entsprechende Datenblatt deines PICs enthält sicherlich eine genaue Registerbeschreibung - ich setze ebenfalls I2C auf vielen PIC ein, habe keine Probleme damit. Wenn man dir also wirklich weiterhelfen soll, zeige mal deinen Code usw. Viele Grüße, Michael
Angehängte Dateien:
Wie kommt man auf die Idee, eine Seite so zu designen? Man kann das nichtmal in die Zwischenablage kopieren. Das geht ja gar nicht! > Die Codebeispiele online sehen alle ähnlich aus, nie > ohne setzen von ACks. Aber keins davon funktioniert. Offenbar ist im Register SSPCON2 das Bit 4 (ACKEN) immer 1.
Toby P. schrieb: > M.w. nein, es gibt kein Ack/Nack. Wie soll I2C ohne funktionieren?? Hast du selbst schon einmal mit der I2C-Einheit eines PIC gearbeitet? Siehe beispielsweise Seite 260: http://ww1.microchip.com/downloads/en/devicedoc/41440a.pdf
Michael schrieb: > Toby P. schrieb: >> M.w. nein, es gibt kein Ack/Nack. > > Wie soll I2C ohne funktionieren?? > > Hast du selbst schon einmal mit der I2C-Einheit eines PIC gearbeitet? Was die I²C-Einheit eines PIC macht, ist zwar schön und gut, aber entscheindend ist, was die I²C-Bus Spezifikation sagt. Und da steht im Abschnitt 7.2 Acknowledge (S.10): "... Usually, a receiver which has been addressed is obliged to generate an acknowledge after each byte has been received". Dem ist nichts hinzu zu fügen. http://i2c2p.twibright.com/spec/i2c.pdf
Wolfgang schrieb: > Was die I²C-Einheit eines PIC macht, ist zwar schön und gut, aber > entscheindend ist, was die I²C-Bus Spezifikation sagt. Wo siehst du da eine Diskrepanz? "Toby P. (Gast)" hat geschrieben, dass der PIC keine ACK erzeugen würde. Das stimmt nicht, wenn du ACK haben willst, setze einfach die entsprechenden Bits korrekt und der PIC beantwortet dir jedes Byte mit einem ACK. Das ist alles im Datenblatt beschrieben, inwiefern soll dem Fragesteller der Hinweis auf die I2C-Spezifikation hier weiterhelfen? Wenn man erfährt, um welchen PIC es genau geht, kann man problemlos im betreffenden Datenblatt nachsehen, ich habe nur ein zufälliges ausgewählt, um zu zeigen, dass es hier keine fehlende Funktionalität gibt.
Michael schrieb: > Wo siehst du da eine Diskrepanz? Nirgends. Für den I²C-Bus ist aber die Spezifikation der Maßstab der Dinge und nicht eine Implementation auf irgendeinem Chip ...
Wolfgang schrieb: > Nirgends. Für den I²C-Bus ist aber die Spezifikation der Maßstab der > Dinge und nicht eine Implementation auf irgendeinem Chip ... Schon klar, aber die Frage hier dreht sich alleine darum, wie man mit der vorhandenen Implementation das korrekte Verhalten erzielt. Hierfür ist einzig das Datenblatt des Controllers relevant. Wenn man weiß, welcher konkrete PIC es ist, kann man ganz knapp sagen: Setze diese Bits so und so, fertig...
Michael schrieb: > Schon klar, aber die Frage hier dreht sich alleine darum, ... Es ging um die Richtigstellung, dass es sehr wohl ein Ack gibt und der Slave dieses lt. I²C Spezifikation schicken muss. Toby P. schrieb: > derneue schrieb: >> Der Slave >> muss doch als Bestätigung für den Master ein ACK/NACK Senden. > M.w. nein, es gibt kein Ack/Nack.
Lies mal das, was Microchip selber zu dem Thema schreibt. http://ww1.microchip.com/downloads/en/appnotes/00000734c.pdf https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en011798 Das Zeug funktioniert, das habe ich als Basis für meinen Code genommen. fchk
Michael schrieb: > Toby P. schrieb: >> M.w. nein, es gibt kein Ack/Nack. > Wie soll I2C ohne funktionieren?? > Hast du selbst schon einmal mit der I2C-Einheit eines PIC gearbeitet? Ja habe ich, sogar sehr ausführlich als komplette Steuerung mit I2C Bussystem. Das schütz aber wohl nicht gegen falsche Erinnerung. Sorry für die Konfusion.
Danke an alle! Ich habe mir eben die Application Note von Microchip durchgelesen, und da wird genau nur einmal erwähnt dass die Hardware den Ack generiert.. (http://ww1.microchip.com/downloads/en/appnotes/00000734c.pdf) seite 5, schritt 4 Benutzt wird ein PIC16F15-354 Code sieht folgendermaßen aus:
1 | |
2 | if(PIR3bits.SSP1IF){ |
3 | PIR3bits.SSP1IF=0; |
4 | |
5 | //Master sendet Schreibbefehl, Slave muss lesen
|
6 | if (!SSP1STATbits.R_W) { |
7 | //adress match
|
8 | |
9 | // Adresse
|
10 | if (!SSP1STATbits.D_A) { |
11 | dummy=SSP1BUF; //read, 6) |
12 | SSP1STATbits.BF=0; |
13 | SSP1CON1bits.CKP=1; |
14 | PIR3bits.SSP1IF=0; |
15 | return; |
16 | }
|
17 | // Daten
|
18 | else if (SSP1STATbits.D_A) { |
19 | message=SSP1BUF; |
20 | SSP1CON1bits.CKP=1; |
21 | PIR3bits.SSP1IF=0; |
22 | return; |
23 | }
|
24 | } else if (SSP1STATbits.R_W) { |
25 | // wird nicht benötigt.
|
26 | }
|
27 | }
|
derneue schrieb: > da wird genau nur einmal erwähnt dass die Hardware den Ack generiert Das ist beides normal, dass der Hersteller solche Dinge nur einmal hinschreibt und dass die Hardware es selbst macht. Ich habe nicht umsonst schon ziemlich früh dies geantwortet: > Offenbar ist im Register SSPCON2 das Bit 4 (ACKEN) immer 1. Zusammen mit einem Screenshot von der scheußlichen Webseite, wo dieses Bit knapp beschrieben ist.
Problem besteht immer noch. Sogar der Code von Microchip läuft nicht. AUßer ein paar Random Takte kommt da nichts.
Hat dein I²C Bus Pull-Up Widerstände? Wie sehen die Signale auf dem Oszilloskop aus?
derneue schrieb: > Sogar der Code von Microchip läuft nicht. Damit weiß man doch schon das der Fehler bei dir liegt. Bilder vom Schaltplan wären nicht verkehrt.
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.