Hallo Ich möchte einen PIC 16F818 als I2C Master verwenden um einen Temperatursensor TMP100 zu betreiben. Ich verwende den internen Oscilator mit 8Mhz. CCS 4.122 Testversion Mein Problem: Ich kann mit dem Oszilloskop nur eine Busgeschwindigkeit von ca. 70 kHz messen. Dabei sollten es im "slow" schon 100 kHz sein. Umstellen auf "fast" bringt keine Veränderung. Jemand eine Idee was ich falsch mache oder vergessen habe? Bin noch recht neu in diesem Gebiet und brauche nachdem ich zwei Tage mit Fehler- bzw Web-Suche verbracht habe eure Hilfe. Schon mal vielen Dank im Vorraus.
Hi! Ich kenne den µC nicht, daher kann ich zum Code nichts sagen. Aber: Wie groß sind dein Pullup Widerstände an SDA und SCL? Versuch mal in der main Daten zu übertragen, nicht nur start und stop.
Die Pulluos sind je 1,8k Auch das ansprechen des Buses hat keine Veränderung gebracht. Ohne Debugger werde ich da wohl nicht sehr weit kommen...
Also hier laufen Pics (16F690) mit über 1 Mhz (clocksignal) Benjamin K. schrieb: > Ich kann mit dem Oszilloskop nur eine Busgeschwindigkeit von ca. 70 kHz > messen Wieso messen? Die wird am Master eingestellt.
Ja genau, Mein 16F818 ist der Master (mit software i2c). Wenn ich dann meine SCL an der Busleitung messe, hat das ca. 70kHz. Also läuft folglich irgendwas nicht so, wie es soll.
Hast du ein Oszi? Kannst du mal Bilder von dem Signalverlauf zeigen? 1,8k und 15pf gibt ein tau von ca. 27ns. Das sind 37MHz. Das müsste also reichen. (Ich weiß, dass die Rechnung so nur sehr grob ist. Da das Ergebnis aber weit von den 100 kHz weg ist, kann man das vernachlässigen). Hast du noch Kondensatoren im parallel zu SCL oder SDA? Kommen keine Daten zurück oder gibt es erst gar keine Ausgabe? Gruß PP
Achso, die Ausgabe ist nur 70 kHz... Dann ist es wohl ein Softwarefehler. Muss in die Main nicht noch ein I2C Init? Mach mal nach dem Senden des Startbits, der Daten und des Stopbits jeweils ne Pause von 1ms. Gruß PP
Angehängte Dateien:
-
IMAG1017.jpg
800 KB -
IMAG1018.jpg
840 KB
Also über das init hab ich in der Hilfe nichts gefunden.
So sieht mein Main nun auch:
void main()
{
setup_adc_ports(NO_ANALOGS);
setup_oscillator(OSC_8MHZ);
int Temp;
while(true){
i2c_start();
delay_ms(1);
i2c_write(0b01001111);
delay_ms(1);
Temp = i2c_read();
delay_ms(1);
i2c_stop();
}
}
Das ergebnis ist wie folgt (Gemessen an SCL):
Einige rechteckige Pulse die sich auf dem Osziloskop überschneiden. Dann
eine Pause von ca 900µs dann wieder von Anfang
hi! Lass mal die Zeiteinstellung wie im zweiten Bild aber mach mal nur einen Singleshot.
Angehängte Dateien:
-
IMAG1019.jpg
820 KB
Hier der single-shot, hab die zeiteinstellung minimal verändert. Aber warum verändert sich denn SCL? Der takt müsste doch immer der gleiche sein, oder?
Benjamin K. schrieb: > Hier der single-shot, hab die zeiteinstellung minimal verändert. > > Aber warum verändert sich denn SCL? Der takt müsste doch immer der > gleiche sein, oder? Da hast du Recht. Außerdem müsste SCL in der Pause auf High bleiben. Sorry, da bin ich mit meinem Latein am Ende.
Kann Software I2C mehr als 70 kHz? Was spricht gegen Hardware I2C?
Der 16F818 kann mit nem Hardware I2C nicht als Master arbeiten.
Häh? bist Du dir sicher? Im Datenblatt steht ein sog. Firmeware Controlled Master Mode. Was mich eher stuzig macht, sind die Delays von je 1ms. Bist Du Dir sicher, das Du dir den Bus nicht selbst ausbremst? Schau mal, ob das nicht noch irgendwelche Delays sind. Und... wiso ist Dir denn die Busgeschwindigkeit so wichtig, wenn Du in Deinem SourceCode schon 3mal eine ms wartest???
Ups, sorry, hatte nicht gesehen, das Ihr das extra zum Testen eingefügt habt...
Firmeware Controlled Master Mode ist ja per software. Die delays hab ich auf rat von PP im Beitrag davor rein genommen. Sind im Original aus dem ersten Beitrag nicht drin. Im Grunde ist mir die Busgeschwindigkeit egal, nur den Slaves nicht.
Benjamin K. schrieb: > Firmeware Controlled Master Mode ist ja per software. 10.3.2 MASTER MODE OPERATION Master mode operation is supported in firmware using interrupt generation on the detection of the Start and Stop conditions. (PIC16F818/819 Data Sheet) Das bedeutet das du in der Software lediglich die Conditions abfangen mußt, den Rest steuert die SSP selsttätig. Mit anderen Worten: Das ganze zeitaufwendige bitgefiddle und geschiebe entfällt, lediglich ein paar Bus Statis muß die Software per Interrupt behandeln. Das muß du ja so der so wenn das näcshte Datentelegramm gesendet werden soll. Es ist halt ein wenig zeitkritisch, das entfällt bei ner vollen Master Implementierung.
in deinem h File steht doch ganz klar das das SOFTWARE !!! I2C ist und nicht Hardware. Lass die Compilerfunktionen von CCS weg, ddie taugen nix
Benjamin K. schrieb: > Hier der single-shot, hab die zeiteinstellung minimal verändert. > > Aber warum verändert sich denn SCL? Der takt müsste doch immer der > gleiche sein, oder? Das hängt vom Slave ab, z.B. bei clock stretching (s. I2C specs wobei der slave die SCL Leitung pullt). Clockdauer ist wenn ich das richtig sehe 5ms ~ 200kHz. Woher hast du die 70 khz?
iaoffline schrieb: > Clockdauer ist wenn ich das richtig > sehe 5ms ~ 200kHz. Woher hast du die 70 khz? Hat sich erledigt da nur high state. Clock stretching ist wohl auch ne falsche Fährte da dein I2C wohl für jeden Slave lahm genug ist das er nicht stretched. Sorry
ttl schrieb: > Lass die Compilerfunktionen von CCS weg, ddie taugen nix Könntest du mir denn erklären wie ich es besser machen kann?
Benjamin K. schrieb: > Könntest du mir denn erklären wie ich es besser machen kann? Back to the roots, Datgenblat lesen und verstehen und die Register selbst ansteuern. Wirkt wunder und das auch noch unabhängig von der verwendeten Sprache.
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.