Problem: Kommunikation über RN-PC->I2C langsam

[hspecht74]

Hallo,

ich habe scheinbar ein Problem mit der I2C Geschwindigkeit über RS232 mit dem RN-PC->I2C Interface.
Der Aufbau für meinen Roboter sieht so aus:

Steuer-PC --> TCPConnection --> OnBoard-PC (derzeit zum Testen ein Notebook) --> PC->I2C Interface --> RNMotor

Am Steuer-PC habe ich einen Joystick angeschlossen, über den die Motoren am RN-Motor gesteuert werden sollen.
Kommt ein Befehl vom Steuer-PC am Notebook an, wird dieser dort ausgewertet und an die I2C-Library weitergeleitet. Ausserdem wird er im Konsolenfenster angezeigt. Das Problem ist, dass die Ausführung der I2C Befehle elendig lange dauert. Ich habe noch nicht genau gemessen, aber einmal mit dem Joystick "Gas geben" und sofort wieder loslassen erzeugt bei dem eingestellten Abfrageintervall des Joysticks ca. 6-8 zu übertragende Befehle. Die Ausführung auf dem Notebook inkl. I2C-Senden dauert für diese Befehle > 1 Sek., d.h. wenn ich den Joystick losgelassen habe kommt erst mit merklicher Verzögerung der Stop-Befehl am Motor an, auch die Ausgabe im Konsolenfenster dauert dementsprechend lange. Kommentiere ich in der SW auf dem Notebook die I2C-Send-Befehle aus, lässt sich dagegen keine Verzögerung mehr feststellen.
Die I2C-Library ist eine 1:1 Portierung nach C# aus dem Beispielprogramm, das mit dem PC->I2C Interface mitgeliefert wird. Die Delays habe ich dabei schon entfernt. Die Kommunikation klappt fehlerfrei, nur eben grottenlangsam.
Hat jemand diesen Effekt auch schonmal beobachtet und weiß vielleicht wie man da Abhilfe schafft? So wie es im Moment läuft brauche ich da ja gar nicht weitermachen...wenn später Sensordaten in kurzen Intervallen gesendet werden sollen etc. wirds ja nich besser.

Ich hoffe jemand hat eine Idee.

Hinrich

[Vitis]

nun, dann hängt das vermutlich an der Notebook-I2C-schnittstelle.
Was ist denn das für ein Ding?
ne andere Alternative wär eventuell n einfacher USB-RS232-Adapter
falls Dein Notebook eben kein COM mehr hat. Allerdings halt da nur
9600 Baud, aber vermutlich schneller als Dein Dings.

[hspecht74]

Ja das könnte sein...ich hab ein Dell Latitude D8210 mit eingebauter COM-Schnittstelle. Ich habe jetzt zum testen mal einen USB->seriell Adapter angeschlossen...die Kommunikation klappt dann immer noch, allerdings nicht schneller als vorher, sondern mit ca. 1 Byte / Sek !!!!
Werde das Ganze wohl nochmal an einem anderen PC ausprobieren.
Kennt jemand einen einigermaßen schnellen USB->Seriell Adapter?

Danke, Hinrich

[linux_80]

Da würde ich doch dann gleich nach einem USB->I2C Adapter ausschau halten (bzw. selbst bauen mit AVR), denn über RS232 ist das nur BitBanging, und das ist langsamer.

[Vitis]

1 Byte / Sekunde ?¿ ... kann nicht sein. Die Hardware kann
dafür nicht verantwortlich sein, da ja die Baudrate
stimmen muss, damit das Ding überhaupt was empfängt.
Muss Software- oder Treiberfehler sein.
In was progst Du die Software? VB? C# ?

u.U. kann man da ja mal ansetzen mit Debuggen.

[hspecht74]

C#. Die Software ist okay, es dauert tatsächlich so lange bis der Bus wieder frei ist. Ich vermute momentan dass es ein Treiberproblem ist. Der USB->RS232 Adapter ist ein NoName Teil für 2,50...wahrscheinlich mit der entsprechenden Qualität.
Ich werde das ganze nochmal an nem anderen PC ausprobieren. Habe allerdings auch beim Nachforschen im Netz festgestellt dass die SerialPort-Klasse von .NET nicht unbedingt die schnellste ist. Da kommt dann vielleicht eins zum anderen. Mal sehen, wenn ich Zeit finde probiere ich es auch nochmal mit der alten Comm.dll über Interop.

Viele Grüße,
Hinrich

[linux_80]

Wenn Du doch was selber bauen willst:
http://www.harbaum.org/till/i2c_tiny_usb/index.shtml

[Netzman]

Ich habe mir den USB/I²C Adapter von www.openservo.org (OSIF -> http://www.robotfuzz.com/OSIF ) nachgebaut, läuft mit einem Mega8 und funktioniert bei mir einwandfrei.

mfg

[Lurchi]

zur Vollständigkeit: Bei mir läuft das RN-Motorcontrol sauber an der RS232.
Allerdings kann man bei Windows die Com-Port Einstellungen optimieren - das hat vor allem beim Empfang der Daten großen Einfluss:

Wichtig ist Teil bei "SetCommTimeouts" - da wird eingestellt, wie lange auf das nächste Zeichen gewartet werden soll bevor die das Read auf dem Comport wieder zurückkommt. (Achtung: Bei zu kurzem Timeout, kann es sein, das die Gegenstelle einfach nicht schnell genug sendet...)

Die komplette OpenComPort Funktion:


int OpenComPort()
{
DCB dcb;
COMMTIMEOUTS timeout;
TCHAR *pcCommPort = TEXT("COM1");

m_hCom = CreateFile( pcCommPort, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
if (m_hCom == INVALID_HANDLE_VALUE)
{
return FAILED;
}

SecureZeroMemory(&dcb, sizeof(DCB));
dcb.DCBlength = sizeof(DCB);
if (!GetCommState(m_hCom, &dcb))
{
CloseComPort();
return FAILED;
}

// Fill in DCB: 9600 bps, 8 data bits, no parity, and 1 stop bit.
dcb.BaudRate = CBR_9600; // set the baud rate
dcb.ByteSize = 8; // data size, xmit, and rcv
dcb.Parity = NOPARITY; // no parity bit
dcb.StopBits = ONESTOPBIT; // one stop bit

if (!SetCommState(m_hCom, &dcb))
{
CloseComPort();
return FAILED;
}

timeout.ReadIntervalTimeout = 60;
timeout.ReadTotalTimeoutMultiplier = 0;
timeout.ReadTotalTimeoutConstant = 1000;
timeout.WriteTotalTimeoutConstant = 0;
timeout.WriteTotalTimeoutMultiplier = 1000;

if (!SetCommTimeouts(m_hCom, &timeout))
{
CloseComPort();
return FAILED;
}

return SUCCESS;
}


Außerdem ich habe aber beobachtet, dass die Übertragung von vielen kleinen, einzelnen Datenpaketen scheinbar insgesamt langsamer ist als die Übertragung großer zusammenhängender Datenblöcke.