Hallo,
Ich versuche schon seit langer Zeit den Led Treiber von Atmel (TLC59116) per I2C Bus in gang zu bekommen. Jedoch klappt das mit dem I2C Bus überhaupt nicht. Kann mir bitte jemand helfen? Sonst verzweifle ich so langsam.
Ich benutze dazu einen Atmega644 und schreibe in C.
Danke,
lg Kurt
Die erste Frage dazu: Wie ist denn der Treiber an den Controller angeschlossen? Also welche Leitungen sind wie verbunden?
Klassischer Fehler (passiert mir auch immer): Die Pullups an SCL/SDA fehlen.
Dem Wert in TWBR nach geh ich davon aus, dass du den AVR mit 16MHz und I2C mit 400kHz betreibst. Korrekt?
Danke für die schnelle Antwort, hier ist meine Schaltung.
In der Schaltung denke ich ist kein Fehler, i gehe von einen Softwarefehler aus. Ich betreibe den Atmega mit 20Mhz und den Bus mit 500kHz, später wenn alles funktioniert vieleicht auch noch mit mehr Hz.
Das merkwürdige ist, dass ich auch mit dem Oszi nichts messe, aber die Ports funktionieren wenn ich sie einzeln beschalte.
lg
Da der Atmega als Master arbeitet brauchst du keine ACK hinter jedem Byte zu senden. Der Slave sendet das ack oder nack nach jedem byte das er empfängt.
Um zu sehen, ob ein byte richtig angekommen (ack) ist mußt du nach dem Senden TWSR anschaun.
0x18 für vom Slave korrekt empfangene Adresse
0x28 für vom Slave korrekt empfangenes Datenbyte
Da kann man die Adresse auch einfach als Datenbyte senden, muss halt nur die Antwort (TWSR) stimmen.
Das Gleiche solltest du auch für Start tun, dann ist 0x08 die richtige Antwort.
Immer schön eins nach dem Andern (Start, Adresse, Datenbytes) und jedesmal den Status prüfen.
Im Datenblatt des ATmega ist irgendwo eine Tabelle mit den Inhalten vom TWSR für alle möglichen Zustände.
PS: den Status als hex vorzudefinieren ist unschön, da gibs auch defines für..
Also hänge ich an jeder funktion in der ich etwas sende, dieses return dran. Soll ich dann den Befehl wiederholen lassen,wenn ein Byte nicht korrekt gesendet wurde?
Ja die Tabelle habe ich schon gefunden. Danke.
Also nochmal zusammengefasst:
Startbedingung
warten bis ack gesendet wurde
return(TWSR & 0xf;
Adresse senden
warten bis ack gesendet wurde
return(TWSR & 0xf;
Daten senden
warten bis ack gesendet wurde
return(TWSR & 0xf;
Start senden
warten bis start ist raus
return(TWSR & 0xf;
checken ob start korrekt rausgegangen ist (kann immer mal schief gehen, u.a. bei mehreren mastern)
Adresse senden
warten bis adresse draussen ist
return(TWSR & 0xf;
checken, ob adresse vom slave bestätigt wurde (ack)
Daten senden
warten, bis byte draussen ist
return(TWSR & 0xf;
checken, ob slave das byte mit ack bestätigt hat
Stopbedingung
geht einfach so, jedenfalls tu ich da nix mehr checken
Im Fehlerfall ein Stop rausschicken.
Im Anhang ein Beispiel mit ein paar kleinen Erweiterungen wie timeouts und der Versuch im Fehlerfall die Slaves etwas wachzurütteln. Geht mit Sicherheit schöner, aber tut so seit Monaten im Dauerbetrieb. Waitalittle() sind nur ein paar us.
Ach ja, zwischen einzelnen Nachrichten etwas warten kann nicht schlecht sein.
Achso, ich muss jedes Bit einzeln senden, ich dachte das geht einfach so wenn ich die Adresse reinschreibe.
Wenn ich Pullups habe, muss ich trotzdem DDRC und PORTC initialisieren?
Danke für dein Beispielcode, der hilft mir sehr und es sind einige interessante Lösungen drinnen. Ich werde nach der Arbeit versuchen ob es klappt.
Danke
lg
Die Pins für SCL/SDA brauchst du nicht initialisieren, da hier die interne TWI-Hardware arbeitet und sich selber darum kümmert.
Die wieder sauber auf Input schalten ist nur dann (sicherheitshalber) empfohlen, wenn die Pins im Programm zuvor für was anderes verwendet werden. Aber sowas macht normalerweise keiner *g*
Die gesamte letzte Routine sendet nur eine einzige Nachricht, allerdings zusammengesetzt aus den Inhalten von mehreren Feldern, u.a. den Inhalt von maintime[i]. Alles byteweise. Zwischendurch wird noch nen Feld kopiert, was ausgerechnet und das Ergebnis als einzelnes byte verschickt.
Sorry, wollte damit keine Verwirrung stiften aber auch nichts falsch verändern vorm Posten. So gehts halt
Lesezeichen