-
        

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 20

Thema: Uebertragungsfehler mit RNKC10 (was: SCL bleibt low)

  1. #1
    Benutzer Stammmitglied
    Registriert seit
    12.02.2005
    Beiträge
    38

    Uebertragungsfehler mit RNKC10 (was: SCL bleibt low)

    Anzeige

    Hi,

    momentan versuche ich, 12 Servos mit 2 RNKC10 anzusteuern, unter Verwendung eines Mega32 als Master. Hierbei kommt die I2C-Lib von Peter Fleury zum Einsatz.
    Nun vermute ich mal, dass die Servocontroller in Ordnung sind; beim Einschalten werden geschaetzte 1.5ms Puls auf der Steuerleitung erzeugt, soweit in Ordnung.

    Nun funktioniert die Uebertragung aber leider ueberhaupt nicht; Messungen ergeben, dass SCL low ist, waehrend SDA high bleibt, der Bus also in einem mWn nicht definierten Zustand ist. Da das ganze so bleibt, wenn ich die Slaves abklemme, scheint der MAster schuld zu sein.

    Nun frage ich mich, was der damit andeuten will - die Situation passt irgendwie auf keine Stelle ausser zwischen der Uebertragung von zwei Bits... Kann jemand vllt. mal kurz eine Checklist hinwerfen, was die Hauptfehlerquellen beim I2C-Bus sind?
    So komplex scheint er mir ja nun nicht; und wenn das Signal erzeugt wird und alle Chips sich programmieren lassen, sollte die Schaltung ja so weit i.O. sein, dass das Problem im Bus liegt...

    Gruss und Danke,
    David

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.09.2004
    Ort
    Düsseldorf
    Beiträge
    3.948
    Hast du an die Pullups gedacht ?
    Gruß
    Ratber

  3. #3
    Benutzer Stammmitglied
    Registriert seit
    12.02.2005
    Beiträge
    38
    Sicher, sonst waer ja SDA auch low. 27k sind drin, das erste, was die Kiste hergab, ist zwar hoch, aber sollte ja bis 100k gehen, ne?

    Waer nett, wenn jemand helfen koennt, steh grad ziemlich hilflos da

    Danke,
    v.

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.09.2004
    Ort
    Düsseldorf
    Beiträge
    3.948
    Jtag abgeschaltet ?
    Gruß
    Ratber

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    06.02.2005
    Ort
    Hamburg
    Alter
    31
    Beiträge
    4.255
    je länger die Leitung, desto kleiner sollte man die Pullups machen... 27K ist schon ne Menge, üblich wäre ein Zehntel davon...

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.09.2004
    Ort
    Düsseldorf
    Beiträge
    3.948
    Ja,das ist ne Sache der Störesicherheit.
    In den Specs werden 4.7K angegeben.

    Aber gerade bei 27K müßte es besonders gut gehen.

    Es geht darum warum der SDA sich nicht bewegt.


    @Vinter

    Hast du nochmal alles kontrolliert ?
    Jede Leitung am richtigen Pin ? (Auch die Slaves)
    Nutzt du die Hardware Ports oder eigene ?
    I2C auf dem M32 komplett initialisiert ?
    Gruß
    Ratber

  7. #7
    Benutzer Stammmitglied
    Registriert seit
    12.02.2005
    Beiträge
    38
    Pins sind xmal kontrolliert, das ist sicher Die Leitungen sind insgesamt vllt 5cm lang, also fast irrelevant, keine Stoerquellen. Und ich benutze die Hardware-I2C-Lib von Peter Fleury, ist ja relativ bekannt, die initialisiert alles gleich mit.
    Daher verstehe ich auch nicht, warum nichts passiert - sind ja praktisch wirklich nur die I2C-Leitungen, die Pullups dran und die definitiv funktionierende Library... Auch die Slaves sind RN-Standard...

    Naja, noch mal kontrollieren, das mit dem JTAG koennte hoechstens noch sein, auch wenn ich mit einem uC gearbeitet habe, bei dem das aus sein muesste, bzw gewechselt habe. Blockiert das wirklich PORTC, nicht nur die oberen 5 bit?

    Danke jedenfalls,
    David

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.09.2004
    Ort
    Düsseldorf
    Beiträge
    3.948
    Nun der M32 ist bis auf die Speicherausstattung identisch zum M16 also gehe ich mal davon aus das auch er das gleiche Verhalten an Port C hat.

    Ich hab momentan keinen M32 hier um das mal gegenzuprüfen.
    Normalerweise schalte ich das Jtag generell aus da ich es nicht brauche.

    Probiers einfach mit dem Fusebit.
    Mehr wie "Fehlanzeige" kann es nicht geben aber wir könnten den Punkt abhaken
    Gruß
    Ratber

  9. #9
    Benutzer Stammmitglied
    Registriert seit
    12.02.2005
    Beiträge
    38
    War Fehlanzeige, aber mittlerweile ist die Sache geloest, naja halbwegs.
    Und zwar laeuft alles, sobald ich die Funktion i2c_start statt start_wait benutze, also ohne Ruecksicht auf Busy-Status auf den Slave schreibe. Das ist nun gar nicht schoen, weil ich dann manuell warten muss, aber nun ja. Falls niemandem etwas dazu einfaellt, werde ich es
    wohl dabei belassen.

    Dafuer kaempfe ich grade mit dem Quarz und dem Timing, also der naechsten Stufe, um die Servos zu koordinieren... Clock Source ist zwar External und CLKOPT 0, auf Mega32 16pu aber er schwingt nicht mit 22pf-Kerkos, zumindest laut Oszi. Kann ich am Verhalten des Chips (laesst sich programmieren / mach I2C / ...) erkennen, ob Clock ankommt, oder sollte ich einfach einen 4MHz-Quarz einsetzen und fertig? Oder kann man dQuarze aus irgendeinem Grund gar nicht messen?

    Gruss und Danke,
    David

  10. #10
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.09.2004
    Ort
    Düsseldorf
    Beiträge
    3.948
    Yo,also Softwareproblem.


    .............Clock Source ist zwar External...........
    Also da stimmt was nicht.

    Du gibst an den Takt auf Extern gestellt zu haben aber der Contr. läuft nicht mit nem Qarz aber er läst sich weiterhin ansprechen.

    Das ist wiedersprüchlich.

    Ständen die Fuses tatsächlich auf Extern dann würdest du ohne Externen Takt garnicht mehr an den Controller herankommen.
    Auf Extern läuft er aber auch nicht mit nem Quarz.
    Wenn du ihn ansprechen kannst und kein Quarz drann ist dann steht er immernoch auf "Intern".

    Also entweder du hast das ganze falsch beschrieben oder den Contr. nicht richtig erwischt.
    Gruß
    Ratber

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

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