Hallo Forum!
Ich habe hier Merkwürdigkeiten mit dem IOW56, die ich mir zum verrecken nicht erklären kann. Zunächst zum Programmablauf: es werden mehrfach abwechselnd daten auf I2C geschrieben und empfangen, dann wird mal der eine, mal der andere Port auf den einen oder anderen Wert gesetzt, dann wieder von vorn. Nachdem das eine Zeit lang prima läuft, passiert einer der folgenden Fehler:
1. IowKitRead() bricht mit Timeout ab, ein sofort hinterhergeschobenes IowKitRead() bekommt den erwarteten Report dann doch. Dabei ist es egal, wie lang oder kurz das Timeout gesetzt ist.
(Das passiert genauso auch mit SPI im anderen Prg).
Oder
2. IowKitRead() bekommt einen verhunzten Report. Es werden per IowKitWrite() 1 oder 16 Bytes vom I2C angefordert (Spec.Rep.ID 3) aber IowKitRead() liefert darauf hin einen Report zwar mit den erwarteten und korrekten 1 oder 16 Bytes als Antwort zurück aber mit ID 2 (I2C-Senden)...
I2C-Senden tue ich aber immer nur 3 Bytes (incl. Dev-Adr) und zwar ohne Fehler und auch mit korrektem antwort-Report.
Was auch vorkommt sind die I2C-Fehler: kein Byte empfangen oder keins gesendet. Mag ja sein das es da ein Problem auf dem I2C selber gibt (obwohl die Flanken und Pegel gut aussehen und auch die Taktrate keinen merklichen Einfluß auf die Häufigkeit aller Fehler hat). Nur lassen sich die ersten 2 Fehler denn auch damit erklären? Ausserdem: wenn die Werte ankommen, sind sie auch immer korrekt; so von wegen Bitfehler...
Weiterhin habe ich ein Problem beim bedienen mehrerer IOWs: Je IOW wird ein Thread gestartet. Wenn ich auf dem einen loslege, geht auf dem anderen Thread nix mehr zuverlässig. IowKitWrite() kehrt meist mit 0 zurück, IowKitRead() auch. Dann kommt es zu Verschiebungen in den erwarteten Antwort-Reports, als ob ein IowKitWrite() trotz Rückgabe 0 einen Antwort-Report auslöst (den ich dann natürlich nicht abfange)...
Hat jemand Ideen dazu?
Noch ein paar Infos:
- Die bedienten Ports überschneiden sich nicht mit I2C oder SPI
- Vor jedem IowKitRead() wird der Report-Buffer ausgenullt.
- Es passier nach dem Programmstart mal der eine mal der andere Fehler zuerst.
- Es ist weder eine Reihenfolge, noch eine zeitliche Abhängigkeit zu erkennen. Völlig unregelmäßig.
- Tante Edith sagt noch: Wenn ein Fehler auftrat, läuft das Prg danach ganz normal weiter, bis nach etwa einigen 100 korrekten Writes und Reads das nächste mal einer der beschriebenen Fehler auftritt.
- Noch ein Edit: Habe gerade noch eine IowKitReadNonBlocking()-Schleife statt IowKitRead() probiert: Fehler 1 kann folglich nicht mehr auftreten, aber der Rest kommt immernoch lustich...
- Es wird nur einmal IowKitOpenDevice() gemacht und jeder Thread bekommt dann ein Device-Handle, über die er das IowKit anspricht.
Der Code ist inzwischen ziemlich länglich. Bei bedarf könnte ich auszüge schicken.
Viele Grüße und Dank
Benjamin
Bekomme verspätete oder inkorr. Reports / 2 IOWs gehen nicht
Moderator: Guido Körber
-
Christoph Jung
- Posts: 673
- Joined: Sun Oct 08, 2006 3:43 pm
- Location: Germany / Berlin
- Contact:
Hallo,
Vorab ein paar Fragen:
Welches Betriebssystem?
Welche Programmiersprache?
Laufen noch andere Rechenintensiven Anwendungen im Hintergrund?
Ist ein Hub zwischen Rechner und IOWarrior (und ist es ein eher preisgünstiger Hub)?
Wie lang ist das USB-Kabel
Wie lange ist das Timeout denn eingestellt?
Da Windows kein Echtzeitsystem ist werden die einzelnen Programme Priorisiert. Wenn was dazwischenkommt, dann kann es schonmal länger dauern. In welchem Intervall werden denn die Lese/Schreib-Vorgänge durchgeführt? Vllt. ist es alles einfach zu schnell.
Zum I2C kann ich leider nicht so viel sagen. Da müsste jemand mit mehr Hardware-Verständnis mal eine Aussage machen.
Zu den Threads? Wie sind die denn aufgebaut?
Greifen die Threads evtl. auf die selben Variablen zu? Das kann zu überschneidungen und vor allem Fehlern führe.
Wie werden denn die Handles geholt? (am besten Codeausschnitt)
Vorab ein paar Fragen:
Welches Betriebssystem?
Welche Programmiersprache?
Laufen noch andere Rechenintensiven Anwendungen im Hintergrund?
Ist ein Hub zwischen Rechner und IOWarrior (und ist es ein eher preisgünstiger Hub)?
Wie lang ist das USB-Kabel
Wie lange ist das Timeout denn eingestellt?
Da Windows kein Echtzeitsystem ist werden die einzelnen Programme Priorisiert. Wenn was dazwischenkommt, dann kann es schonmal länger dauern. In welchem Intervall werden denn die Lese/Schreib-Vorgänge durchgeführt? Vllt. ist es alles einfach zu schnell.
Zum I2C kann ich leider nicht so viel sagen. Da müsste jemand mit mehr Hardware-Verständnis mal eine Aussage machen.
Zu den Threads? Wie sind die denn aufgebaut?
Greifen die Threads evtl. auf die selben Variablen zu? Das kann zu überschneidungen und vor allem Fehlern führe.
Wie werden denn die Handles geholt? (am besten Codeausschnitt)
Software developer
Moin moin!
Welches Betriebssystem?
XP MCE SP2
Welche Programmiersprache?
Boland Develloper Studio 2006 / C++ / VCL
Laufen noch andere Rechenintensiven Anwendungen im Hintergrund?
Nö. Ist auch egal, ob Debug-Version mit Debugger mit und ohne Einzelschritt oder Release-Version. Immer das gleiche Verhalten.
Ist ein Hub zwischen Rechner und IOWarrior (und ist es ein eher preisgünstiger Hub)?
Hama 7-Port, 15€, Aktiv. Es sind weitere Geräte angeschlossen, da werde ich noch mal einige Versuche machen. Gute Idee!
Wie lang ist das USB-Kabel
Je (Hub und IOW) ca. 1m
Wie lange ist das Timeout denn eingestellt?
Wurst. Gleiches Verhalten mit 100, 250, 1000, 3000 ms. Der Versuch mit IowKitReadNonBlocking() hat auch immer normale Reaktionszeiten ergeben, keine auffälligen Verzögerungen.
In welchem Intervall werden denn die Lese/Schreib-Vorgänge durchgeführt? Vllt. ist es alles einfach zu schnell.
Hmmm. Da ich vor jeder weiteren Aktion ja den Antwort-Report abwarte, dürfte da eigentlich nix untergehen.
Greifen die Threads evtl. auf die selben Variablen zu?
Eiiiigentlich nicht. Ich achte da schon drauf! Aber manchmal verstecken sich die Seiteneffekte ja sehr gut vor einem... :) Die einzige gemeinsame Variable ist der Instance-Counter der Thread-Klasse, der per InterlockedIncrement() / -Decrement() bedient wird.
Zu den Threads? Wie sind die denn aufgebaut?
Wie werden denn die Handles geholt? (am besten Codeausschnitt)
Codeausschnitt geht gerade nicht. Bin frühestens Mo wieder bei der Arbeit (grippaler Infekt). Ich versuche es mal ausm Kopf:
Die Threads sind mit einer TThread-Klasse (VCL) implementiert. Der erste Thread, der startete, macht IowKitOpenDevice(), der letzte, der endet, IowKitCloseDevice(). Dazwischen werden IowKitXyz() nach belieben und ohne Synchronisierung benutzt, aber jeder Thread nur für seinen zugewiesenen IOW.
Das Hauptprogramm ermittelt in einer Schleife die Seriennummern aller angeschlossenen IOWs. Um diese Schleife herum sind IowKitOpenDevice() und IowKitCloseDevice() gesetzt. Jeder Thread bekommt dann beim Start eine IOW-Seriennummer mit. Der Thread selbst macht zu Beginn auch eine solche Schleife bis die übergebene Seriennummer gefunden wurde. Dann wird per IowKitGetDeviceHandle(n) das Handle geholt und lokal gespeichert.
Es geht hier konkret um eine Testprozedur für eine bestückte Platine. Der Thread beginnt mit einer Erkennung, ob eine Platine ans Prüfgerät angeschlossen wurde: 3 Ports nacheinander Schalten, dann einen I2C-AD-Wandler konfigurieren und abfragen, dann die Port wieder zurückschalten, 2 s Pause, und wieder von vorne.
Bis dahin funktioniert mit 2 Prüfgeräten (also 2 IOWs) alles Prima, nur wenn der Testablauf losgeht, also die Häufigkeit der Zugriffe deutlich steigt hakts aus. Es sind auch beide Prüfgeräte an den HUB angeschlossen.
Vielen Dank schonmal für die Mühe und
viele Grüße
Benjamin
Welches Betriebssystem?
XP MCE SP2
Welche Programmiersprache?
Boland Develloper Studio 2006 / C++ / VCL
Laufen noch andere Rechenintensiven Anwendungen im Hintergrund?
Nö. Ist auch egal, ob Debug-Version mit Debugger mit und ohne Einzelschritt oder Release-Version. Immer das gleiche Verhalten.
Ist ein Hub zwischen Rechner und IOWarrior (und ist es ein eher preisgünstiger Hub)?
Hama 7-Port, 15€, Aktiv. Es sind weitere Geräte angeschlossen, da werde ich noch mal einige Versuche machen. Gute Idee!
Wie lang ist das USB-Kabel
Je (Hub und IOW) ca. 1m
Wie lange ist das Timeout denn eingestellt?
Wurst. Gleiches Verhalten mit 100, 250, 1000, 3000 ms. Der Versuch mit IowKitReadNonBlocking() hat auch immer normale Reaktionszeiten ergeben, keine auffälligen Verzögerungen.
In welchem Intervall werden denn die Lese/Schreib-Vorgänge durchgeführt? Vllt. ist es alles einfach zu schnell.
Hmmm. Da ich vor jeder weiteren Aktion ja den Antwort-Report abwarte, dürfte da eigentlich nix untergehen.
Greifen die Threads evtl. auf die selben Variablen zu?
Eiiiigentlich nicht. Ich achte da schon drauf! Aber manchmal verstecken sich die Seiteneffekte ja sehr gut vor einem... :) Die einzige gemeinsame Variable ist der Instance-Counter der Thread-Klasse, der per InterlockedIncrement() / -Decrement() bedient wird.
Zu den Threads? Wie sind die denn aufgebaut?
Wie werden denn die Handles geholt? (am besten Codeausschnitt)
Codeausschnitt geht gerade nicht. Bin frühestens Mo wieder bei der Arbeit (grippaler Infekt). Ich versuche es mal ausm Kopf:
Die Threads sind mit einer TThread-Klasse (VCL) implementiert. Der erste Thread, der startete, macht IowKitOpenDevice(), der letzte, der endet, IowKitCloseDevice(). Dazwischen werden IowKitXyz() nach belieben und ohne Synchronisierung benutzt, aber jeder Thread nur für seinen zugewiesenen IOW.
Das Hauptprogramm ermittelt in einer Schleife die Seriennummern aller angeschlossenen IOWs. Um diese Schleife herum sind IowKitOpenDevice() und IowKitCloseDevice() gesetzt. Jeder Thread bekommt dann beim Start eine IOW-Seriennummer mit. Der Thread selbst macht zu Beginn auch eine solche Schleife bis die übergebene Seriennummer gefunden wurde. Dann wird per IowKitGetDeviceHandle(n) das Handle geholt und lokal gespeichert.
Es geht hier konkret um eine Testprozedur für eine bestückte Platine. Der Thread beginnt mit einer Erkennung, ob eine Platine ans Prüfgerät angeschlossen wurde: 3 Ports nacheinander Schalten, dann einen I2C-AD-Wandler konfigurieren und abfragen, dann die Port wieder zurückschalten, 2 s Pause, und wieder von vorne.
Bis dahin funktioniert mit 2 Prüfgeräten (also 2 IOWs) alles Prima, nur wenn der Testablauf losgeht, also die Häufigkeit der Zugriffe deutlich steigt hakts aus. Es sind auch beide Prüfgeräte an den HUB angeschlossen.
Vielen Dank schonmal für die Mühe und
viele Grüße
Benjamin
Hallo,
da gibt es ein Problem mit dem IOW56 wenn er an einem UHCI-Usb Host Controller betrieben wird.
Der Fehler wurde in diesem Thread
http://www.codemercs.de/phpBB2/viewtopi ... c&start=30
endeckt und äußert sich darin, dass der IOW56 nach einigen 100 oder auch mal 1000 Reports auf der SpecialMode-Pipe blockiert. Und zwar nur dann, wenn er (sozusagen Full-Speed) in einer Schleife Schreiben/Lesen muß. Wenn der Code also etwa so aussieht :
und der IOW56 an einem USB UHCI-Host-Controler steckt.
An einem OHCI-Controller tritt das Problem nicht auf, sollte also ggf. mit einem anderen Rechner leicht nachprüfbar sein.
Die hier beschriebenen Sympthome passen wohl nicht ganz, könnte aber vieleicht an den Threads liegen?
Eberhard
da gibt es ein Problem mit dem IOW56 wenn er an einem UHCI-Usb Host Controller betrieben wird.
Der Fehler wurde in diesem Thread
http://www.codemercs.de/phpBB2/viewtopi ... c&start=30
endeckt und äußert sich darin, dass der IOW56 nach einigen 100 oder auch mal 1000 Reports auf der SpecialMode-Pipe blockiert. Und zwar nur dann, wenn er (sozusagen Full-Speed) in einer Schleife Schreiben/Lesen muß. Wenn der Code also etwa so aussieht :
Code: Select all
While(true) {
IowKitWrite();
IowKitRead();
}
An einem OHCI-Controller tritt das Problem nicht auf, sollte also ggf. mit einem anderen Rechner leicht nachprüfbar sein.
Die hier beschriebenen Sympthome passen wohl nicht ganz, könnte aber vieleicht an den Threads liegen?
Eberhard
Hallo Eberhard!
Cool, auf den (Forums-)Thread bin ich noch nicht gestoßen. Das könnte zumindest mein erstes Phänomen erklären. Ich glaube mein Arbeitsrechner hat UHCIs. Bei mir wars allerdings, dank Timeout, keine endgültige Blockierung und es gehen bei mir auch keine Reports verloren.
Dann habe ich ja schonmal noch 2 heiße Spuren, die ich allerdins frühestens Donnerstag probieren kann (immernoch krank). Wenn ich da noch was rausfinde poste ich das hier auf jeden Fall noch!
Vielen Dank schonmal und viele Grüße
Benjamin
Cool, auf den (Forums-)Thread bin ich noch nicht gestoßen. Das könnte zumindest mein erstes Phänomen erklären. Ich glaube mein Arbeitsrechner hat UHCIs. Bei mir wars allerdings, dank Timeout, keine endgültige Blockierung und es gehen bei mir auch keine Reports verloren.
Dann habe ich ja schonmal noch 2 heiße Spuren, die ich allerdins frühestens Donnerstag probieren kann (immernoch krank). Wenn ich da noch was rausfinde poste ich das hier auf jeden Fall noch!
Vielen Dank schonmal und viele Grüße
Benjamin