Internen Puffer abschalten

Petrusilius · Post by **Petrusilius** » Wed Dec 13, 2006 1:38 pm

Hallo
ich will mit dem IOWarrior die Gleiskontakte einer Modeleisenbahn abfragen. Die Logik der Eisenbahnplatine verlangt:

Schreibe der Platine welchen Gleiskontakt man Lesen will und setze Bit für AntwortPort. Lies Antwort. Das Problem ist eine starke Verzögerung auf Grund des internen Puffers des IOWarriors (bis zu 1sec). Gibt es eine Möglichkeit den Puffer abzuschalten?

mfg michael

Guido Körber · Post by **Guido Körber** » Wed Dec 13, 2006 1:56 pm

Also zum Lesen würde ich erst mal die Dokumentation der DLL empfehlen...

Die DLL puffert die letzten Reports vom IO-Warrior bis diese gelesen werden (oder der Buffer überläuft). Wenn man also mehrere Statusänderungen am IO-Warrior hat und dann nur einen Report aus dem Buffer liest bekommt man nicht den aktuellen Zustand, sondern die erste Änderung seit dem letzten Lesen.

zorstn · Post by **zorstn** » Fri Jun 22, 2007 3:01 am

hallo,

habe dazu mal eine frage:
wie schnell liest der warrior eigentlich die eingänge?
verstehe ich es also richtig, dass wenn ich 32 eingänge habe und alle kurz nacheinander geschaltet werden 32 verschiedene reports geschrieben werden? und da ich nur den letzten auslesen kann sind die anderen 31 eingänge schon wieder verloren oder wie?

Guido Körber · Post by **Guido Körber** » Fri Jun 22, 2007 7:43 am

Gelesen wird jede Millisekunde, gesendet werden kann aber nur im Takt der Abfragen vom Host, also beim IOW40 alle 8msec. Änderungen dazwischen gehen verlosren.

zorstn · Post by **zorstn** » Fri Jun 22, 2007 1:11 pm

das heisst also, wenn innerhalb der 8ms ein taster ein signal setzt, was kürzer als diese zeit ist, wird es nicht erkannt, da der zustand "schalter offen" mittlerweile wieder eingelesen ist?

verstehe ich es richtig, dass die dll automatisch alle 8ms die eingänge liest?
wann werden die writebefehle geschrieben? welche zeit benötigt das? verlangsamen die das ganze dadurch?

Robert Marquardt · Post by **Robert Marquardt** » Fri Jun 22, 2007 1:34 pm

Der USB fragt in Hardware alle 8 Millisekunden das Geraet ob es neue Daten hat. Wenn ja, dann ruft das Betriebssystem die daten ab und speichert sie in einer Warteschlange ab. Aus dieser Warteschlange liest die DLL permanent in einem eigenen Thread die Daten aus und stellt sie seinerseits in eine Warteschlange innerhalb der DLL. Aus dieser Warteschlange bedienen sich IowKitRead bzw. IowKitReadNonBlocking. Der Unterschied besteht darin das wenn die Warteschlange leer ist IowKitRead wartet bis Daten eintreffen, waehrend IowKitReadNonBlocking nicht wartet. Die Warteschlange ist 128 Elemente lang und daher ist sichergestellt das ca. 1 Sekunde lang Daten gepuffert werden. Treffen bei voller Warteschlange weitere Daten ein so wird der aelteste Report verworfen.

Ein beliebter Fehler ist
IowKitWrite
IowKitReadNonBlocking
fuer einen Special Mode Befehl.
Das versagt, da das IowKitReadNonBlocking ausgefuehrt wird, bevor der IOWarrior Zeit hatte die Antwort zu senden.

Performanceprobleme gibt es dabei nicht. Die Write-Befehle stoeren das Ganze nicht. Das regelt der USB schon.

Man kann sich nur darauf verlassen das man eine Pin-Aenderung pro 8 msec mitbekommt. Schnellere Aenderungen koennen verlorengehen.

zorstn · Post by **zorstn** » Fri Jun 22, 2007 2:01 pm

okay, nun ist mir das ganze schon etwas klarer.

beim iow56 ist die zeit ja 1ms. somit kann ich damit ja genauer arbeiten. ist die warteschlange denn trotzdem nur 128reports lang? das würde ja heissen, dass meine software nur noch 128ms zeit hat, damit keine daten verlorengehen.

Robert Marquardt · Post by **Robert Marquardt** » Fri Jun 22, 2007 2:09 pm

Ja, die Schlange ist nur 128 Elemente lang. 128 Millisekunden ist aber viel Zeit. Man muss ja nur einmal pro 128 Millisekunden die Schlange leerlesen. Genau dafuer ist IowKitReadNonBlocking da. Wenn die Funktion FALSE liefert dann ist die Schlange leer.

zorstn · Post by **zorstn** » Fri Jun 22, 2007 2:12 pm

sind 128ms wirklich so viel zeit, wenn windows meint mal hängen zu müssen? :) ich werds erleben.

zorstn · Post by **zorstn** » Fri Jun 22, 2007 9:09 pm

nun habe ich doch nochmal abschließend eine fraeg zu dem puffer.
mit den funktionen lese ich den kompletten puffer aus und jeder report entspricht allen 32 pins. welcher von diesen reports wird denn nun überbhaupt ergeben? ich erhalte doch mit dem readbefehl nur einen report zurück, oder sehe ich das falsch?

Robert Marquardt · Post by **Robert Marquardt** » Sat Jun 23, 2007 5:49 am

Es ist eine Warteschlange. First in first out. Der aelteste Report kommt zuerst.

zorstn · Post by **zorstn** » Mon Jul 02, 2007 3:36 am

Hab nochmal 'ne Frage zum IOW40:

Ist es richtig, dass ein Eingangssignal mindestens 8ms anliegen muss, damit es auch erkannt wird, da die DLL ja erst dann nachfragt?

Guido Körber · Post by **Guido Körber** » Mon Jul 02, 2007 3:59 am

Nein, das ist eine falsche Interpretation. Das Signal muss >1ms anliegen um sicher detektiert zu werden. Es dürfen nicht zu viele Änderungen aufeinander folgen, da nur alle 8ms ein Report geschickt werden kann. Da der IO-Warrior aber einen Report plus den aktuellen Zustand intern halten kann können auch kürzere Signale als 8ms sicher erkannt werden, aber nur wenn nicht zwei Ereignisse in dieser Zeit passieren.

zorstn · Post by **zorstn** » Mon Jul 02, 2007 1:25 pm

Okay Danke.

Habe nämlich noch ungelöstes Problem. Wenn ich nur sehr sehr kurz schalte flattert mein zugewiesener Ausgang (simuliertes Stromstoßrelais) immer hin und her. Wenn ich mir die Eingänge jedoch anschaue wird er nur einmal gesetzt, also eigentlich alles richtig. Kann das was mit dem Warrior zu tun haben, oder eher ein Softwareproblem? Nehme eine positive Flankenauswertung vor, vermutlich ist das noch nicht ganz sauber.

Nachtrag: Eine Analyse hat gezeigt, dass die Funktion, die den Ausgang setzt, bzw zurücksetzt nur einmal aufgerufen wird, trotzdem der Ausgang immer flattert.. seltsam.

Ah, Fehler glaube ich gefunden. IOW bekommt abfallen des Schalters bevor mein Programm es geschafft hat, den Ausgang zu setzen.., sehr seltsam. Muss ich mal meinen code ändern.

Guido Körber · Post by **Guido Körber** » Mon Jul 02, 2007 8:26 pm

Hört sich so an als wenn die umgebende Hardware ein Problem sein könnte?