-         

Seite 1 von 4 123 ... LetzteLetzte
Ergebnis 1 bis 10 von 36

Thema: TLC59116 Led Treiber

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    20.12.2009
    Beiträge
    86

    TLC59116 Led Treiber

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    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
    Angehängte Dateien Angehängte Dateien

  2. #2
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    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?
    #ifndef MfG
    #define MfG

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    20.12.2009
    Beiträge
    86
    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
    Miniaturansichten angehängter Grafiken Miniaturansichten angehängter Grafiken clock.png  

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    26.08.2006
    Beiträge
    84
    Hi!

    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.

    // ****** send I2C byte, return TWSR & 0xf8
    uint8_t i2csendbyte(uint8_t txbyte) {
    // --- send data byte
    .......
    // --- return status
    return(TWSR & 0xf;
    }

    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..

  5. #5
    Benutzer Stammmitglied
    Registriert seit
    20.12.2009
    Beiträge
    86
    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;

    Stopbedingung

  6. #6
    Benutzer Stammmitglied
    Registriert seit
    26.08.2006
    Beiträge
    84
    Jain:

    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.
    Angehängte Dateien Angehängte Dateien

  7. #7
    Benutzer Stammmitglied
    Registriert seit
    20.12.2009
    Beiträge
    86
    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

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Jaecko
    Registriert seit
    16.10.2006
    Ort
    Lkr. Rottal/Inn
    Alter
    35
    Beiträge
    1.987
    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*
    #ifndef MfG
    #define MfG

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    20.12.2009
    Beiträge
    86
    Noch eine kurze Frage, in deinem Code sendest du die Adresse als Byte (0x9e) aber die Daten Bitweise mit maintime[i]. Ist das nur zur Sicherheit?

  10. #10
    Benutzer Stammmitglied
    Registriert seit
    26.08.2006
    Beiträge
    84
    Hi!

    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

Seite 1 von 4 123 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •