MSP430F169 - I2C - ACK

> 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

Der Master ist bei dir der MSP? Was für ein Baustein ist dein Slave?

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.