RUWIDO Merlin IR-USB-HID-keyboard

[alibenpeng]

Hallo Forum,

nach langer Suche, die immer nur halb funktionierende Ergebnisse brachte, habe ich jetzt die Arbeit von Guenter Bartsch [1] und dem V-USB-Projekt [2] kombiniert, und einen USB-HID-Receiver [3] gebaut, mit dem man das Keyboard [4] ohne weitere Treiber als (fast) normales HID-Keyboard benutzen kann.

Der Code läuft mindestens auf ATMega8 (also z.B. dem USBASP [5]) und der ATMega*8-Familie (Arduino und Verwandte), mit 12 oder 16MHz. Außerdem braucht man nur noch einen IR-Empfänger mit 56kHz [6], Schaltplan und nähere Beschreibung gibts hier [7].


Gruß,

Ali

[1]: https://sites.google.com/site/guenterbar...arddecoder
[2]: http://www.obdev.at/products/vusb/index.html
[3]: https://github.com/alibenpeng/ruwido_hidusb
[4]: http://www.pollin.de/shop/dt/MjQ5ODgyOTk...ERLIN.html
[5]: http://www.ebay.com/itm/1PCS-USBasp-USBI...3cc61e7aab
[6]: http://www.reichelt.de/Fotodioden-etc-/T...018c18bf93
[7]: http://testblog.arles-electrique.de/2012...eiver.html

[Martin]

Wow, das als ersten Beitrag in einem Forum. Danke!

(Grübel, ... warum hab ich zwei USB-ASP in der Schublade ? Leider mit verschiedenen Firmware Versionen, was solls. Einer muss zum flashen reichen.  8))

[alibenpeng]

Naja, ich hab ja gesehen, dass das Thema hier schon rauf und runter diskutiert wurde und dachte mir, hier kann das sicher jemand gebrauchen.

[Wirbel]

Sehr schön. Das passt gut zu dem Projekt was ich gerade andenke..


So als Kommentar: Die Schaltung in [6] hat drei derbe Fehler.

a) C5 ist wenigstens um den Faktor 500 zu klein, und sollte 47nF..200nF sein.
b) C6 dito
c) R5 sollte ganz sicher nicht 1Megaohm sein, sondern doch eher 47ohm..220ohm

C2 und C3 sind abh. vom Quarz.

Wer nen USBasp verwendet, hat korrekte Werte, das funzt also.

[alibenpeng]

[...]
a) C5 ist wenigstens um den Faktor 500 zu klein, und sollte 47nF..200nF sein.
b) C6 dito
c) R5 sollte ganz sicher nicht 1Megaohm sein, sondern doch eher 47ohm..220ohm

C2 und C3 sind abh. vom Quarz.

Wer nen USBasp verwendet, hat korrekte Werte, das funzt also.

Stimmt natürlich! Den Schaltplan hab ich auch im Halbschlaf zusammengepfuscht,.

a, b) C5 und 6 sind selbstverständlich 100n, nicht 100p.
c) Stimmt auch. Da habe ich einfach R3 kopiert und den Wert nicht angepasst.
Die 22p für den Quarz sind optimal für den 16MHz, laufen aber auch mit 12MHz.

Ich hab das jetzt mal korrigiert, bevor sich noch jemand in die Luft sprengt.

[Martin]

Für nen USBasp wäre dann folgendes einzustellen ?

#usbconfig.h
define USB_CFG_DPLUS_BIT      3
define USB_CFG_CLOCK_KHZ  12000

[Wirbel]

#define USB_CFG_IOPORTNAME      B
#define USB_CFG_DMINUS_BIT      0
#define USB_CFG_DPLUS_BIT      1
#define USB_CFG_CLOCK_KHZ 12000

[alibenpeng]

Für nen USBasp wäre dann folgendes einzustellen ?

#usbconfig.h
define USB_CFG_DPLUS_BIT      3
define USB_CFG_CLOCK_KHZ  12000

Das kommt auf die Belegung an. Ich habe verschiedene Schaltungen für den USBASP gesehen. Wichtig sind vor allem der Port und das Bit. Für den hier wären das Port B und Bits 0 und 1. Wichtig ist, dass Pin 3 des USB-Steckers zusätzlich noch mit INT0 (PD2) verbunden ist. Der Ausgang vom TSOP muss dann an PD3, was an dem TQFP-Package etwas fummelig zu löten ist.

Die Taktrate solltest Du im Makefile einstellen, lieber nicht das USB_CFG_CLOCK_KHZ in der usbconf.h anfassen!

[Wirbel]

Die header Datei ist genau dafür da.

[alibenpeng]

Die header Datei ist genau dafür da.

Nicht um die CPU-Frequenz einzustellen. Die wird ja an mehreren Stellen gebraucht, deshalb sollte immer nur F_CPU im Makefile geändert werden.

[Wirbel]

Das schon, aber du wirst beide ändern müssen.

[alibenpeng]

Das schon, aber du wirst beide ändern müssen.

Eben nicht, dafür ist doch F_CPU als Variable in der usbconfig.h:

#define USB_CFG_CLOCK_KHZ      (F_CPU/1000)

Im Makefile steht sie ja in Hz.

[muebau]

Hi,
um den USBasp verwenden zu koennen muessen doch noch Aenderungen in der

Code:

hardwareInit

und

Code:

irInit

gemacht werden (DDRx und PORTx). Uebersehe ich da was?

muebau

[alibenpeng]

eigentlich sollten da keine Änderungen nötig sein. Außer den Pins für D+ und D- wird ja nur noch ein weiterer Pin für den TSOP gebraucht, und der muss einen Interrupt auslösen können. Bei den "großen" Atmegas kann das ein beliebiger Pin mit PCINT sein, aber beim Atmega8 muss das PD3 (INT1) sein, da der Atmega8 keine PCINTs kann.

Insofern sollte der Code eigentlich ohne weitere Modifikationen auf dem USBASP laufen (probiere ich aus, wenn meine Bestellung da ist).

Gruß,

Ali

[muebau]

Hi,
hab mir mal das Repo geforked. Meine Version habe ich hier erfolgreich auf einem USBasp laufen. Die LEDS hab ich als Indikator verwendet.

Ist es normal das die ich erst die Shift-Taste druecken muss, diese dann loslassen und dann die Buchstabentaste druecken muss?

muebau

BTW: hast du schon eine remote.conf fuer die aktuelle EasyVDR 1.0? Damit sind dann auch die Tasten out of the box korrekt.

[alibenpeng]

Hi,
hab mir mal das Repo geforked. Meine Version habe ich hier erfolgreich auf einem USBasp laufen. Die LEDS hab ich als Indikator verwendet.

Ist es normal das die ich erst die Shift-Taste druecken muss, diese dann loslassen und dann die Buchstabentaste druecken muss?

muebau

BTW: hast du schon eine remote.conf fuer die aktuelle EasyVDR 1.0? Damit sind dann auch die Tasten out of the box korrekt.

Dass man die Modifier loslassen muss ist leider so, das habe ich nicht anders hinbekommen (sie werden aber immerhin "gesammelt", so dass man mehrere Modifier gemeinsam nutzen kann (z.B. Alt-Shift-Tab). Ich habe irgendwo mal ein Paper zu dem Protokoll gesehen, nach dem das auch anders möglich sein sollte, aber ich weiß nicht, ob ich das in den Decoder-Code reingestrickt bekomme.

Und nein, eine remote.conf habe ich noch nicht (auch kein Easy-VDR). Braucht man die denn überhaupt? Und wenn, wofür, bzw. was geht damit, was ohne nicht geht?

[muebau]

Dass man die Modifier loslassen muss ist leider so, das habe ich nicht anders hinbekommen (sie werden aber immerhin "gesammelt", so dass man mehrere Modifier gemeinsam nutzen kann (z.B. Alt-Shift-Tab). Ich habe irgendwo mal ein Paper zu dem Protokoll gesehen, nach dem das auch anders möglich sein sollte, aber ich weiß nicht, ob ich das in den Decoder-Code reingestrickt bekomme.

Schade

Und nein, eine remote.conf habe ich noch nicht (auch kein Easy-VDR). Braucht man die denn überhaupt? Und wenn, wofür, bzw. was geht damit, was ohne nicht geht?

Ach das ist nur ein Mapping von Tasten auf Funktionen. (Taste x soll ESC, Taste y soll "Aufnamen" sein)

muebau

[Martin]

Mist: Wie es aussieht den ersten USB-ASP geschrotet.

Für nen Hinweis wäre ich dankbar. (Das Hexfile sieht z.B. auch etwas merkwürdig aus; B250 nutz ich eigentlich immer weil es sonst je nach Firmware des Programmers/AVR-Dude-Version zu Problemen kam...)

sudo avrdude -P usb -c usbasp -p m8 -B250 -U flash:w:main.hex

avrdude: set SCK frequency to 4000 Hz
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x1e9307
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
        To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is -257 (if being tracked)
avrdude: erasing chip
avrdude: set SCK frequency to 4000 Hz
avrdude: reading input file "main.hex"
avrdude: input file main.hex auto detected as Intel Hex
avrdude: writing flash (4796 bytes):

Writing | ################################################## | 100% 57.22s



avrdude: 4796 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex auto detected as Intel Hex
avrdude: input file main.hex contains 4796 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 52.10s



avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
        0xc6 != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was 9f, and is now 0
Would you like this fuse to be changed back? [y/n] y

^C

[Martin]

Ich ziehe meine eigentliche Frage zurück. Der USB-ASP lässt sich nach etwas Geduld wieder ansprechen und flashen.
Nun ist nur noch die Frage warum die Ruwido Tastatur keine Reaktion zeigt.

Neu: Nach dem zweiten mal flashen zeigt Windows auch schon mal ein unbekanntes HID Device...

[alibenpeng]

Puh, da kann ich ja gar nichts hilfreiches zu sagen. Windows habe ich nie ausprobiert..

[Martin]

Danke für die Rückmeldung.

Stand ist so:

Windows erkennt ein unbekanntes Device. (Aber das Virtualbox-Progrämmchen unter Windows weiss schon dass es ein Ruwido* Reciever ist)
Unter Linux kann man per "lsusb" einen RUWIDO Merlin Receiver sehen.
Aber gedrückte Tasten haben z.B. in nem Terminal unter Linux keine Wirkung.

Kann es sein dass ich noch irgendwas im Source falsch konfiguriert habe ?
(3 Posts weiter oben ist der komplette Source so wie ich kompiliert + geflasht habe)
Komisch ist halt dass es "ein bisschen geht"...

[Wirbel]

Könnte am Clock liegen, USB ist sehr kitzlig, wenn der Takt nicht perfekt passt, z.B. Interrupts die zu lange brauchen oder falsche Clock settings.

[Martin]

Mir scheint eher dass es an der USB-ID liegen koennte.
Bin mir leider nicht 100% sicher was da zu nehmen ist damit kein  extra  Windows-Treiber noetig ist.
Der Receiver hängt bei meinen USBASP auf PB5/SCK. Dazu hab ich widersprüchliches gelesen...

Funktion hab ich damit auch unter Linux keine. (TSOP 31256 testweise an 20cm Kabel)

[glotzi]

Ist das hier evtl. dein Problem:

http://www.vdr-portal.de/board18-vdr-har...ost1132486

Alle Stable-Kernel sind/waren davon betroffen.

[Martin]

Hi Glotzi,
davon gehe ich aus. Aber ich brauche vermutlich andere IDs als Du, wenn es direkt als Tastatur erkannt werden soll...