Hi,

On Saturday 21 May 2011, Luca Bertoncello wrote:

Konrad Rosenbaum konrad@silmor.de schrieb:

...

Ich suche eine Hardware, die möglichst frei, problemlos (also C, nicht Assembler) zu programmieren, nicht zu teuer und via USB angebunden ist.

Im Augenblick schwanke ich zwischen Arduino Uno, Maple und der eventuellen Möglichkeit dass es noch was anderes gibt...

Arduino ist fast 'ne Garantie! Ganz einfach zu nutzen, billig und trotzdem mächtig! Ob es reicht, für was du machen willst, ist die Preisfrage...

Genau diese Preisefrage stelle ich mir auch...

...

Ich will mir einen Tastatur- und Maus-emulator via USB basteln. Man kann zwar in X11 Events einschmuggeln, aber auf der Textkonsole, im Framebuffer oder Wayland ist das schon schwieriger - ein per USB angeschlossener Emulator könnte beliebigen Programmen Input unterjubeln.

Hat jemand Erfahrungen wie schwierig sowas ist?

'sticazzi! (eine Übersetzung erfolgt auf Wunsch).

Hmm. Will ich das wissen?

Man sagt mir, daß ich mir schwere Aufgabe für meine Freizeit mir suche, aber du hast auch sowas im Plan...

Ich arbeitet bereits seit ein paar Wochen an der Applikation, die ringsrum existieren soll. Ich mag Herausforderungen...

Also, das ist eine SEHR schwere Sache... Erstmal musst du den USB-Stack als MASTER implementieren. Das kann schon recht aufwändig sein.

Master? Meinst Du Host? Nein, ich will nur ein Gerät bauen.

Standardmäßig haben alle solche EmbeddedGeräte nur die USB-Schnittstelle als SLAVE (viel einfacher!). Danach musst du auch ein Ethernetstack, inklusive TCP/IP, einrichten.

Nö, da kann ich sparen... ;-)

Und noch mit dem Lötkolben basteln, denn Arduino wenigstens, hat keinen Ethernetcontroller! Das bedeutet, eine extra Platine, im besten Fall mit einem ENC28J60, die übliche Kondensatoren, einen Quarz, die RJ45-Büchse und einen SPI-Anschluss bis zum ATMega (Arduino).

Ups. Da habe ich mich unklar ausgedrückt: ich will kein echtes Ethernet bauen. Es gibt eine Spezifikation wie Ethernet-Karten an USB zu funktionieren haben (CDC ECM). Ich will dem PC vorgaukeln, dass ich ein Ethernet wäre, aber darüber Kommandos entgegennehmen.

Gewiss, es gibt schon freie Implementationen von TCP/IP-Stacks (siehe uIP), aber das ganze ist trotzdem gar nicht so einfach.

So sehr will ich nicht übertreiben. Ich werde ausschließlich IPv6 nehmen, das ist etwas einfacher als IPv4. Die Idee ist mit UDP-Paketen zu kommunizieren (spart sehr viel Status und Protokoll) - ich brauche nur zu filtern dass die Pakete an den richtigen Port gehen, die richtige Größe haben und interpretierbaren Inhalt haben. Wenn ich Daten senden will nehme ich einfach einen statischen Header, bastel die Daten hinten dran und berechne eine Standard-IP-CRC (ich muss nochmal nachlesen, eventuell kann ich mir das sogar sparen).

...

Die Idee ist das USB-Gerät drei virtuelle Schnittstellen haben zu lassen: Ethernet (USB CDC ECM), Tastatur (HID Keyboard) und Maus (HID Mouse). Wenn via Ethernet ein Kommando geschickt wird soll es dann via Tastatur oder Maus als Event zurückgesendet werden. Wenn die Tastatur das Kommando bekommt eine LED anzuschalten, kommt das Ereignis übers Netzwerk zurück.

Sagen wir so: wenn du geschafft hast, USB-Master und Ethernet zu basteln, das ist das einfachste... :D

Wie gesagt: ich brauche nur USB-Device und das Ethernet ist virtuell.

...

Ich hatte noch überlegt statt Ethernet, HID plain data oder CDC ACM (serial) zu nehmen. HID plain hat das Problem dass man eine funktionierende USB- Bibliothek, wie libusb braucht, was nur begrenzt portabel ist. CDC ACM ist an sich gleichwertig mit Ethernet, aber für Netzwerk habe ich bereits fertige portable Klassen (Qt).

Naja, HID macht das ganze noch komplexer, denn du musst ZWEI USB-Stacks (und Ports!!) haben: eine als Master (für Tastatur und Mouse) und die andere als Slave (für HID). CDC ACM kenne ich nicht.

Hmm. Noch mehr Misverständnisse. Ich will keine Tastatur an das Device anstöpseln, sondern selbst Tastatur spielen.

Meine Box soll ausschließlich via USB angeschlossen werden und dem PC die drei virtuellen Interfaces vorgaukeln, die ich dann mit etwas simpler Software benutze, um dem PC Tastatur- und Maus-Events unterzujubeln.

Kleines USB-Glossar:

USB Host: ein PC oder Mac oder so, sagt einem Device wann es reden darf. An einer Host Buchse können (via Hub) mehrere Devices stecken. Auf Protokollebene: Master.

USB Device: eine Tastatur, Maus, Modem, Arduino, sonstwas. Ein Gerät kann an exakt einen Hub oder einen PC-Port gestöpselt werden. Auf Protokollebene: Slave. Ein Device kann mehrere Interfaces haben.

Interface: ein virtuelles Gerät am selben physischen Stecker. Die meisten Geräte haben nur ein Interface. Mehrere Interface am selben physischen Gerät dürfen durchaus sehr unterschiedliche Funktionen haben (das typische UMTS- Modem hat ein Mass-Storage, ein Modem und eventuell noch ein paar).

Weitere Ebenen, wie End-Point, Configuration, Descriptor, Report, etc. lasse ich mal weg, weil zu kompliziert.

HID: Human Interface Device. Unter dieser Spec läuft alles was normalerweise benutzt wird, um Eingaben vom Nutzer entgegen zu nehmen. Es gibt mehrere Sub-Specs:

HID Keyboard: Tastatur, kann Tastendrücke senden und den LED-Status empfangen.

HID Mouse: die Maus, ganz ohne Sendung. Sendet in nur einem Report die Bewegung der Maus, gedrückte Tasten, Mausrad, etc. Kann keine Kommandos entgegennehmen.

HID ...: es gibt noch sub-Specs für Joystick, Force Feedback, etc.pp.

HID plain data: Ausnahmespec. Eigentlich keine Spec, aber sehr verbreitet. Das Device sendet und empfängt Daten in kleinen Blöcken (bis zu 8 Byte), die vom Betriebssystem nicht interpretiert werden können. Wird gerne für einfache IO-Bausteine benutzt.

CDC: Communication Device Class. Netzwerkkarten, Modems, ISDN, UMTS, etc.

CDC ACM: Abstract Control Model. Simuliert eine serielle Schnittstelle mit beliebiger Geschwindigkeit. Wurde entwickelt um Modems dahinter zu verstecken. Typisch für UMTS Modems und Geräte, die einfach nur eine serielle Konsole bieten wollen ohne ein echtes serielles Gerät dahinter zu haben.

CDC ATM: Asynchronous Transfer Mode. Nein, keine Telekomglasfasern. Einige ältere DSL- oder Kabel-Modems. Nicht sehr verbreitet.

CDC ISDN: ISDN. Als ob ISDN und USB alleine nicht schon schlimm genug wären...

CDC ECM: Ethernet Control Model. Das Protokoll mit dem man Ethernet-Frames über USB jagen kann. Üblicherweise hat das Kabel an einem Ende einen USB- Stecker am anderen Ende eine RJ-45-Buchse. Das Protokoll erlaubt es Ethernet-Frames zu senden und zu empfangen, verschiedene Eigenschaften der Ethernet-Karte zu setzen und Statusänderungen (z.B. Kabel wurde eingesteckt) zu senden. Soweit ich recherchieren konnte sollten das alle Systeme auch können.

CDC EEM: Ethernet Emulation Model. Vereinfachte Variante. Die Idee ist dass man zwei USB-Stecker (mit einem Chip dazwischen!!) nimmt, sie an zwei PCs ansteckt und dann kommuniziert als wäre es ein Netzwerk. Man spart sich eine Menge Ethernet-Overhead (Settings, Filter, Checksumme, ...). Dummerweise weigert sich Microsoft es zu implementieren - sie bevorzugen etwas namens RNDIS, was wesentlich komplexer und schwerer zu implementieren ist.

Neben HID und CDC gibt es noch ungefähr ein halbes dutzend weitere standardisierte USB-Geräte-Klassen

Konrad

On Saturday 21 May 2011, Fabian Hänsel wrote:

Just als Anregung, falls die Umsetzung in "eigener HW" zu kompliziert wird (beides ungetestet auf Basis wilder Vermutungen):

Eigene HW will ich ja gar nicht nehmen. Nur programmierbare HW.

Selber löten erzeugt bei mir nur kaputte Hardware und Brandblasen an den Fingern. Mit ganz viel Glück schaffe ich es vielleicht die Platine in ein Gehäuse zu schrauben ohne mir selbst ernsthafte Verletzungen zuzufügen... ;-)

(1) modifizierter Kernel-Input-Device-Treiber. Möglicherweise einfacher umzusetzen? (Dann kannst du ganz auf HW verzichten)

Leider keine Option, erstens kann ich nicht überall den Kernel beeinflussen und zweitens soll die Lösung portabel sein.

Die Variante ohne HW ist schon geplant - sie funkioniert aber nur unter X11 (spätere Varianten auch unter Win32 und MacOS/X). Mir ging es darum eine Lösung zu haben wenn Software nicht geht.

(2) Serielle Tastatur. /dev/ttyS0 fühlt sich als Tastatur, ist jedoch direkt mit /dev/ttyS1 verbunden (letzteres ggf. USB-Seriell-Adapter). echo "a" > /dev/ttyS1 lässt die "Tastatur" /dev/ttyS0 ein gedrücktes "a" vermelden.

Was zum Gyps Fulvus ist eine serielle Tastatur(*)? Mir wäre nicht bekannt dass man einem Kernel ein serielles Device als Tastatur unterschieben kann. Man darf das nicht mit seriellen Terminals verwechseln, dass die Daten da drauf entfernt mit Tastatur zusammenhängen ist eher Zufall.

(*)Ja, mir ist bekannt, dass strenggenommen PS/2 ein serielles Protokoll ist. Ich habe aber noch nie ein PS/2-Device als TTY wiedergefunden.

Konrad

On Sunday 22 May 2011, Fabian Hänsel wrote:

...

(*)Ja, mir ist bekannt, dass strenggenommen PS/2 ein serielles Protokoll ist. Ich habe aber noch nie ein PS/2-Device als TTY wiedergefunden.

Möglicherweise könnte man die Idee aber auf anderem Wege noch mit der Realität verheiraten: ein relativ einfach ansprechbares, eigenes USB-Gerät steuert eine gefälschte PS/2-Tastatur am PS/2-Port, deren Protokoll einfacher zu realisieren ist als USB-HID.

Aus Sicht eines Programmierers (zumindest eines P. der andauernd Protokolle baut) ist USB HID nahezu trivial. Zumindest wenn Du schonmal eine Bibliothek für USB hast. Ich habe die letzten paar Monate damit verbracht mich mit einem HID raw Device zu unterhalten (und auf USB zu fluchen).

Die größte Schwierigkeit ist es die HID-Descriptoren zu parsen und zu interpretieren (was nur den Host betrifft). HID Keyboard sendet Reports von 4 bis 8 Byte Länge, das erste Byte enthält die Mofifier Keys (Shift, Ctrl, Meta, ...) als Bitmaske, der Rest die Scancodes der gedrückten Tasten oder binäre Nullen. HID Maus ist nur geringfügig komplexer, weil die Bits auf zwei Koordinaten, 2-4 Buttons und 1-2 Mausräder aufgeteilt werden müssen.

Nachteil Deiner Lösung ist dass es an nahezu keinem Laptop geht und nicht unbedingt hot-plug-fähig ist (PS/2 gibt keine Garantie auf Hot-Plug). Ausserdem: was mache ich wenn ich noch eine echte PS/2 Tastatur anschließen will? Die meisten PCs haben nur einen PS/2-Tastaturanschluss (nein, PS/2 Maus ist ein gänzlich anderes Protokoll, mixen geht nicht).

Das geht dann allerdings nicht ohne etwas Fummelei mit Widerständen, Lötkolben & Co ab.

Ich habe gerade keine Lust auf Brandblasen... ;-P

Ja, mir ist klar dass ich in jedes der drei Protokolle mindestens ein volles Wochenende investieren muss bis es läuft. Bisher ist das alles noch im Ideenstadium und kann sich gewaltig ändern oder ich lasse es eventuell komplett bleiben - meine primäre Implementation wird sowieso eine Software- Lösung mit unterschiedlichen Treibern für X11, Mac und win32.

Konrad

Hi,

danke für den Tip, aber Oyo ist keine Option.

On Sunday 22 May 2011, Heiko Stübner wrote:

Am Samstag 21 Mai 2011, 22:00:09 schrieb Konrad Rosenbaum:

...

Ich suche eine Hardware, die möglichst frei, problemlos (also C, nicht Assembler) zu programmieren, nicht zu teuer und via USB angebunden ist.

falls es deinen Preisrahmen nicht sprengt, wäre ggf. auch ein Oyo eine Möglichkeit. Da sich Thalia mit ihrer Medion-Zusammenarbeit scheinbar mächtig vertan haben, soll es ihn jetzt teilweise auch schon für 75EUR geben.

Laut Wikipedia ist der reguläre Presi 229 Euro, bei buch.de gerade 139.

In ähnlicher Preislage gibt es auch haufenweise ARM-Bastelkits, die weniger Risiko bergen als Oyo. Und Android-Tablets, für die ich schon entwickelt habe.

Der Vorteil wäre, dass auf dem Gerät ein Linux [inkl. nativem Dual-Boot] läuft und du dann die USB-gadget-Schnittstelle des Kernels für dein Input-Device nutzen könntest. Halbwegs aktueller Kernel existiert [1] auch, nur eben noch ohne Unterstützung des Display-Controllers.

Nette weitere Features wären der multitouch-fähige Touchscreen und hoffentlich demnächst auch ein funktionierendes Display.

Alles nicht nötig und vollkommener Overkill für einen Device-Emulator.

Ich hatte unter anderem gehofft ein Gerät zu finden, welches mit USB-Power klarkommt und quasi instan-on funktioniert. Bei Arduino und Maple ist das der Fall - alles mit Screen kann das elektrisch nicht leisten, alles mit vollem Linux drauf braucht mindestens 10s zum booten, Android braucht z.B. auch weitere 20s zum Initialisieren der Oberfläche.

Konrad