Hallo, ich habe ein Verständnisproblem. Bei der I2C-Kommunikation wird ein Byte ja mit einem ACK nach den 8-Datenbitsbits quittiert. Jetzt meine Frage: 1.) Wer generiert dieses ACK, ist es die Übertragungslogik im MSP430 oder muss dies durch meine Software passieren? 2.) Wie kann man softwareseitig das ACK abfragen? Hier im Forum habe ich schon ein schönes Beispiel für eine Software-I2C-Implementierung gefunden. Da ist die sequentielle Vorgehensweise gut erkennbar. Ich möchte aber die für I2C vorgesehenen Pins 3.1/3.3 und die interne Logik des MSP430 nutzen. Danke für eure Hilfe gruss master
> 1.) Wer generiert dieses ACK, ist es die Übertragungslogik im MSP430 > oder muss dies durch meine Software passieren? Das ACK generiert der Teilnehmer der Daten empfängt. Wenn das der MSP ist, muss der das natürlich auch machen. Für die MSP I2C Rountinen einfach mal einen blick in die Code Beispiele von Ti werfen: http://www-s.ti.com/sc/techzip/slac015.zip
Hallo , danke für den Hinweis mit den Quellcodebeispielen von TI. Ich habe das Beispiel mit den Master/Slave über I2C implementiert. Dabei ist jetzt folgendes Problem aufgetreten. Der Master initiiert die I2C-Kommunikation mit dem Slave und schiebt die Adresse über den Bus. Das funktioniert sauber(ist am Oszi zu sehen). Dann müßte doch eigentlich das ACK vom Slave kommen(generiert durch die MSP430-Hardware). Und genau das passiert NICHT. Die Clock-Leitung wird dauerhaft auf LOW gezogen. Trenne ich die Datenleitung vom Slave, geht die Clockleitung ganz normal wieder auf HIGH. Dies bedeutet aus meiner Sicht, dass der Slave die Clockleitung auf LOW zieht. Wenn ich richtig informiert bin, so will der Slave damit einen Fehler mitteilen. Aber ich verstehe nicht warum. Ich habe ja die Original-Quellfiles von TI für den Master und den Slave benutzt. Habt ihr eine Idee???? Danke gruss master
Hallo Jörg, Master ist ein MSP430F169. Als Slave habe ich das Olimex-EvaBoard mit einem MSP430F1611. Und wie bereits gesagt, die Quellsourcen sind die Originalfiles von TI. gruss master
Hallo ich hatte ein ähnliches Problem. Dies trat aber nur auf wenn man CCE2 statt IAR nutzt. Die Quellcodebeispiele sind nur für IAR für den F1611 jedenfalls. Man muß da dann das schreiben des Interruptvectors anpassen. Ein low ziehen der SCL-Leitung soll den Master ausbremsen. Sobald der Slave die empfangenen Pakete verarbeitet hat sollte SCL eigentlich wieder auf high gehen, damit der Slave die nächten Bytes empfangen kann.
Bitte 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.