Pic I2C Slave

Gast #6060865
Lesenswert?

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
Gast #6060891
Lesenswert?

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
Gast #6060914
Lesenswert?

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
Gast #6060921
Lesenswert?

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.
Gast #6060959
Lesenswert?

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...
Gast #6061086
Lesenswert?

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.
Gast #6061097
Lesenswert?

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
    }
Gast #6061779
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren