Uebertragungsfehler mit RNKC10 (was: SCL bleibt low)

[Vinter]

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

[Ratber]

Hast du an die Pullups gedacht ?

[Vinter]

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.

[Ratber]

Jtag abgeschaltet ?

[uwegw]

je länger die Leitung, desto kleiner sollte man die Pullups machen... 27K ist schon ne Menge, üblich wäre ein Zehntel davon...

[Ratber]

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 ?

[Vinter]

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

[Ratber]

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

[Vinter]

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

[Ratber]

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.

[Vinter]

Dochdoch, die Fuses sind DF und 3F :/
D.h., falls du grad keinen Rechner da hast, Clock Selection alle 1 (-> Ext Crystal), SUT1 und SUT0 1 -> Langer Startup, BODEN und BODLEVEL gesetzt, also empfindliche Brown-Out-Erkennung, die Bootloader-Sachen alle 1, CKOPT 1, also schneller Quarz, SPIEN 0, also ISP an, und JTAGEN und OCDEN 1, also aus.

box:~# avrdude -p m32 -c stk200 -t

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9502
avrdude> dump hfuse
>>> dump hfuse
0000 df |ß |

avrdude> dump lfuse
>>> dump lfuse
0000 3f |? |

avrdude>

Kann ich also davon ausgehen, dass der Quarz laeuft, ich ihn also nur nicht messen kann?

Gruss und Danke,
David

[Vinter]

OK, noch ein paar Tests mit den Timern gemacht, bin mir sicher, dass er laeuft, 100% genau mit 16MHz-Einstellung :) Sorry, dass das so seltsam lief, aber ich hatte den Quarz vor einiger Zeit auch mit einem wirklich guten Oszi nicht messen koennen; bin ziemlicher Neuling, und deshalb immer unsicher...

Jetzt geht jedenfalls alles! Danke,
David

[Vinter]

Grmbl... zu fueh gefreut...
Jetzt wird es fast schon zu speziell, trotzdem mal die Frage, bin ja im Roboternetz und das Bauteil (RNKC10) ist euer Standard ;) : Das zweite Byte (Servoposition) produziert nur ein Write Failed, sonst geht alles... Jemand eine Idee? Weder Source noch Elektronik wurden seit gestern, als uebertragen wurde, veraendert, was I2C-Angelegenheiten betrifft.

Auch wenn sichs wiederholt: Gruss und Danke,
David

[Ratber]

Das zweite Byte (Servoposition) produziert nur ein Write Failed, sonst geht alles...

Wie überträgst du ?

Start
Byte1
Ack
Byte2
Ack
Byte3
Ack
Stop

Oder

Start
Byte1
Ack
stop
Start
byte2
Ack
Stop
Start
byte3
Ack
Stop


Edit:
Hab doch glatt das 3. Byte unterschlagen.

[PicNick]

Habt ihr berücksichtigt, daß der RNKC10 als Soft-I2c saumäßig langsam ist ? Mit normaler Speed geht da nix

[Ratber]

Ich gehe davon aus das dem Baustein der Entsprechende Hinweis auf den Maximaltakt beiliegt und das auch umgesetzt wurde.

[Frank]

Der I2C-Mode dieses Bausteins arbeitet nach meiner Erfahrung nicht 100% stabil. Clock Stretching wird auch nicht berücksichtigt obwohl es gerade bei der verlassamten Frequenz gut wäre.
Ich hatte damals jedenfalls auch Probleme damit. Das Problem ist das der Baustein kein Hardware I2C besitzt und alles per Software realisiert wurde. Da gibts wohl ab und zu Timing Probleme mit der Servoansteuerung und dem gleichzeitigen I2C Protokoll. Das läßt sich kaum vermeiden.
Ich würde ihn nur im RS232 Mode betreiben. Aus dem Grund ist auch später noch RNS1 rausgekommen, hier wurde der I2C Mode ganz weggelassen um Probleme zu vermeiden.

[Vinter]

@Ratber: Erstere Variante, so wie es der Autor in der Doku angegeben hat.
@PickNick: Natuerlich, wird ja mehrmals gewarnt, aber bis 1000Hz runter keine Verbesserung...
@Frank: Das hoert sich aber sehr, sehr schlecht an :( Problematischerweise habe ich naemlich 12 Servos anzusteuern, d.h. 6 pro RNKC10 momentan... Ueber UART kann ich da ja wohl kaum umschalten, oder? Da die Leitungen per Transistoren umzulegen o.ae. wuerde ja wohl auch die Sync zerstoeren (vermute ich, habe UART noch nie verwendet). Naja, mal den Source ansehen, evtl. schaffe ich es, den um ein Identifikationsbyte zu erweitern...
Brauche ich fuers UART irgendwelches zusaetzliches, komplizierteres Equipment, oder sind das praktisch nur zwei andere Leitungen mit anderem Code?

Gruss und Danke,
David

[Frank]

Nix ist einfacher als UART (rs232). Einfach TX an RX und RX an TX , Baudrate einstellen und mit Print Befehle übermitteln.
Du kannst auch zusätzlich noch einen zweiten Port als RS232 definieren (in Bascom ist das vorgesehn), so kannst du mehrere Servotreiber anschließen.

Gruß Frank

[Ratber]

@Vinter



@Ratber: Erstere Variante, so wie es der Autor in der Doku angegeben hat.


Ja,so ist das auch richtig.

Kannst du feststellen ob nach dem 2. Byte auch ein Ack zurückkommt ?