Merkwürdiges Verhalten - Rollover?
Moderator: Guido Körber
Merkwürdiges Verhalten - Rollover?
Ich habe hier ja einen Commander mit Typing Makros programmiert.
Jetzt habe ich das unvorhergesehene Verhalten, dass wenn zwei Tasten gleichzeitig gedrückt sind und eine davon losgelassen wird, die erste noch gedrückte Taste ein zweites Mal gesendet wird.
Also z.B.
1 drücken und halten :1
2 dazu drücken und halten:2
2 loslassen: 1
Ich kenne dieses Verhalten eigentlich nur vom Rollover mit sehr vielen gedrückten Tasten. Ist das ein spezielles Verhalten der USB Variante, oder liegt das an den Typing Makros? Normalerweise würde ich davon ausgehen, dass eine losgelassene Taste niemals ein neues Zeichen senden darf, es sei denn eben bei einem Rollover mit vielen Tasten.
- Carsten
Jetzt habe ich das unvorhergesehene Verhalten, dass wenn zwei Tasten gleichzeitig gedrückt sind und eine davon losgelassen wird, die erste noch gedrückte Taste ein zweites Mal gesendet wird.
Also z.B.
1 drücken und halten :1
2 dazu drücken und halten:2
2 loslassen: 1
Ich kenne dieses Verhalten eigentlich nur vom Rollover mit sehr vielen gedrückten Tasten. Ist das ein spezielles Verhalten der USB Variante, oder liegt das an den Typing Makros? Normalerweise würde ich davon ausgehen, dass eine losgelassene Taste niemals ein neues Zeichen senden darf, es sei denn eben bei einem Rollover mit vielen Tasten.
- Carsten
Re: Merkwürdiges Verhalten - Rollover?
Hm, scheint in der Tat mit den typing Makros zusammenzuhängen. Sowohl mit 'normalen' Tastenprogramierungen als auch mit stable Makros passiert das nicht. Glücklicherweise habe ich mir von vorneherein ein paar Backdoors offengehalten. . .
Aber ist dieses Makroverhalten so gewünscht oder lässt sich das nicht ändern?
- Carsten
Aber ist dieses Makroverhalten so gewünscht oder lässt sich das nicht ändern?
- Carsten
Re: Merkwürdiges Verhalten - Rollover?
So, das Projekt ist abgeschlossen und die Hardware funktioniert, mittlerweile auch mit obligatorischem 2-Pin Keramik-Resonator, der auf den letzten Drücker noch von RS kam.
Das Interface dient der Steuerung eines Museumsexponates, es sind insgesamt 44 Reedschalter auf Bedienelementen verteilt. Wegen der Leitungslängen von 2-3 Metern sind alle Schaltkontakte am KeyWarrior über eine Bank von 48 Optokopplern (12*PC847) entkoppelt, das ist zusätzlich auch nötig, weil parallel jeder Schalter noch eine Anzeige-LED betätigt. Dass zusätzlich die recht große Mechanik mit langen Leitungen auch noch galvanisch vom Interface und PC entkoppelt ist, ist ein zusäzliches Plus, ebenso der Umstand, dass die Halbleiterausgänge der Optokoppler automatisch auch Seriendioden zur Vermeidung von Phantom-Keys darstellen. Durch den relativ hohen Schaltstrom für die Optokoppler ist das bei den langen Leitungen auch recht störungssicher.
Wird alles komplett aus dem USB versorgt. Der Stromverbrauch der LEDs und Optokoppler wird zwar nicht USB-konform signalisiert, aber da das Interface an einem eigenen USB-Port hängt und immer unter 200mA bleibt...
Das ganze funktioniert bisher sehr zuverlässig, auch während der Entwicklung gab es keinerlei Irritationen, der KeyWarrior 16 Commander lief auf Anhieb mit der sehr simplen USB-Only Beschaltung, die neben EEPROM und Resonator nur ein paar Pullup Widerstände benötigt, ich habe da einen sehr verdrahtungsarmen Aufbau auf einer Lochrasterplatine gemacht.
War insgesamt zeitlich etwas knapp, zumal ich noch nie vorher mit einem xWarrior Produkt zu tun hatte und ich das Optokoppler Konzept auch nur aus einer spontanen Idee heraus mal mit einem Wald-und-Wiesen Keyboard-Controller ausgetestet hatte.
Interessieren würde mich jetzt aber trotzdem noch, warum der Commander bei Typing Makros und mehreren gedrückten Tasten beim Loslassen einer Taste sämtliche Makros der anderen Tasten nochmal schickt. Eine echte Notwendigkeit dafür sehe ich nicht, für mich ist das ein Bug. Da es hier um komplette KeyOn/KeyOff Sequenzen geht, kann ich mir auch eigentlich nicht vorstellen, dass Windows dafür verantwortlich ist.
In unserer Director Anwendung, die die Bildschirme steuert, ist das glücklicherweise nicht kritisch.
- Carsten
Das Interface dient der Steuerung eines Museumsexponates, es sind insgesamt 44 Reedschalter auf Bedienelementen verteilt. Wegen der Leitungslängen von 2-3 Metern sind alle Schaltkontakte am KeyWarrior über eine Bank von 48 Optokopplern (12*PC847) entkoppelt, das ist zusätzlich auch nötig, weil parallel jeder Schalter noch eine Anzeige-LED betätigt. Dass zusätzlich die recht große Mechanik mit langen Leitungen auch noch galvanisch vom Interface und PC entkoppelt ist, ist ein zusäzliches Plus, ebenso der Umstand, dass die Halbleiterausgänge der Optokoppler automatisch auch Seriendioden zur Vermeidung von Phantom-Keys darstellen. Durch den relativ hohen Schaltstrom für die Optokoppler ist das bei den langen Leitungen auch recht störungssicher.
Wird alles komplett aus dem USB versorgt. Der Stromverbrauch der LEDs und Optokoppler wird zwar nicht USB-konform signalisiert, aber da das Interface an einem eigenen USB-Port hängt und immer unter 200mA bleibt...
Das ganze funktioniert bisher sehr zuverlässig, auch während der Entwicklung gab es keinerlei Irritationen, der KeyWarrior 16 Commander lief auf Anhieb mit der sehr simplen USB-Only Beschaltung, die neben EEPROM und Resonator nur ein paar Pullup Widerstände benötigt, ich habe da einen sehr verdrahtungsarmen Aufbau auf einer Lochrasterplatine gemacht.
War insgesamt zeitlich etwas knapp, zumal ich noch nie vorher mit einem xWarrior Produkt zu tun hatte und ich das Optokoppler Konzept auch nur aus einer spontanen Idee heraus mal mit einem Wald-und-Wiesen Keyboard-Controller ausgetestet hatte.
Interessieren würde mich jetzt aber trotzdem noch, warum der Commander bei Typing Makros und mehreren gedrückten Tasten beim Loslassen einer Taste sämtliche Makros der anderen Tasten nochmal schickt. Eine echte Notwendigkeit dafür sehe ich nicht, für mich ist das ein Bug. Da es hier um komplette KeyOn/KeyOff Sequenzen geht, kann ich mir auch eigentlich nicht vorstellen, dass Windows dafür verantwortlich ist.
In unserer Director Anwendung, die die Bildschirme steuert, ist das glücklicherweise nicht kritisch.
- Carsten
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Merkwürdiges Verhalten - Rollover?
Ich denke das ist eine Randsituation die wir nicht getestet haben, werden wir uns mal ansehen.
Re: Merkwürdiges Verhalten - Rollover?
Und, hattet Ihr schon Zeit, diesbezüglich was zu testen?
Ist ja ganz einfach, nur mal ein typing Makros auf ein paar Tasten programmieren und diese dann mal nacheinander und zusammen drücken, dann sieht man's schon.
- Carsten
Ist ja ganz einfach, nur mal ein typing Makros auf ein paar Tasten programmieren und diese dann mal nacheinander und zusammen drücken, dann sieht man's schon.
- Carsten
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Merkwürdiges Verhalten - Rollover?
Momentan sind wir in München auf der electronica, alles Andere nach der Messe.
Re: Merkwürdiges Verhalten - Rollover?
Wollte die Sache nur nochmal ins Gedächtnis rufen ;-)
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Merkwürdiges Verhalten - Rollover?
Also ich kann dieses Verhalten bestätigen. Das ein Fehler, da es aber bisher noch nie damit Probleme im praktischen Einsatz gab, werden wir das nicht forciert bearbeiten, sondern auf die To-Do Liste setzen.
Re: Merkwürdiges Verhalten - Rollover?
Okay. Sowas wie nachträgliche Firmwareupgrades gibt es für die EEPROM basierenden Chips vermutlich nicht, oder?
- Carsten
- Carsten
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Merkwürdiges Verhalten - Rollover?
Nein, die KeyWarrior Chips sind OTP.
Re: Merkwürdiges Verhalten - Rollover?
Habt Ihr an diesem Bug mittlerweile was getan?
- Carsten
- Carsten
-
- Site Admin
- Posts: 2856
- Joined: Tue Nov 25, 2003 10:25 pm
- Location: Germany/Berlin
- Contact:
Re: Merkwürdiges Verhalten - Rollover?
Nein, ist noch auf der To-Do Liste.