Hallo zusammen, ich bekomme es einfach nicht hin meine beiden PIC18F4680 im Master-Slave Verbund zu betreiben!! Was funktioniert? - Master kann Daten an Slave senden, und Slave kann empfangen (das heißt, beide sind richtig initialisiert) Was funktioniert nicht? - Slave kann keine Daten an den Master senden - zumindest kommt nur die Adresse des Slaves um ein Bit nach links verschoben zurück! bzw. gar nichts Ich steig da nicht mehr durch. Habe auch schon probiert einen Temp.sensor DS1624 zu befragen (auszulesen) um sicher zu gehen ob ich nicht schon ganz irre bin ;) ... es hat auch funktioniert! Hat jemand schonmal einen funktionsfähigen Slave für I2C aufgesetzt und kann den C-Code hier posten?? Ich wäre demjenigen sehr dankbar!!!!!!
Was heisst Slave kann keine Daten an Master senden? Willst du vom dem Slave nur Daten abholen oder soll er als Master selber Daten zum anderen Master (der dann als Slave fungiert) senden ? (ich denke du meinst ersteres) Was von deinem Slave zurueck kommt haengt nur davon ab, was du deinem Slave befehlst zu senden, wenn er denn vom Master "gefragt" wird. Hier wirst du fuendig: Beitrag "TWI / I2C einf. MASTER SLAVE Beispiel(Assembler) ATmega8" (letzter Beitrag). Ob man das nun so wie dort macht oder mit Interrupts arbeitet ist im Prinzip gleich. Der Code sollte auch auf einem PIC ohne Probleme portierbar sein da der Ablauf gleich ist. Gibt es kein Datenblatt zu dem Pic ? Zumindestens beim Atmega steht alles bis aufs kleinste erklaert. ansonsten waere ggf gut wenn du deinen Code postest. gruss
Hallo, ich habe ein ganz ähnliches Problem (oder exakt dasselbe?). 2 PICs per I2C verbunden. Master=PIC18F2585, Slave=PIC18F4680. Den Datenverkehr protokolliere ich wegen der Fehlfunktion via CAN-Verbindung zu einem CAN-Monitor auf PC. Das funktioniert auch sehr gut. Kommunikation Master -> Slave Zur Anforderung von Daten sendet der Master zuerst ein Paket mit einem Steuercode (eigenes Protokoll: Startcode, Länge, Steuercode, CRC) zum Slave. Das funktioniert korrekt, beide PICs melden über den CAN-Bus den Inhalt den Sende- bzw. Empfangspuffers und beides ist korrekt. Daraufhin füllt der Slave den Sendepuffer mit den angeforderten Daten Kommunikation Slave -> Master Der Master liest die Daten vom Slave aus. Der Slave zeigt via CAN-Bus einen korrekt gefüllten Sendepuffer. Der Master zeigt jedoch als erstes Byte in seinem Empfangspuffer 0x0e (was die Slave-Adresse 0x07 << 1 wäre, wie von Philipp H. beschrieben). Erst danach kommt der erwartete Inhalt des Puffers. Testweise habe ich einen anderen Slave angeschlossen (ein TFT-Display von Electronics Assembly) und mit deren vorgefertigtem Protokoll gearbeitet. Da funktioniert alles wie erwartet. Demnach muss der Fehler im Slave liegen. Ich habe schon alles ausprobiert mit der Reihenfolge von SSPIF, Release Clock Line und BF (->SSPBUF) setzen/rücksetzen aber es ändert sich nichts! Kennt irgend jemand dieses Problem und womöglich eine Lösung? Vielen Dank schon mal Stephan
Der Slave und der Master müssen beide das Clock-Stretching unterstützen. Der Slave hält dazu SCL solange auf Low, bis er das zu sendende Byte in das Senderegister geschrieben hat. Und der Master wartet solange, bis er auf SCL High liest. Peter
Beide PICs unterstützen Clock Stretching. Der Slave ist so eingestellt, dass er auch bei Slave-Receive stretcht (bei Slave-Transmit ist das zwangsweise). Das benötige ich, da die CAN-Bus Kommunikation Vorrang hat. Wegen der Stretcherei gehe ich davon aus dass das Timing unkritisch wird. Daher habe ich auch versuchsweise die ganze I2C Kommunikation aus den Interrupt Service Routinen herausgenommen und arbeite sie in der Main Loop nach Polling von SSPIF ab. Stephan
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.