IOW24 Fehlendes Stopbit beim Lesen => Timing?

[unix]

Guten Tag,

Ich komme mal schnell auf den Punkt :)

Ich habe 2 Geräte hier, die ich per I²C Messages ansprechen kann.
Bin gerade dabei mir eine eigene Schnittstelle (in Java) zu meinem USB to I2C Dongle zu entwickeln.
Benutzt wird die Version 1.5 der iowkit.dll unter Windows XP!

Bei den Geräten ist eines der Nachfolger des anderen, neue Hardware und ist auch schneller (interne Mikrocontroller etc.)

So meine Schnittstelle funktioniert mit dem älteren Modell wunderbar (read/write auf den I²C Bus).

Bei der neueren Version hingegen bekomme ich beim Lesen immer eine fehlende Stopbedingung und die restlichen Interaktionen mit dem Bus sind dann nutzlos bzw. fehlerhaft!

Hier mal kurz zwei Bildchen von meinem Trace Programm:


Hier sieht man die Fehlende Stop Bedingung (Message Nr.3 checkt ob die Adresse erreichbar ist, danach wird eine Message zum Slave gesendet damit man was auslesen kann und dann liest man aus)
Durch die fehlende Stop Bedingung bricht der im Bild nach 12 Bytes ab und bringt nur noch Nullen. Obwohl die angeforderten 25 Bytes alle != 00 sind!

Wenn ich danach die gleiche Adresse nochmal auslesen möchte hängt der dem ersten Lesevorgang ein paar Bytes an, bringt ein StopBit und bringt danach wieder nur Müll + Fehlende Stop Bedingung:



Ich dachte zuerst, dass wegen dem schnelleren Gerät etwas mit den Timings nicht stimmt und der deswegen nicht richtig lesen kann. Habe dann versucht die Taktung vorher einzustellen.
Dafür habe ich nachgeschaut wie Herr Wagner dies in seinem IOWJ erledigt.

Beim aktivieren der SpecialModeFunction schickt Herr Wagner ja folgenden Report:
{ 1, 1, x, 0, 0, 0, 0, 0} x= 0 für 100 kHz, 1 für 400kHz, 2 für 50 kHz.

Ich habe die 3 verschiedenen Taktungen bei mir ausprobiert aber keines hat geholfen.
Leider findet man (oder nur ich) keine näheren Informationen in den Dokus zu der Einstellung des Takts. Unter 5.10.1 steht nix von diesem 3. Byte!

Ist vielleicht diese Einstellung des Takts falsch?

Hier mal kurz meine Interaktionen mit der iowkit.dll:

Code: Select all

long devHandle = IowKit.openDevice();

//Aktivierung der Special Mode Funktion
IowKit.write(devHandle, 1, { 1, 1, 1, 0, 0, 0, 0, 0 });

// flags werden wie bei IOWJ erstellt (Start-Stop Bedingungen etc. das Schreiben geht ja auch)
IowKit.write(devHandle, 1, {2,flags,data,data,data,data,data,data});

//Überprüfen ob das Schreiben korrekt war
IowKit.readNonBlocking(devHandle, 1, 8);
....
//Lese von adress bytes Bytes //hier fehlt die Stop Bedingung!
IowKit.write(devHandle, 1, { 3, bytes, adress, 0, 0, 0, 0, 0 });

//Daten aus dem IOW24 auslesen => das klappt auch
IowKit.readNonBlocking(devHandle, 1, 8);
...

Mit meinem Trace Programm kann ich auch als Master auf den Bus schreiben und wenn ich das gleiche mit diesem durchführe klappt alles auch wunderbar!
Somit liegt es nicht am Gerät sondern an meinem Code!

Hat vielleicht noch jemand eine Idee bezüglich dieser fehlenden Stop Bedingung?

Ich hoffe man kann mein Problem einigermaßen verstehen :)

Danke!

[Christoph Jung]

die I2C Funktionalität wurde um ein timeout erweitert. Das ist im neuern Datenblatt zum IOW24 beschrieben. Ich weiß zwar nicht ob das hilft dort was einzuestellen. Aber wenn das ganze mit 2 älteren Ihrer Chips funktioniert, und nun mit einem neueren nicht, dann liegt evtl. dort ein Problem vor? Funktioniert es denn, wenn man 2 neue Geräte zusammen verwendet?

Ach ja bei I2C würde ich IowKitRead nehmen anstelle von NonBlocking. Bei Nonblocking kann es sein, dass er mit dem Lesen schon fertig ist, bevor neue Daten vorliegen.

[Guido Körber]

Der IOW24 hat keine Einstellung für die Datenrate auf dem I2C, sondern läuft immer mit ca. 100 kHz. Den einstellbaren Takt hat der IOW56.

Ist der IOW24 von der aktuellen V1.0.3.0?

[unix]

Ist der IOW24 von der aktuellen V1.0.3.0?

Ja ist er!

Ach ja bei I2C würde ich IowKitRead nehmen anstelle von NonBlocking. Bei Nonblocking kann es sein, dass er mit dem Lesen schon fertig ist, bevor neue Daten vorliegen.

Aber das fehlende Stopbit wurde ja in IowKitWrite verursacht.

Aber ich habe einen anderen Fehler entdeckt...

Meinen Tracer hatte ich nur mit GND, SDA und SCL angeschlossen, weil der eig. den Strom selbst über USB zieht, aber anscheinend hat der mir trotzdem Spannung vom I²C geklaut...

Hab den Tracer jetzt noch mit VCC angeschlossen und jetzt krieg ich ein Stopbit und es läuft auch! Aber ich kriege im Anschluss an einen Read Befehl noch ein ErrorBit hinter her geschoben.
Liegt vielleicht daran, dass jetzt zuviel Spannung anliegt ^^



Und ich habe noch den Fehler, dass ich ein Gerät nicht zwei mal hintereinander auslesen kann. Ich muss es immer wieder abziehen und neu anschließen.

Ich habe auch schon versucht einen Reset vom Dongle zu implementieren:

Code: Select all

		int[] sbuf = { 0, 0, 0, 0, 0, 0, 0, 0 };
		IowKit.write(devHandle, 1, sbuf);
		IowKit.closeDevice(devHandle);

		devHandle = IowKit.openDevice();
		IowKit.setTimeout(devHandle, 2000);
		IowKit.setWriteTimeout(devHandle, 2000);

		int[] tbuf = { 1, 1, 0, 0, 0, 0, 0, 0 };
		IowKit.write(devHandle, 1, tbuf);

Dies hat aber leider noch nichts gebracht.

Vielen Dank für die Hilfe bis jetzt =)

[Christoph Jung]

Aber das fehlende Stopbit wurde ja in IowKitWrite verursacht.

Trotzdem Rate ich IowKitRead() zu nutzen da so sichergestellt ist, dass auch das gelesen wird was gesendet wurde und nicht irgendwas von davor.

Und ich habe noch den Fehler, dass ich ein Gerät nicht zwei mal hintereinander auslesen kann. Ich muss es immer wieder abziehen und neu anschließen.

Ein paar mehr Informationen dazu wäre gut. Ich kann mit der Fehlerbeschreibung nämlich nicht viel anfangen.

[Guido Körber]

Haben Sie ein Speicheroszilloskop zur Verfügung um mal nachzusehen wie das Signal auf der Leitung aussieht?

[unix]

ok ich versuche es mal besser zu erklären:

Hier mal ein Screenshot vom Trace, wenn ich das Programm 2 mal nach einander ausführe:



Es werden zuerst 5 Bytes an das Gerät gesendet, dann 25 ausgelesen!
Danach wird der Dongle im Programm (hoffentlich korrekt) beendet.
Nun nochmal kurz die Abfolge vom Programm:

Code: Select all

		long devHandle = IowKit.openDevice();

//Special mode Function aktivieren
		int[] tbuf = { 1, 1, 0, 0, 0, 0, 0, 0 };
		IowKit.write(devHandle, 1, tbuf);

//Bytes an Gerät senden über I²C //wbuf wird wie bei IOWJ generiert mit den flags usw. 
		long ret = IowKit.write(devHandle, 1, wbuf);
//Überprüfen ob alles richtig gesendet wurde
		rbuf = IowKit.read(devHandle, 1, 8);
....

//Auslesen //bytes = Anzahl der Bytes zum Auslesen, adress => Adresse mit gesetztem Bit
		int[] wbuf = { 3, bytes, adress, 0, 0, 0, 0, 0 };
		Long iihh = IowKit.write(devHandle, 1, wbuf);

//In einer While Schleife wird nun eingelesen

		while (remain > 0) {
			sleep(100); // 100ms warten sonst gibts einen Lesefehler
			rbuf = IowKit.read(devHandle, 1, 8);
		...}

//Danach den Dongle "ordentlich" beenden
		int[] cbuf = { 0, 0, 0, 0, 0, 0, 0, 0 };
		IowKit.write(devHandle, 1, cbuf);
		IowKit.closeDevice(devHandle);

Wenn ich das Programm nun einmal ausführe klappt alles, beim Zweiten Mal klappts nicht mehr siehe Bildchen oben.
Der Fehler bei Nr. 4 und 5 bedeutet: I²C Adress has not been acknowledged!

Wenn ich das Gerät aber vom Bus trenne und wieder anschließe geht es wieder einmal!

Haben Sie ein Speicheroszilloskop zur Verfügung um mal nachzusehen wie das Signal auf der Leitung aussieht?

Nein dies nicht, aber beim Tracer kann ich auch eine TimeLine Ansicht auswählen:

Hier die entsprechenden Fehler :

[Christoph Jung]

Wird das Programm oder die Funktion 2 mal nacheinander ausgeführt?
Innerhalb eines laufenden Programmes ist der Auruf von IowKitClose() nicht notwendig. Bei einem erneuten aufruf von IowKitOpen() werden nochmal alle IO-Warrior durchgeheckt, also geschaut ob sie noch da sind und die Liste der IOWs wird in der DLL erneuert.

[unix]

Wird das Programm oder die Funktion 2 mal nacheinander ausgeführt?
Innerhalb eines laufenden Programmes ist der Auruf von IowKitClose() nicht notwendig. Bei einem erneuten aufruf von IowKitOpen() werden nochmal alle IO-Warrior durchgeheckt, also geschaut ob sie noch da sind und die Liste der IOWs wird in der DLL erneuert.

Wenn ich am IowKitClose() nicht aufrufe beendet sich mein Programm nicht!

Obwohl ich zum Schluss

Code: Select all

System.exit(0);

aufrufe, bleibt das Programm aktiv!

Das Problem tritt auf wenn man das Programm mehrmals hintereinander ausführt, sowie wenn man den Code im Programm mehrmals hintereinander ausführt!

[Christoph Jung]

Ich kenne mich mit Java nicht aus, aber gibt es dort nicht eine Funktion, die beim Beenden des Programms immer aufgerufen wird?
Bei C/C++ ist das OnClose() und dort rufe ich immer IowKitCloseDevice() auf, damit die DLL beendet wird. Sowas sollte es auch in Java geben.

[unix]

Ich kenne mich mit Java nicht aus, aber gibt es dort nicht eine Funktion, die beim Beenden des Programms immer aufgerufen wird?
Bei C/C++ ist das OnClose() und dort rufe ich immer IowKitCloseDevice() auf, damit die DLL beendet wird. Sowas sollte es auch in Java geben.

Ja, klar.

Ich rufe ja auch die IowKitCloseDevice() auf bevor ich das Programm schließe!
Nur wenn ich dies nicht tue, läuft das Programm im Hintergrund weiter.

[Guido Körber]

Also die Ausdrucke vom I2C Tracer helfen nicht, da dran kann man nicht sehen wie die Signale wirklich aussehen. Da Sie geschrieben haben, es gab abhängig von der Verkabelung schon unterschiedliches Verhalten, denke ich da könnte es ein rein elektrisches Problem geben.

Wie lang sind denn die Leitungen für den I2C? Mehr als das mitgelieferte Kabel? Das wäre dann eventuell ungesund fürs Signal.

[unix]

Guten Tag,

ich grabe mal wieder meinen alten Thread aus, da ich seit Kurzem wieder an der Problematik arbeite.

Habe jetzt ein Speicheroszilloskop und den Fehler damit aufgezeichnet:



Hier sollen 22 Bytes ausgelesen werden, beim letzten Byte fehlt allerdings der 9. Taktimpuls für das ACK.

Hier mal die komplette Kommunikation vom Auslesen der 22 Bytes:



Der Fehler führt dazu, dass der Mikrocontroller (AVR) sich aufhängt, weil er auf den letzten Takt wartet.
Mit einer anderen I²C Schnittstelle funktioniert die Kommunikation, warum fehlt da der 9. Taktimpuls?
Muss man das vielleicht noch irgendwo konfigurieren?

Mein Aufruf zum Auslesen schaut so aus:

Code: Select all

		
// bytes = 22; adress = 0x3A
IowKit.write(devHandle, 1, new int[] { 3, bytes, (adress << 1) ^ 0x01,
				0, 0, 0, 0, 0 });

Danke :)

[friend-of-rq]

Hallo Unix,

schon mal probiert mit einer anderen Software deine I2C-Devs zu bearbeiten,

ich hätte da ein TestTool für Dich http://www.allinone.greinert-dud.de/,
benutze es selber bei I2C-Bausteinen zum probieren recht gern :-)

Gruss Ralf

[unix]

Hallo Unix,

schon mal probiert mit einer anderen Software deine I2C-Devs zu bearbeiten,

ich hätte da ein TestTool für Dich http://www.allinone.greinert-dud.de/,
benutze es selber bei I2C-Bausteinen zum probieren recht gern :-)

Gruss Ralf

Hey Ralf,

gerade ausprobiert und ich erhalte eine zusätzliche Stopbedingung beim "I²C Bus Durchsuchen".


Und wenn ich den Mikrocontroller auslesen will, bekomme ich ebenfalls das fehlende Stopbit und die letzten Bytes als Nullen zurück:


Der Speicheroszi steht mir leider nicht mehr zur Verfügung, aber ich kann mir gut vorstellen, dass da ebenfalls der ACK bei dem letzten gelesenen Byte 0x6F fehlt.

Edit::

Ok, hab doch ein Bild von einem Speicheroszi bekommen:
Komplette Übertragung über das AllInOne mit fehlendem 9. Takt: