Hi, erstmal vorweg, der Beitrag ist leider nicht ganz so schön formuliert wie der "erste"...warum? weil mal wieder Murphy zugeschlagen hat und ich nach erfolgter Vorschau dann doch einen HTTP Fehler beim endgültigen Absenden bekam und der ganze Text futsch war (natürlich habe ich ihn in der Eile nicht wie sonst üblich vor dem Abschicken erstmal ins Clipboard kopiert - war ja klar). Wie dem auch sei, wir haben eine ganze Menge der o.g. etwas betagten Barcodescanner im Einsatz. Diese sind standardmäßg über eine sog. Keyboard Wedge in eine bestehende PS/2 Tastatur eingeschleift. Der Umsetzer betseht im Prinzip nur aus ein paar wenigen passiven SMD Bauteilen und einem einzigen 4066 Schaltkreis. Der Scanner selbst endet in einem 8poligen RJ45 Stecker (voll belegt). Ähnliche Schaltungen (mit 4066) meine ich noch von früher schon als seriell->PS/2 Umsetzer gesehen zu haben, kann das sein? Dafür sprechen würde dann vermutlich auch die Notwendigkeit einer bestehenden Tastatur, da der Scanner selbst keinerlei PS/2 initialisierung etc. vornimmt, der PC aber die gesendeten Daten einfach als ganz normale Zifferneingaben der Tastatur interpretiert. Im Falle von Defekten sind heute aber einfache USB Tastaturen immer gebräuchlicher, außerdem arbeite ich an einem kleinen Hilfsprogramm für den Büroalltag und die Entwicklung findet hauptsächlich auf einem der Notebooks statt die gar keine PS/2 Schnittstelle mehr haben. Aus diesem Grund würde ich mir gerne einen USB Adapter bauen der möglichst direkt und ohne Umwege den Anschluss der Scanner an neueren Notebooks oder PCs ohne bestehende PS/2 Tastatur erlaubt. Wenn ich die Belegung und Protokollinformationen hätte, könnte ich diesen ziemlich sicher problemlos bauen, FT232's (oder USBN9604 falls das Viorhaben damit sinnvoller realisiert werden kann) habe ich noch ein paar, ebenso wie diverse AVRs und das notwendige Equipment und KnowHow. Was mir allerdings fehlt ist die Praxis sowie die dazu verwendeten Hilfsmittel beim Ermitteln solcher Anschlussdaten (z.B. Logic Analyzer). Für jegliche Hilfe, die mich dem Bau eines solchen Adapters weiterbringt, wäre ich sehr dankbar! Gezielte Rückfragen würde ich selbstredend bestmöglich zu beantworten versuchen (solange dazu nicht mehr als ein Multimeter und ein Einfaches 60MHz Oszi notwendig ist). Ciao... PS. Nach 8 Fehlversuchen (HTTP Error 500) gebe ich langsam auf...
Versuchs doch erstmal mit einem Keyboard/Maus/PS2 zu USB-Adapter. Gibts für einige Euronen.
Hallo, die Metrologic Handscanner, die wir benutzen, haben in der Tastaturversion sowohl was gegen USB-Adapter als auch gegen Notebooks. Beim ersten Scannen stürzt der Scanner ab, warum habe ich nicht untersucht, externe 5V-Versorgung des Scanners hat bei mir nicht geholfen. Die eigentlich soweit baugleichen USB-Versionen gehen auch am Notebook ohne Probleme. Diese Scanner werden aber auch allein, also ohne Tastatur, erkannt und gehen am PS/2 ohne Probleme. Gruß aus Berlin Michael
PS/2-USB-Adapter gibt es von mehreren Herstellern. Manche haben mir im Gebrauch auch nicht zugesagt. Da die Dinger ja keine Unsummen kosten, vielleicht ein paar unterschiedliche durchprobieren. Wenn es nur darum geht, die PS/2 Scanner USB-tauglich zu machen, würd ich es erstmal damit versuchen: www.codemercs.com/KeyWarriorE.html
Hi, nun, es geht mir weniger darum das Ding einfach irgendwie zum Laufen zu bekommen als vielmehr darum, einen in der Praxis möglichst einfachen Adapter zu bauen bei dem ich eben NICHT wieder eine PS/2 Tastatur anschliessen muss. Als Bonus wäre das Ding dann auch jederzeit einsteckbar, was mit der Keyboard-Adapter Lösung nur bedingt gut funktioniert. An vielen der PC's die später mal von dem Hilfstool profitieren könnten sitzen nicht zuletzt Leute mit vergleichsweise wenig PC Kenntnissen über ihr Aufgabenfeld hinaus, da würde eine direkte Lösung ebenfalls die Sache wesentlich erleichten. Ideal wäre daher wohl wirklich ein Adapter auf USBN9604 Basis - kein wildes Tastaturumstecken, keine Konfigrationshürden durch das Suchen des passenden COM Ports etc. Sollte es sich beim eigentlichen Anschluss um ein simples serielles Protokoll handeln wäre das auf einfachste Weise machbar. Allerdings möchte ich nicht einfach wild drauf los Basteln um die Funktion der 8 Leitungen zu ermitteln und dabei möglicherweise den Scanner schon im Ansatz killen. Auf jeden Fall wäre eine Lösung auf Basis der meist sowieso nur bedingt kompatiblen USB->PS/2 Adapter nicht interessant. Dennoch Danke für die bisherigen Vorschläge in dieser Richtung. Ciao...
Tja, das wird dann wohl etwas komplizierter. Deine Schaltung muss erstens eine Tastatur bzgl. Initialisierung und Kommandos teilweise emulieren können. Mal als Vorgeschmack: ==================================================================== KEYBOARD COMMANDS (written to port 60h; from Table P0386 of PORTS.A) ==================================================================== EDh nn write LEDs, as above EEh echo, keyboard responds with EEh EFh no-operation (reserved) F0h nn selects scancode set nn=1-3 or 0 to return current set F1h (?) F2h read ID. Keyboard responds with ACK (FAh) and two optional ID bytes: (none) AT keyboard 83h ABh (?) ABh 41h MF2, translation mode ABh 83h MF2, pass-through mode F3h nn set autorepeat rate/delay. nn= b7 unused b6..5 Repeat delay (00=250 msec ... 11=1000msec) b4..0 Repeat rate (00000=30x/sec ... 11111=2x/sec). F4h clears output buffer, enables keyboard F5h default disable: resets keyboard, suspends scanning F6h set default: resets keyboard F7h make all keys typematic (auto-repeat) [*] F8h make all keys make-break [*] F9h make all keys make-only [*] FAh make all keys typematic and make-break [*] FBh nn make one key typematic [*] FCh nn make one key make-break [*] FDh nn make one key make-only [*] [*] these commands may work only for scancode set 3; I'm not sure. FEh resend previous scan code FFh reset keyboard CPU, do power-on self-test, return self-test result byte non-key status bytes -------------------- 00h Key detection error or buffer full. AAh Power-on/reset diagnostics successful. E0h Prefix byte for "gray" keys. E1h Prefix byte ??? EEh Sent in response to ECHO command. F0h Prefix byte for break codes when using scancode sets 2 or 3. FAh ACKknowledge; response to most commands. FCh Diagnostics failed (MF keyboard). FDh Diagnostics failed (AT keyboard). FEh Last command was invalid or had parity error; resend it. FFh Key detection error or buffer full. Wieviel davon nötig ist, muss man wohl ausprobieren. Und zweitens in Richtung USB ein HID realisieren. Da kannst hier ja mal gucken: http://svn.berlios.de/wsvn/usbn2mc/trunk/applications/hidkeyboard/?rev=0&sc=0 oder da: http://www.obdev.at/products/avrusb/hidkeys.html Viel Spass trotzdem :-)
P.S.: Wenn die Sache einen kommerziellen Hintergrund haben sollte, kann ich gern kommerziell helfen :-) Eine e-mail-Adresse wäre aber von Nöten.
Hi, vorweg: die Sache ist nicht wirklich kommerziell, daher wäre das Angebot leider unrentabel denke ich. Danke auch für die kurze Auflistung des PS/2 Emulation, aber das wäre nur meine zweite Wahl. Dazu müßte ich den Keyboard Wedge weiterhin mitverwenden und sozusagen den "Adapter adaptieren" was nur suboptimal wäre. Der Rest wäre dann z.B. nicht viel anders als ein ähnlicher Adapter den ich schon in früheren Jahren mal gebaut habe (PS/2 Tastatur am Amiga betreiben). Wie gesagt, ich vermute stark, dass es sich beim eigentlich verwendeten Protokoll um ein serielles Protokoll handelt und dieses nur durch den Wedge auf ein "PS/2 subset" umgesetzt wird. Es wäre daher wohl am idealsten, bereits das Rohprotokoll am RJ45 direkt abzugreifen und möglichst ohne Umwege umzusetzen. Das eigentliche problem und somit die eigentliche Frage war in erster Linie, ob jemand die Belegung des RJ45 dieses Modells kennt (oder Tipps geben kann wie man diese mit einfachen Mitteln ermitteln kann) und entweder etwas über das protokoll weiss oder auch hier wieder Tipps zu genauen Ermittlung geben kann. Wenn ich mich recht erinnere (und wenn ich nachher noch die Anleitung finde) dann lässt sich der Scanner im übrigen glaube ich auch auf verschiedene Protokolle umstellen. Sollte dies der Fall sein, wäre es vielleicht nur noch die reine Belegung die es herauszufinden gilt. Ich melde mich mit einem Nachtrag, wenn ich die entsprechenden Seiten gefunden habe...
> Wie gesagt, ich vermute stark, dass es sich beim eigentlich > verwendeten Protokoll um ein serielles Protokoll handelt Das ist das Tastaturprotokoll auch, ein synchrones serielles Protokoll. Und das verwendet der Scanner ebenso. > und dieses nur durch den Wedge auf ein "PS/2 subset" umgesetzt wird. Wenn da nur ein '4066 drin steckt, dann ist das ausgeschlossen. Der 4066 ist nur ein vierfacher Analogschalter (http://www.fairchildsemi.com/ds/CD%2FCD4066BC.pdf), damit kann keine Protokollumsetzung durchgeführt werden. Der Scanner liefert schon die richtigen Daten an der Tastaturschnittstelle, er bedarf nur zur "Hilfe" der vorhandenen Tastatur, die nicht nur Kommandos an den PC sendet, sondern eben auch welche von ihm empfängt und auswertet (gerade neuere Rechner testen zyklisch das Vorhandensein einer Tastatur durch ein Testkommando, und verweigern die Arbeit, wenn keine angeschlossen ist, die auf dieses Kommando reagiert). Mal Dir mal einen Schaltplan von diesem Adapterprömpel auf; das Datenblatt des '4066 sollte Dir beim Verständnis helfen.
> Danke auch für die kurze Auflistung des PS/2 Emulation, aber das wäre > nur meine zweite Wahl. Wie rufus auch schrieb, deine Mimik muss zum Teil so tun als wenn sie eine echte Tastatur wäre. Der Scanner klinkt sich nur in Takt und Daten ein, und schiebt das Scanergebnis als Tastatur-Scancodes in den Rechner. Das könnten je nach Scancodeset auch unterschiedliche Scancodes sein. Nachgeguckt hab ich jetzt aber nicht ;-) Durch den 4066 werden wahrscheinlich nur Takt und Daten zwischen echter Tastatur und Scanner gemultiplext. Um den Scanner richtig zu initialieren, kann es sein, dass auch die Initialierungssequenzen die sonst der Rechner sendet, erzeugt werden müssen.
Hi, sorry, ich habe mich wohl einfach zu laienhaft ausgedrückt. Im Prinzip meinte ich auch genau das... der Scanner ist wohl in der Lage, diverse Protokolle zu verwenden. Nur kümmert der sich im Falle von der keyboard Emulation eben nicht um das volle Protokoll das benötigt wird, daher auch das Einschleifen. Dann macht auch das synchronisieren sinn. Allerding shabe ich jetzt auch im Handbuch die Seiten zu den Protokollen gefunden. Je nach Seriennummer ist ein anderes als defaultprotokoll eingestellt. indiesem Fall (Prüfziffer "7") eben Keyboard Wedge. Durchabscannen diverser Codes kann ich wohl jedoch auf andere, unter anderem 2 RS232 Protokolle Wechseln (RS232C und RS232TTL). Um da weiter zu testen wäre wohl nur die Belegung des RJ45 notwendig, ggf. in Verbindung mit ein paar Tipps wie ich sicherstellen kann (sollte), dass ich beim Testen das Gerät trotzdem nicht kille. BTW. Danke auch weiterhin für die Beiträge Eurerseits...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.