Welches Kabel für TWI (I2C) verwenden? Hilfe bei TWI Routine

[Sauginius]

Hallo,

ich möchte mit einem LM75 die Öl- bzw. Wassertemperatur über TWI vom Auto messen.
Die Platine wird im Innenraum eingebaut und die Sensoren an der entsprechenden Stelle (ist ja klar).
Aber welche Leitung sollte ich dafür verwenden?
Der LM75 braucht:
-Ub
-Masse
-Data
-Clock
Ich denke mal das hier abgeschirmtes Kable nötig ist oder? Wie sieht es mit LIYCY (4x0,14mm²)aus oder geht auch Dünneres (0,08mm²)?

Danke

[Sauginius]

Hmm, keiner kann helfen :(

Aber wenn nicht bei der Hardware dann vielleicht bei der Software.
Im Datenblatt des ATmega16 auf Seite 183 steht doch die Routine für den TWI. Ich verstehe nur nicht so ganz wie das mit den Deffinitionen gemeint ist, z.B. MT_SLA_ACK, ERROR und MT_DATA_ACK? :-s

[Frank]

Mit I2C Kabeln im Autor haben sicher wenige Erfahrung, daher gab es keine Antwort. Normalerweise soll das Kabel ja nicht länger als 2m sein. Im normalen Betrieb reicht ein einfaches Flachkabel mit einer Masseleitung dazwischen, kurze Leitungen brauchen garkeine Abschirmung. Aber im Auto bei etwa slängerem Kabel würde ich dann doch ein Kabel mit Abschirmung nehmen. 0,08mm könnte vielleicht noch gehen. Ich würde es einfach mal in deinem Bastelzzimmer austesten.
Zu dem Datenblatt-Hinweis kann ich gerade nix sagen, hab die Passage nicht gelesen. Aber für so einfache Aufgaben kannst du ruhig die Bascom I2C-Befehle benutzen!

[Sauginius]

Danke für die Auskunft was das Kabel betrifft, ich werde das mal testen.

Ich benutze leider nicht Bascom. Ich kann nur Assembler!

[Sauginius]

Hat jemand TWI bzw I²C-Bus schon einmal mit Assembler zum laufen gebracht, und kann mir sagen was diese Deffinitionen (Seite 183, Datasheet) bedeuten?

was für ein Datenblatt, welchen AVR benutz du?

ok, alles klar, hatte es übersehen.

also: Das MT_SLA_ACK und das andere , das sind Konstanten.

cpi vergleicht das Register mit der Konstanten und je nachdem wie das Ergebnis aussieht gibts Error oder es geht weiter.

Über dem Beispiel steht auch das im Code Vereinbarungen enthalten sind die du vorher festlegen mußt.
am Anfang mußt du also mit
.equ MT_SLA_ACK = x dem Begriff eine Zahl zuordnen

so wie ich das überflogen habe ist es eine Acknoledge Abfrage, die Zahlen könnten also 0 und 1 sein, ist aber nur getippt...

hoffe erst mal weitergeholfen zu haben

byPö

[Sauginius]

Ok,
aber was hat das zu bedeuten? Ich möchte eigentlich nur den Temperaturfühler abfragen, wie bekomme ich das hin?

[Pö]

Ok ich bins wieder. Könntest du deine Fragen etwas zielgerichteter Formulieren ?

einfach nur abfragen will ich auch immer :-))

Um den Sensor abzufragen mußt du natürlich das serielle Übertragungsprotokoll des TWI einhalten. wie der aussieht steht paar Seiten vorher im Datenblatt. Der Code den du hast enthält zwischendurch Sicherheitsabfragen falls etwas schief läuft bei der Übertragung. Dann verzweigt das Programm nach Error.

Das Übertragungsprotokoll sieht kurz formuliert so aus, die Nummer entsprecheen den Abschnitten deienr Code Tabelle im Datenblatt:

START Du erklärst deinem MC das du über TWI kommunizieren willst.

Du wartest darauf das der MC alles zur Übertragung per TWI klar macht


Da du mehrere Dinge gleichzeitig am TWI hängen haben könntest mußt du erst mal eine Adresse losschicken damit dein Temp weiß das er gemeint ist. Selbige setztsich aus einem unveränderlichen und variablen Teil zusammen. Näheres zur Adresse findest du im Datenblatt des Sensors.
Die Adresse umfasst 7bit, das 8 klärt ob du zum Sensor schreiben willst oder von ihm lesen willst.

boah, ich hör jetzterst mal auf, du solltest mal genauer erklären wo dein Problem liegt.

Wenn du dein Programm erzeugst (F7) bekomst du jede Menge Fehlermeldungen nehme ich an oder? Click die mal an und poste mal ein paar Zeilen wo Fehler angezeigt werden...

byPö

[Sauginius]

Also ein Problem bis jetzt ist, dass ich nicht verstehe wie das mit den Daten empfangen funktioniert.
Aslo der LM75 hat ja ein 16Bit Register aber der µC nur 8Bit (TWDR). Wenn ich jetzt den LM75 "abfrage", schickt dieser zuerst das höhere Byte und danach das niedere Byte über den Datenbus. Aber macht der Temp sensor das selbstständig oder wartet er erst auf ein Signal vom µC um nach dem Höheren das niedere Byte zu senden?
Müsste doch so sein weil das TWDR nur 8Bit umfasst, sonst würde dieses ja "überlaufen".

Hm, verstehe das Problem.

die Antwort darauf findest du nur im Datenblatt des Sensors. Der TWI hat auch unterschiedliche Modi. Es ist zB. möglich fortlaufend Pakete zu übertragen, nach der Startadresse wird dann vermutlich automatisch hochgezählt. Ist aber nur geraten, ich hatte das Problem noch nicht, will da aber in Kürze auch hin :-)

Ich hab es im Moment genau anders herum, ich hab eine 16 bit Adresse. Das zumindest ist kein Problem. Wenn du die Antwort im Datenblatt nichtfindest sehe ich Montag selber mal rein, mal sehen ob ich schlau werde.

So absolut aus dem Bauch heraus würde ich sagen...du sendest Adresse, schaltest auf Lesen -legst ein leeres TWDR auf den Bus, liest mit IN die Daten ein, speicherst ab, legst wieder ein leeres TWDR auf den Bus, liest wieder ein und bekommst damit die zweite Hälfte.
Ist aber auch nur geraten, muß morgen erst mal einen Blick ins Datenblatt werfen.
wie gut ist der LM75 eigentlich, ich bräuchte eventuell irgendwann was mit unter 1/10 °C Auflösung, von ca 15 - 40°C.

byPö

[Pö]

Ok, hab das mal durchgesehen. Also ich bin ganz ehrlich, ich durchblick das auch nicht 100%.

Ich denke mir mal es soll so funktionieren:

1. Devicedresse schicken. Normalerweise bekommt die hinten ein WRITE Bit, in diesem Fall würde ich aber vermuten das sie ein READBit bekommt.
2. Dann müßtest du theoretisch die Speicheradresse senden. Das kann wegfallen wenn der Pointer bereits auf 0 steht - wie es meistens gebraucht wird. Statt dessen sendet der LM75 wegen dem vorhergehenden READ Bit die D15-D8. Das Ack-Bit wird nicht LOW, dem System ist also irgendwie klar das es noch weitergeht.
An der Stelle mußt du vermutlich ein STOP senden, um erst mal anzuhalten und das Datenregister auszulesen, danach legst du ein leeres Byte auf den Bus, der LM "füllt" das mit D7-D0 und dasAck Bit wird LOW als Zeichen das der Vorgang gegessen ist.

Ich denke mir mal so das es bei diesem Auslesen günstiger wäre mit den interruptbasierten Hardware TWI zu benutzen,, in zweiter Priorität den Hardware TWI mit Polling und eher notfalls den Software TWI. Bin aber da nicht so der große Ahnungshaber, kenne nur Software TWI und Hardware Polling.

Mich wundert allerdings das es dafür keinen fertigen Code gibt, hast du mal gesucht?

[Pö]

Ich bin ja auch doof, ich hab doch das Buch von Trampert da, da ist ein komplettes eräutertes Beispiel vom LM75 mit dem AT908515. Alles als Software TWI. Besord dir dasam besten mal, gibts auch CDdazu ( Bilbliothek?).

Ist Im prinzip so ähnlich wie vermutet, du fragst ab, setzt kein AcK-bit, speicherst, und fragst nochmal ab.

[Sauginius]

Also ich hab schon viel gehört von dem Buch. Manche sagen es ist in Ordnung und andere sagen es ist einfach nur das Datnblatt ins Deutsche übersetzt. Welche Controller behandelt das Buch denn?

Also ich hab mich jetzt nur mit dem Hardware TWI beschäftigt.
Laut LM75 Datenblatt muss der Master ein Ack zwischen den beiden Byte's senden (Seite 12 und 10)

[Sauginius]

Also ich hab mal versucht eine Routine zu erstellen aber irgendwie bleib ich in der "Wait1"-Schleife hängen.
Ich hab auch nicht so ganz bei den Voreinstellungen (Bit Rate, Prescaler) durchgeblickt.
Deshalb hab ich den TWBR auf 10 und den Presccaler auf 4 gestellt (siehe ersten vier Zeilen)
Ich habe mich nach dem MR Mode gerichtet (Seite 188 Datenblatt). Es kann sein das auch noch andere Fehler sich darin befinden.



ldi temp1, 0b00001010
out TWBR, temp1

ldi temp1, 0b00000001
out TWSR, temp1

ldi temp1, (1<<TWINT)|(1<<TWSTA)|(1<<TWEN) ;Start Befehl
out TWCR, temp1

wait1: in temp1,TWCR ;Wenn TWINT gesetzt ist, wurde Start übermittelt
sbrs temp1,TWINT
rjmp wait1

in temp1,TWSR
andi temp1, 0xF8
cpi temp1, 0x08
brne loop

ldi temp1, 0b10010001 ;Adresse des Tempsensors (SLA_R)
out TWDR, temp1
ldi temp1, 0b10000100
out TWCR, temp1

wait2: in temp1, TWCR
sbrs temp1, TWINT
rjmp loop

in temp1,TWSR
andi temp1, 0xF8
cpi temp1, 0x40
brne loop

in temp2, TWDR

ldi temp1, 0b11000100
out TWCR, temp1

in temp1,TWSR
andi temp1, 0xF8
cpi temp1, 0x40
brne loop

in temp3, TWDR

ldi temp1, 0b10010100
out TWCR, temp1

mov temp1, temp2
rcall lcd_data

loop: rjmp loop

[Sauginius]

Also ich habe jetzt 3,9k Widerstände als Pull-Up's des TWI genommen. Ist das in Ordnung?

[Sauginius]

oh, ich hab mich verschrieben. Ich meine natürlich Pull-Down! (Masse)

[Sauginius]

Ah, da hab ich schon einen Fehler gefunden, ich muss den Bus über die Widerstände auf Ub legen! Also doch Pull-Up
Sorry für die vielen posts!

[Pö]

ja , Wiederstände an +UBb! ic hhab 4,7k, 3,9k sollte aber auch ok sein.
code hab ich noch nicht durch , hab immoment nur Datenblatt mega163 da, dachte die sind identisch, aber da ist TWSR völlig anders ...morgen...

Fierabend....

[Sauginius]

Hast du schon den TWI zum laufen gebracht?
Ich hab auf dieser Seite http://www.sprut.de/electronic/pic/grund/i2c.htm#allgemein gelesen das mindestens 3mA über den Bus fliessen muss, d.h. die Widerstände 1,8k gross sein sollen.

Noch ein paar Hinweise zu der Routine:

Ich habe das Label ERROR durch loop ersetzt.
Zu Testen gebe ich das erste empfangene Byte über ein Display aus, nur um zu wissen ob die Übermittliung geklappt hat.

Um den Fehler weiter einzuschränken ersetze ich die Sprungbefehle zu loop, durch ein anderes Label. Das bedeutet wenn der µC zu dem Label springen will, springt er nicht zu loop sondern zu einem kleinen Unterprogramm das mir ein Wort auf dem LCD ausgibt. So fang ich bei dem ersten loop (Zeile 13) an und ersetze es, spiele das Programm auf den µC beobachte was passiert. Bekomme ich keine Anzeige weiss ich dass das Programm weitergelaufen ist. Dann ersetze ich denn nächsten Sprungbefehl loop und das Spiel beginnt von neuen.

Leider hab ich den Fehler noch nicht gefunden. :-(

[Frank]

Die Pullup-Größe (Widerstand vom Port nach +5V) ist garnicht so wichtig. Gewöhnlich wird 5 kOhm bis 100 kOhm verwendet. Ich verwende immer 10 KOhm, denn dann ist es nicht so schlimm wenn mehrere Teilnehmer am Bus Pullup-Widerstände dran haben.

[Pö]

Ja der TWI läuft bei mir. Ich spreche ein EEPROM über den Hardware TWI an (im Polling Modus) und eine RTC per Software TWI.

Ich seh bei dir keine Grundeinstellungen, also fangen wir mal an mit :

.equ EEPROM = 160 ; 1010 für EEPROM, 000x für individuelle Geräteadresse, dh Pins auf GND, x (R/W)wird softwareseitig verwaltet

Dann mache ich es so das ich die Register gerne mit ihrer Bezeichnung anspreche sofern es geht, das vereinfacht den Abgleich mit dem Datenblatt, und geht schneller, ggf müssen die Werte aber vorher vereinbart werden...


cbi TWSR, TWPS1 ; (0) Prescaler Value =1
cbi TWSR, TWPS0 ; (0)
ldi r16,0x0C ; = 12
out twbr,r16


Das nehme ich für 4MHz ! Das TWBR ist variabel, 10 - 15 sollte alles gehen.... Ob deine Werte ok sind kann ich nicht sagen da ich die Clock Frequenz deines MC nicht kenne. Kannst ja aber mit den Werten kontrollrechnen.

Sie erst mal zu das du nicht schon in der ersten START übertragung steckenbleibst ( ich bau immer kleine "rcall light" - LED Blitze ein um zu sehen ob bestimmte Stellen auch durchlaufen werden oder ob er steckenbleibt.

Da du bereits so früh hängst würde ich den Fehler
A.) irgendwo im Vereinbarungsteil von Konstanten,Variablen, usw oder
b) in der Hardware suchen.

Ich nehm nicht an das du zufälligerweise ein Speicheroszi zur Verfügung hast? Hilft ungemein.

[Sauginius]

Also ich betreibe den µC mit 16MHz.
Ich hab mal die Einstellungen von dir übernommen, leider ohne Erfolg. Vielleicht liegt es ja am LM75, ich hatte mich mal beim stecken der Pins auf dem Breadboard vertan. Dann ist der Sensor mal ganz schön heiss geworden, vielleicht hat es ihn ja zerstört!
Ich werde mal einen neuen nehmen, und das ganze ausprobieren.

[Sauginius]

Also ich hab die Hardware überprüft und den LM75 gegen einen neuen sogar ausgetauscht, aber Fehlanzeige!
Ich kann mir nur vorstellen das es irgendwie an der Voreintellung der SCL Frequenz liegen kann.

Noch eine Frage zu dem Buch, eird dort auch der Hardware TWI behandelt? Welche µC werden erklärt?