IowRead() - Statusänderung verdoppelt sich

methusalem · Post by **methusalem** » Mon Jan 23, 2006 2:57 pm

OK, ich kann das hier im Moment nicht testen.
Aber so rum wäre es mir lieber! Dann werde ich es selber abfangen und auswerten, bzw dafür sorgen, das die Schalter nicht mehr prellen!

wayoda · Post by **wayoda** » Mon Jan 23, 2006 3:02 pm

Robert Marquardt wrote:Wenn Linux-Treiber oder Linux-Lib bei gleichen Reports einen verwirft, dann ist das ein Bug.

Schade, dann wirds Zeit für einen Kernel-Modul-Update, damit unter Linux auch endlich Kontaktprellen ein Thema wird.
Gibt es eigentlich auch einen guten Grund, warum man sich mit Eingangswerten herumschlagen muss, die ausserhalb der Übertragungsrate des IOWarriors liegen?

Eberhard

Robert Marquardt · Post by **Robert Marquardt** » Mon Jan 23, 2006 3:11 pm

Da gibt es lustige Effekte besonders unter Windows. Man kann naemlich HID-Geraete anweisen immer mal wieder einen Report zu senden.
Der IO-Warrior macht das auch brav ohne das sich etwas an den Pins tut.
Das passiert ueblicherweise nur wenn man einen irregeleiteten Filtertreiber installiert hat der sich auch am IO-Warrior vergreift, aber vorgekommen ist das schon.

methusalem · Post by **methusalem** » Mon Jan 23, 2006 3:17 pm

Robert Marquardt wrote:...
Der IO-Warrior macht das auch brav ohne das sich etwas an den Pins tut.
Das passiert ueblicherweise nur wenn man einen irregeleiteten Filtertreiber installiert hat der sich auch am IO-Warrior vergreift, aber vorgekommen ist das schon.

D.h. mein obiges Phänomen könnte auch soetwas sein? Was für Filtertreiber sind das denn? Wie kann ich die ausfindig machen?

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 3:20 pm

Die Library auf MacOS macht das routinemässig (also das Ausfiltern von identischen Reports). Da das MacOS die IdleTime des IO-Warrior nicht auf 0 setzt wie Windows, wiederholt der IO-Warrior den letzten Report in einem gewissen Intervall. Der Vorteil dabei ist natürlich, dass der Anfangswert beim Starten der Lib ganz leicht zu haben ist.[/i]

wayoda · Post by **wayoda** » Mon Jan 23, 2006 3:23 pm

Guido Körber wrote:Die Library auf MacOS macht das routinemässig (also das Ausfiltern von identischen Reports).

Heißt das jetzt es steht 2:1 für Liunx+MacOS gegen Windows?

Robert Marquardt · Post by **Robert Marquardt** » Mon Jan 23, 2006 3:27 pm

Na dann werde ich das fuer die IowKit V2.0 in die Windows-Version einbauen, statt es aus der Linuxversion auszubauen.
Vermutlich setzt Linux auch die Idle-Time nicht auf 0.

Dabei ergibt sich aber eben das das Hardware-Problem Prellen maskiert wird und durch das Problem ersetzt wird das der IO-Warrior nur noch halb so schnell reagiert.
Das koennte fuer die Fehlersuche bei Anwendungen im Bereich unter 20 msec problematisch sein.

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 3:42 pm

wayoda wrote:Heißt das jetzt es steht 2:1 für Liunx+MacOS gegen Windows?

Mindestens...

Aber das hat nichts mit IO-Warrior zu tun :D

methusalem · Post by **methusalem** » Mon Jan 23, 2006 3:47 pm

Robert Marquardt wrote:...
Dabei ergibt sich aber eben das das Hardware-Problem Prellen maskiert wird und durch das Problem ersetzt wird das der IO-Warrior nur noch halb so schnell reagiert.
Das koennte fuer die Fehlersuche bei Anwendungen im Bereich unter 20 msec problematisch sein.

Ähh, das ist aus meiner Sicht der falsche Weg! Wenn Leute Schalter benutzen, die prellen, dann sollte das nicht durch den IOW gelöst werden, schon garnicht auf Kosten der zeitlichen Auflösung.

Ich finde, das der IOW und die dll in diesem Falle unter Windows völlig korrekt arbeiten. Wenn ein Schalter prellt, dann muss der Schalter eben entprellt werden. Dafür gibts ja nun entsprechende Schalter bzw. Schaltungen.

Ich wäre eher dafür, dieses Verhalten auch unter Linux und Mac OS einzubauen, damit alle drei Plattformen gleich reagieren.

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 3:50 pm

Mindestens bei MacOS Ist das Problem hat, dass ständig Reports ankommen, auch wenn sich nichts ändert.

Das Entprellen hat auf jeden Fall nichts im Chip zu suchen, dafür gibt es die Key Matrix Funktion.

wayoda · Post by **wayoda** » Mon Jan 23, 2006 3:55 pm

Robert Marquardt wrote:Na dann werde ich das fuer die IowKit V2.0 in die Windows-Version einbauen, statt es aus der Linuxversion auszubauen.

Habe gerade noch mal nachgeschaut, ist leider nicht ganz so trivial:
Auch unter Linux gibt es Bedingungen, unter denen das Ausfiltern identischer Reports fehlschlägt:
Die Applikation hat gerade den Puffer Leergelesen und dann kommt ein identischer Report rein. Hier kann Treiber nichts mehr vergleichen und liefert also auch 2 Reports mit gleichen Zuständen. Vielleicht ist die Diskussion ja auch zu akademisch. Programme laufen ja doch meistens nach dem Prinzip:

Code: Select all

if(lastvalue!=newvalue)
   tuwas()

oder

Code: Select all

if(newvalue==0x??)
   tuwas()

Robert Marquardt wrote: Vermutlich setzt Linux auch die Idle-Time nicht auf 0.

Doch Idle_time ist 0

Robert Marquardt wrote: Dabei ergibt sich aber eben das das Hardware-Problem Prellen maskiert wird und durch das Problem ersetzt wird das der IO-Warrior nur noch halb so schnell reagiert.
Das koennte fuer die Fehlersuche bei Anwendungen im Bereich unter 20 msec problematisch sein.

Verstehe ich nicht. Änderungen an den Pins, die länger als 10 (bzw.8) Millisekunden anstehen, führen zu einem neuen Report mit dem geänderten Status.

Robert Marquardt · Post by **Robert Marquardt** » Mon Jan 23, 2006 3:58 pm

Wir haben uns gerade intern darauf geeinigt das alles so bleibt wie es ist.

Fuer Linux und MacOS muss man gleiche Reports ausfiltern, da dort die Idle Time des USB offensichtlich standardmaessig nicht auf 0 steht. Der IO-Warrior stoesst also in regelmaessigen Intervallen gleiche Reports aus. Da das API aber nur Reports bei Aenderungen ausweist, muss man halt ausfiltern.

Bei Windows werden Reports in der Standardeinstellung des OS nicht wiederholt. Das maskieren ist also nicht noetig und unterbleibt daher.
Beknackte Treiber sind unwahrscheinlicher als Hardwareprobleme wie prellende Schalter.

Es koennte sich aber eine interne Aenderung bei Linux ergeben, da das Ausfiltern eigentlich nichts im Treiber zu suchen hat. Es gehoert logisch in die iowkit Library.
Solange dies aber keine Probleme ergibt, bleibt es erst mal wie es ist.
Das wird erst relevant wenn wir den Treiber zur Aufnahme in den Kernel einreichen und das wird noch ein bischen dauern.

wayoda · Post by **wayoda** » Mon Jan 23, 2006 4:01 pm

Guido Körber wrote:Mindestens bei MacOS Ist das Problem hat, dass ständig Reports ankommen, auch wenn sich nichts ändert.

SetIdleTimeout ist doch ein Standart HID-Request .
Auch MacOs sollte in der Lage sein die IdleTime einzustellen.

Guido Körber · Post by **Guido Körber** » Mon Jan 23, 2006 4:03 pm

Ist es ja auch. Nur halt genau der gleiche Zustand wie unter Windows: Ohne eigenen Treiber kommt man nicht an alles ran. Und während Windows von alleine die IdleTime auf 0 setzt (was meiner Meinung nach dumm ist) macht MacOS das nicht.

Robert Marquardt · Post by **Robert Marquardt** » Mon Jan 23, 2006 4:08 pm

wayoda wrote: Doch Idle_time ist 0

Ich habe den Treiber nicht geschrieben und vermute nur anhand des Vorhandenseins dieses Filters das die idle_time nicht 0 ist.
Ich werde mal den Treiber ohne Filter implementieren und sehen was passiert. Wenn es weggelassen werden kann, dann wird es natuerlich auch entfernt, denn das erlaubt die Erkennung des Hardwareproblems prellen.

wayoda wrote: Verstehe ich nicht. Änderungen an den Pins, die länger als 10 (bzw.8) Millisekunden anstehen, führen zu einem neuen Report mit dem geänderten Status.

Ich dachte an eine Anwendung die oefter als alle 20 msec eine Aenderung verursacht und Prellen hat. Diese wuerde nur alle 20 msec einen Report produzieren, da der Prellreport weggefiltert wird.
Der User wuerde vermuten das der IO-Warrior nicht 100 Reports pro Sekunde bringt, da ja seine Schaltung in Ordnung ist (das glauben die User immer).