Problem mit RN-Motor über i2c

Hallo an Alle,

ich habe mir einen RN-Motor ST I2C- 1.6c gekauft.
Den Bausatz habe ich nach der Anleitung verlötet.
Beim anlegen einer Spannung fließen 38mA.
Er blinkt beim anschließen an 12V und gibt über RS 232 Referenzspannung, Slave Id … usw aus.

Leider ist bei der Beschreibung trotz Ankündigung kein Software-Beispiel für c-control dabei.
Deshalb habe ich mir folgendes Programm zusammengesucht.

define sda port[2]
define scl port[1]
define daten byte
define n byte

sda = on
scl = on

gosub start
daten = 10 'kennung
gosub i2c_write
daten = 1 'befehlscod
gosub i2c_write
daten = 2 'motor
gosub i2c_write
daten = 50
gosub i2c_write
daten = &H56
gosub i2c_write
gosub stop

gosub start
daten = 10 'kennung
gosub i2c_write
daten = 14 'befehlscod
gosub i2c_write
daten = 0 'motor
gosub i2c_write
daten = 0
gosub i2c_write
daten = &H56
gosub i2c_write
gosub stop

gosub start
daten = 10 'kennung
gosub i2c_write
daten = 4 'befehlscod
gosub i2c_write
daten = 2 'motor
gosub i2c_write
daten = 1
gosub i2c_write
daten = &H56
gosub i2c_write
gosub stop

gosub start
daten = 10 'kennung
gosub i2c_write
daten = 8 'befehlscod
gosub i2c_write
daten = 2 'motor
gosub i2c_write
daten = 100
gosub i2c_write
daten = &H56
gosub i2c_write
gosub stop

gosub start
daten = 10 'kennung
gosub i2c_write
daten = 6 'befehlscod
gosub i2c_write
daten = 2 'motor
gosub i2c_write
daten = 0
gosub i2c_write
daten = &H56
gosub i2c_write
gosub stop

end

#i2c_write
for n = 1 to 8
sda = off
if (daten and 128) = 128 then sda = on
pulse scl
daten = daten shl 1
next
pulse scl
return

#start
sda = off
scl = off
return

#stop
sda = off
scl = on
sda = on
return

Ich versuche nun seit 5 Tagen ohne Erfolg den Treiber zum laufen zu bringen.

Bitte sagt mir, was ich falsch mache.

Das Problem liegt offenbar an deinen I2C Routinen. Bei I2C muss auch überprüft werden ob die Clock-Leitung nach dem Pulse wieder High ist. Wenn nein, dann will der Slave nämlich das der Master etwas wartet.

Ältere Routinen die noch oft bei der CC1 und CC2 verwendet werden berücksichtigen dies nicht, da früher wenige Slaves von dieser EIgenschaft Gebrauch gemacht haben . In neuerer Hardware/Compilern (z.B. Bascom / AVR) ist sowas schon länger integriert.

Also einfach die Routinen etwas umschreiben. Leider habe ich keine CC1 mehr, somit kann ich kein Beispiel bereitstellen. Aber vielleicht hilft dir da ein anderer CC1 Experte.

Gruß Frank

Hallo,

Zitat:

---

Zitat von Frank

Das Problem liegt offenbar an deinen I2C Routinen. Bei I2C muss auch überprüft werden ob die Clock-Leitung nach dem Pulse wieder High ist. Wenn nein, dann will der Slave nämlich das der Master etwas wartet.

---

an den Routinen liegt es nicht :-)

Wenn ich mir diesen Auschnitt aus dem gepostetet Programm ansehe:


gosub start
daten = 10 'kennung
gosub i2c_write
daten = 1 'befehlscod
gosub i2c_write
daten = 2 'motor
gosub i2c_write
daten = 50
gosub i2c_write
daten = &H56
gosub i2c_write
gosub stop

fällt mir, auch ohne das Board zu kennen und nach nur oberflächlicher Betrachtung des Manuals auf, das hier die immer zunächst erforderliche Adressierung (Slaveadress &h56 für schreiben, &h57 für Lesen) ja erst ganz am Ende gesendet wird. Woher soll denn das Board wissen, daß es gemeint ist?
Die "Kennung" ist zwar das erste der insgesamt 5 Bytes die übermittelt werden müssen, vorher muss das IC aber erst mal aufwachen.

Grüße
Henrik

An den I2C Routinen liegt es auch, aber stimmt natürlich, die Bytefolge ist auch falsch. Das kommt noch zu dem von mir gesagten hinzu,habe ich doch ganz übersehen. Also erst Slave Adresse dann die 5 Byte.

Danke für eure Hlfe.

Ich werde das mit der SlaveID gleich mal ausprobieren.
Habe mir die Reihenfolge von einem Programm für die RN-Control abgeschaut.

Wenn jemand Erfahrung mit der Kombination C-Control, RN-Motor über
I2C Buss hat, wäre ich auch dankbar für ein Beispielprogramm.

Gruss Rille

Hallo,

Zitat:

---

Zitat von Frank

An den I2C Routinen liegt es auch, aber stimmt natürlich, die Bytefolge ist auch falsch. Das kommt noch zu dem von mir gesagten hinzu,habe ich doch ganz übersehen. Also erst Slave Adresse dann die 5 Byte.

---

na ja, auf high sollten die Pegel auch nach einem Pulse wieder gehen. Der Ausgangszustand sollte ja zu dem Zeitpunkt high sein. Bei meinen Routinen für die Micro nutze ich allerdings ein doppeltes toggle. Bewirkt das gleiche, ist aber (in diesem Fall nützlicherweise) etwas langsamer.

Ich hänge den rudimentären Code (Vorsicht! Basic++) für die generischen Rotinen mal an:

Code:

---

'-------------------------------------------------------------------
'-------------- Rudimentäre I2C Funktionen -------------------------
'-------------------------------------------------------------------
FUNCTION IICSTART()
SDA=off
SCL=off
END FUNCTION
'-------------------------------------------------------------------
FUNCTION IICSTOP()
SDA=off
SCL=on
SDA=on
END FUNCTION
'-------------------------------------------------------------------
FUNCTION IICREAD()
deact SDA
DATA=0
MASK=80h
#INSHIFT
SCL=on
if SDA=on then DATA=(Data or MASK)
SCL=off
MASK=MASK shr 1
if MASK <>0 then goto INSHIFT
'---- 9. Takt für ACKN bzw. NACKN ----------------------------------

'ACHTUNG! Je nach Erfordernis (letzte Leseoperation
'bei sequentiellem lesen?) muss danach ACKN oder NACKN
'aufgerufen werden! Daher ist (N)ACKN hier NICHT
'Bestandteil der Funktion!

END FUNCTION

'------------------------------------------------------------------

FUNCTION IICSEND(data ref DATA)
 MASK=80h
 #OUTSHIFT
 SDA=(DATA and MASK)
 SCL=on
 SCL=off
 MASK=MASK shr 1
 if MASK<>0 then goto OUTSHIFT
'------------------------------- 9. Takt für ACKN -----------------
deact SDA
 SCL = on
 SCL = off
 ackflag = not sda              'Ackn von Slave gesendet?
 SDA= off
end function

'------------------------------------------------------------------
function ACKN()
 SDA = OFF
 TOG SCL
 TOG SCL
END FUNCTION
'------------------------------------------------------------------
function NACKN()
 SDA = ON
 TOG SCL
 TOG SCL
END FUNCTION
'------------------------------------------------------------------

---

Definitionen und Deklarationen sind nicht enthalten, können aber bei Bedarf von meiner HP geladen werden.

Grüße
Henrik

Hallo Hrei,

danke für deine Hilfe.
Leider reichen meine Programmierkentnisse nicht dazu aus, dein Basic++
Programm für mein Problem verwerten zu können.

Die SlaveID habe ich an den Anfang meiner Routinen gelegt.

Aber bei dem Versuch, die Pegel nach einem Puls auf high zu setzen, habe ich mir die Zähne ausgebissen.

Ich fürchte, dass ich da etwas Grundsätzliches nicht verstanden habe.

Kannst du das mit der Rückmeldung noch mal für Dummis erklären?

Danke Gruß Rille

Zitat:

---

Zitat von hrei

na ja, auf high sollten die Pegel auch nach einem Pulse wieder gehen. Der Ausgangszustand sollte ja zu dem Zeitpunkt high sein. Bei meinen Routinen für die Micro nutze ich allerdings ein doppeltes toggle. Bewirkt das gleiche, ist aber (in diesem Fall nützlicherweise) etwas langsamer.

---

Nu deine Methode ist allerdings keine Lösung wenn es um Clock Stretching geht. Du unterstützt es einfach nicht.
Schau mal unter:
https://www.roboternetz.de/wiki/pmwi...lockStretching

Zitat:

---

Zitat von Frank

Zitat:

---

Zitat von hrei

na ja, auf high sollten die Pegel auch nach einem Pulse wieder gehen. Der Ausgangszustand sollte ja zu dem Zeitpunkt high sein. Bei meinen Routinen für die Micro nutze ich allerdings ein doppeltes toggle. Bewirkt das gleiche, ist aber (in diesem Fall nützlicherweise) etwas langsamer.

---

Nu deine Methode ist allerdings keine Lösung wenn es um Clock Stretching geht. Du unterstützt es einfach nicht.
Schau mal unter:
https://www.roboternetz.de/wiki/pmwi...lockStretching

---

Nein, Clock-Stretching wird in der Tat nicht unterstützt. Nur hat Clock-Stetching nichts mit dem vorliegenden Problem zu tun. Bascom fragt die Clock Leitung nämlich auch nicht ab und wäre insofern auch untauglich. Zumindest sagt mir das der Blick in die i2c.lib (Version 1.11.7.4).

Es liegt also an etwas anderem, daß Rille im Moment keinen Erfolg hat.
Leider habe ich keine CC1 (mehr) und auch kein RN-Motormodul, insofern kann ich das alles nicht in der Praxis überprüfen. Das wäre aber nötig um gezielten vernünftigen Rat zu geben.

Bei der Gelegenheit ein Kommentar, den ich mir eigentlich verkneifen wollte:
Ihr schreibt, daß Beispiele und Demos auch für die C-Control mitgeliefert werden. Dann sollte man das auch tun, oder sich als Vertreiber spätestens dann hinsetzten und seine Hausaufgaben nachholen, wenn das Problem akut auftritt.

Für die Zukunft einfach die Beschreibung dahingehend ändern, daß für einwandfreie Funktion nur für Bascom und AVR µCs garantiert werden kann.

Henrik

Zitat:

---

Zitat von hrei

Nein, Clock-Stretching wird in der Tat nicht unterstützt. Nur hat Clock-Stetching nichts mit dem vorliegenden Problem zu tun. Bascom fragt die Clock Leitung nämlich auch nicht ab und wäre insofern auch untauglich. Zumindest sagt mir das der Blick in die i2c.lib (Version 1.11.7.4).

---

Die Version ist ja auch schon lange veraltet. Dafür wurde schon vor langem ein I2C Bugfix gepostet das I2C Clock Stretching unterstützt.
Die neueren Versionen von Bascom unterstützen das von sich aus.

Und zudem hat es schon mit dem Problem zu tun. Ich hab ja die Firmware geschrieben, von daher muss ich wohl wissen ob ich CLock Stretching nutze oder nicht. :-)

Zitat:

---

Zitat von hrei

Es liegt also an etwas anderem, daß Rille im Moment keinen Erfolg hat.
Leider habe ich keine CC1 (mehr) und auch kein RN-Motormodul, insofern kann ich das alles nicht in der Praxis überprüfen. Das wäre aber nötig um gezielten vernünftigen Rat zu geben.

---

Es liegt schon daran, glaubs mir, ich habe RN-Motor.

Zitat:

---

Ihr schreibt, daß Beispiele und Demos auch für die C-Control mitgeliefert werden. Dann sollte man das auch tun, oder sich als Vertreiber spätestens dann hinsetzten und seine Hausaufgaben nachholen, wenn das Problem akut auftritt.

---

Ok, die Kritik ist Teil berechtigt, ich hatte damit gerechnet das es mehr Anwender mit C-Control gibt und einer so zuvorkommend ist und ein kleines Demo im Forum bereitstellt. Aber offenbar scheinen die C-Control Programmierer wirklich ausgestorben zu sein.
Die Kritik müsste ja fairerweise auch an die Progranmmierer der C-Control Firmware gehen, die berücksichtigen schließlich diese Standard Betriebsart nicht. Sie unterstützen eigentlich keinerlei I2C, die Routinen muss der Anwender immer selbst schreiben.

Zitat:

---

Zitat von hrei

Für die Zukunft einfach die Beschreibung dahingehend ändern, daß für einwandfreie Funktion nur für Bascom und AVR µCs garantiert werden kann.

---

Wäre nicht ganz richtig, denn grundsätzlich kann es jedes Board ansteuern das den I2C Standard wirklich erfüllt und somit auch Clock Stretching berücksichtigt. So werde ich es wohl in der Doku ergänzen.

Also, ich bin jetzt dem Problem so aus dem Weg gegangen,
dass ich mir eine RN-Control mit Buch bestellt habe.

Ich hoffe, dass das nicht der Sinn der Fehlinformation auf der Beschreibung zum RN-Motor war.

Hoffentlich gibt es einen guten Support zum RN-Bord.
Frank hat nämlich was gut zu machen.

Danke an alle
Rille

https://www.roboternetz.de/phpBB2/dl...gory&cat_id=26