Hallo,
es gibt wohl schon einige Projekte dieser Art.
Ich hatte gerade nicht die geforderte Hardware zur Hand und Lust drauf
und soweit ich gesehen habe noch keines für den XMEGA.
Das Resultat lässt sich sehen.
USB-HID mit LUFA.
Bis zu 4 Keys/modifiers werden parallel gelesen.
Fehler Korrektur. (Soweit denn möglich)
Alle Tasten sind gemapt.
36 MHz Abtastfrequenz.
Schaltplan Empfehlung.
Das einzige was ich nicht realisiert habe, ist dynamisches kalibrieren.
Der timings. Allerdings nur weil es wahrscheinlich nie einer brauchen
wird.
Der Code ist an den Wichtigen stellen gut kommentiert. Bis auf weiteres
auch auf Deutsch.
Die Tasten lassen sich relativ einfach umzumapen.
Ich habe es mal bei sf Hochgelanden.
https://sourceforge.net/projects/xmerlinruwido/
Dieser Pollin IR sensor funktioniert gut in meinem Fall:
Infrarot-Empfänger SHARP GP1UM287YKB, 56,8 kHz
Andere habe ich nicht getestet, es sollten aber alle gehen die schnell
genug sind.
~220µS Pulsbreite.
Wenn es Fragen gibt gerne auch hier stellen.
Beste Grüße
Felix
Hallo,
weil es mir nicht so gut gefallen hat, das ich mit der IR-Tastatur
Merlin die Maus nicht bedienen konnte habe ich mein Projekt in die
Zweite Version gebracht. Zur Zur Zeit noch wenig getestet, allerdings
ohne bemerkte Fehler.
Es ist nun möglich die Tastatur per Taste in einen Maus modus zu
versetzen.
Dann kann man die Pfeiltasten, die Ok-Taste und die M-Taste nutzen um
die Maus zu kontrolieren.
Weiter habe ich ein CDC interface hinzugefügt welches das auslesen von
IR Ruwido codes erlaubt.
Es gibt normalerweise auf SourceForge weitere Informationen und aktuelle
downloads:
https://sourceforge.net/projects/xmerlinruwido/
Da SourceForge die letzte Zeit häufiger down ist liegt aber noch eine
Kopie im Anhang.
Ein bisschen was ist auch im Wiki zu lesen, ich habe einen Existierenden
Artikel ergänzt:
http://www.mikrocontroller.net/wikisoftware/index.php?title=IR-Tastatur_Merlin_Ruwido
Ein Beispiel Schaltplan befindet sich im Source Archiv
Benötigte Software:
make
avr-gcc oder win-avrgcc
avrdude oder alternative
Anleitung:
1. Hardware aufsetzen
2. makefile anpassen (einstellungen)
3. make aufrufen
4. make avrdude aufrufen
Diese Anleitung ist nur unter linux gestestet, mit Windows kenne ich
mich da leider nicht aus. Gerne kommentare dazu.
Fähigkeiten:
3-endpoints Maus, Tastatur, CDC dank LUFA
Steuern der Maus
Steuern der Tastatur
Keine zusätzliche Software zum benutzen des Empfänders erforderlich
CDC-debug interface
Sehr hohe abtastrate 36*10^6
Flanken gesteuerte IR Erkennung
Einfach zu änderndes Keymapping
Maus Beschleunigung
Fehler erkennung im Header (soweit den möglich)
Ließt bis zu 4 Tasten/Modifiers gleichzeitig.
Evt. geplante erweiterungen:
Weitere Makro keys z.B. record keyboard input oder play saved keyboard
input oder repeat... Mal sehen weiß noch nicht ob das Sinn macht.
Per CDC konfigurierbares Keymapping.
Weitere Ideen, Kritik oder Probleme möchte ich gerne hören.
Beste Grüße
Felix H.
Hallo,
danke, kann ich sehr gut gebrauchen.
Versuche über die Schnittstelle V_USB mit Atmega 8 die Tastatur an
meinen Fernseher zu bekommen.
Gruß
Anlen
Freut mich das es dir hilft, ich habe es eigentlich nur zum Spaß
gemacht. Mal ein Projekt das man abschließen kann, aber wenn du eine
implementation mit vusb hinbekommst würde ich mich freuen wenn ich ein
Kopie hochladen dürfte, weil längst nicht alle einen X-Mega haben.
Beste Grüße
Felix
Hallo anlen,
ich wollte mich auch mal mit v-usb vertraut machen und habe deshalb mein
Projekt noch mal portiert.
Es gibt wohl schon ein paar ähnliche Projekte.
Du es auf der Sourceforge Seite finden unter den branches (SVN).
Der code ist noch ein wenig chaotisch, vielleicht mache ich es nochmal
ordentlich und binde ihn ins main ein.
Dann schreibe ich das hier auch.
Maus geht leider nicht mit dem atmega :( Konnte kein zweites interface
bei v-usb adden.
Weiß jemand wie das zu schaffen ist?
Oder kann man gemeinsamme HID reports für mouse und keyboard schicken?
Bisher ist das Projekt nur für atmegax8 aber das lässt sich wohl leicht
erweitern sind glaube ich nur 3 oder 4 defindes, welche dir der compiler
Melden müsste.
Der Input Pin für den Sensor ist int1. Weil ich den interrupt brauche.
Den rest habe ich original nach dem usbasp nachgebaut, davon hatte ich
noch ein paar liegen.
Ein 20MHz oder 16MHz quarz (je nach controller) dürte allerdings nicht
schaden, sondern eher freuen.
Beste Grüße
Felix
Schön!
Jetzt passt der code auch auf einen atmega48...
Um das zu erreichen ein s in der Makefile für optimierung eingeben...
Wie gehabt bin immer noch im branch (megax8) welcher nur im svn liegt.
Der code ist mir noch zu experimentel um ein release draus zu machen.
Beste Grüße
Felix
So habe ein neues Release rausgebracht,
version 1.0b2 hat bessere abstraktionsebenen, und ist damit etwas
übersichlicher, weiter scheint es auf beiden architekturen problemlos zu
funktionieren.
Ich bekomme demnächst noch ein paar andere IR-Tastaturen dazu, wenn ich
Zeit finde werde ich dann auch Unterstützung für diese anbieten.
Wenn jemand lust hat mir ein wenig mit v-usb zu helfen würde ich mich
freuen. Ich bekomme einfach kein neues Interface hinzugefügt, was wohl
nötig ist wenn man gerne mouse support hätte.
Grüße
Felix
So liebe Leute ein haufen Neuer Funktionen sind jetzt ins Projekt
eingebunden.
Viele davon sind noch experimentel.
Maus support jetzt auch für den mega.
Man kann jetzt scrollen.
Es gibt neue macro funktionen.
Das Interface wurde vereinfacht so das jetzt (also wahrscheinlich erst
nachdem ich es dokumentiert habe) jeder eine neue Tastatur hinzufügen
können sollte. Man muss nur eine decode methode implementieren und die
Tasten Mappen.
Das keymapping wurde ins eeprom verschoben, es wäre also möglich die
Tastenbelegung zur laufzeit neu zu programmieren.
Ein relativ einfaches interface zum hinzufügen von Macro Funktionen.
Quelltext neu strukturiert.
Es gibt eine neue config (Bitte kurz reinschauen: config/settings.h)
Ein paar Dinge haben sich in der Belegung geändert:
Zwischen Maus und Tastatur hin und her schalten:
VT+m
Debug an/aus (nur xmega):
VT+d
Modifiers an/aus (ist halt quatsch):
VT+q
Maus Belegung:
Pfeiltasten,
P (rechte Maustaste) //Also die sondertaste
OK (linke Maustaste)
M (Scrollen) //Hier auch die sondertaste
Taste unter M (Scrollen)
Habe heute keine Zeit mehr deshalb bin ich leider noch nicht dazu
gekommen die Readme zu aktualisieren oder das ganze zu dokumentieren.
Aber es ist ja halt auch immer noch Beta, da lohnt sich das noch nicht
so toll.
Wie auch immer ich hoffe ihr könnt damit etwas Anfangen.
Beste Grüße
Felix
Hallo endlich habe ich mal wieder ein wenig Zeit gefunden.
Der receiver unterstütz jetzt auch das keyboard:
FDC-3402 (38KHz)
Das kostet nur 0,75€ bei pollin und macht seinen job ganz gut. Es kommt
mit einer analogen maus. Die ich auch gleich mit implementiert habe.
Weiter entschuldige ich mich bei allem für eine Fehlerhafte Readme
Datei.
Das programmieren des controllers muss mit:
1
make avrdude
2
make avrdude-ee
oder
1
make install
erledigt werden nicht nur make avrdude.
Ich hoffe es sind nicht allzu viele in diese Falle getappt.
Für das neu unterstützte keyboard habe ich den:
1
TSOP1138
Welcher seinen Job ganz gut macht, alledings nicht so gut das es den
Preis rechtfertigen würde.
Wenn also jemand einen anderen Sensor zum Testen hat wäre ich wie immer
interessiert ob er funktioniert.
Das FDC-3402 hat ein hässliches Protokoll deshalb muss man jeden Stop
code bekommen. Sonst bleibt die Taste bis zum Timeout gedrückt.
Noch kurz zum Keymapping vom neuen Keyboad:
Die rechte nicht beschriffte Taste ist die Macro Taste,
wer sonder Funktionen für die Maus will (Scrollen und Button 3),
muss also diese Taste + die m Taste gleichzeitig drücken und es wird in
den Mouse Modus gesprungen.
Dann gilt folgende Belegung:
1
Macro + m: Mouse mode off
2
Wheel up: page up
3
Wheel down: page down
4
Mouse3: Left Windows/GUI (Linke nicht beschriffte Taste)
Die standard Funktionen der Maus sind allerdings immer vorhanden, da es
für diese Seperate Tasten gibt.
Wer den Code mit dem XMega nutzt kann zusätzlich die Debug-Funktion ein
und ausschalten mit:
1
Macro Taste + d
!!! Aber vorsicht wer im debug Modus ist, muss auch den debug output
entgegen nehmen sonst reagiert die Tastatur nicht richtig.
Unter Linux reicht ein:
1
cat /dev/ttyACM*
Weiter habe ich ein Generisches Interface zum hinzufügen von neuen
Tastaturen hinzugefügt.
Es ist leider noch nicht dokumentiert, aber es sollte auch so zu
schaffen sein da ich bei meinen Tastaturen Kommentare genutzt habe.
Wer eine eigene Tastatur mit einem anderen Protokoll hinzufügen möchte
muss einen Ordner und folgende Dateien erstellen:
1
./decoder/tastaturname/tastaturname.c
2
./decoder/tastaturname/keyboard_settings.h
Die tastaturname.c könnte etwa so aussehen:
1
#include"../decoder.h"
2
3
4
#include<stdio.h>
5
#include<string.h>
6
#include<stddef.h>
7
#include<stdlib.h>
8
#include<core/x_scancodes.h>
9
#include<avr/pgmspace.h>
10
11
12
#include<core/core.h>
13
#include<core/x_helpers.h>
14
15
#include<core/macros/debug.h>
16
17
volatileuint8_ttimeout=0;
18
19
//This function will be called every X_TIMEOUT_MS ms
20
//return and arguments are the as them for decode
21
int8_tsignal_timeout(uint8_t*result)
22
{
23
// printf_debug("to\n");
24
if(timeout<24)
25
{
26
timeout++;
27
if(timeout==24)
28
{
29
//reset Keycodes if 24 * X_TIMEOUT_MS ms are gone
30
return0;
31
}
32
}
33
// nothing to be done return -1
34
return-1;
35
}
36
37
38
39
int8_tdecode(uint8_t*result)
40
{
41
//Reset Timeout variable
42
43
//Decode the ir signal from
44
//x_ir_reader.data_pos
45
//and
46
//x_ir_reader.data[x];
47
//you can use X_GET_NEXT_PULSE(x); for getting signal length in timer counts with x < x_ir_reader.data_pos - 1
48
49
//Translate all ir-codes to x_codes and save them to result[n]
50
51
//return -1 if decode failed
52
//return count of translated codes
53
returnuse_data_byte_count;
54
}
Die keyboard_settings.h sollte zunächst aus einem der anderen Projekte
kopiert werden und ist hoffentlich durch die kommentare selbst
erklärend.
Wer den xmega nutzt kann auch auf die debug funktion zurückgreifen und
mit der Macro Funktion
1
printf_debug("pattern",args);
Kompilieren kann man das ganze dann in dem man den Namen seiner Tastatur
in der:
1
makefile
beim Unterpunkt:
1
DECODER
einträgt.
debug Output auf der Virtuellen Console ausgeben.
Wenn ich Zeit finde werde ich mich noch um diese Tastatur kümmern:
SWK-8650
Beste Grüße
Felix
Hallo,
ich habe gestern noch ein wenig Zeit gefunden das SWK-8650 alias NETBOX
Keyboard zu implementieren.
Und ich habe die Version 2.0rc2 released.
Es war ein ganz schönes gefrickle, weil das Protokoll unkonventionel
ist.
Aber nachdem es erstmal implementiert ist, bin ich sehr zufrieden.
Auf dem mega8 funktioniert es gut und auf dem XMega merke ich keinen
Unterschied zu meiner Kabelgebundenden Tastatur mehr.
Weiter hat es ebenfalls relativ gute Reichweite, ich denke die beste
bisher.
Was wohl nicht zuletzt an den etwas breiteren Pulse Weite liegt, jetzt
800µS.
Kann ich also wirklich empfehlen.
Details zur implementierung und zur Tasten Belegung findet man im Ordner
1
core/decoders/swk-8650
Ach und der mega8 wird jetzt voll unterstütz und ist getestet.
Das gilt also Wahrscheinlich auch für den mega16 etc.
Wenn ich das nächste mal Zeit finde werde ich für unsere Windows User
ein paar binaries precompilen, und die LED geschichte in Ordnung bringen
:)
Achso bei den ganzen Einstellungen mag man wohl gerne mal durcheinader
kommen. Aber wer die Software nur benutzten möchte braucht wohl auch nur
die makefile anzupassen.
Dort gibt es bereits ein paar Beispiele für verschiedene Controller.
Viel Glück dabei.
Da sourceforge wieder besser Funktioniert ladet die den Kram am besten
hier runter:
https://sourceforge.net/projects/xmerlinruwido/
Beste Grüße
Felix
!!! Es müssen umbedingt beide files geflasht werden eep und hex. Sonst
funktioniert es nicht.
!!! Falls es Probleme gibt lohnt es sich auch die fuses nochmal
anzuschauen. Vielleicht ist das bei den AVR8 controllern sogar immer
nötig.
Für die avr8 controller gibt es da eine readme Datei.
Für die XMEGA controller gibt es immer noch eine xmega_hwconfig.h in den
Ordnern. Die beschreibt wo, was angeschlossen ist.
Die HEX Dateien sind bis auf weiteres ungetestet.
Habe aber leider keine Zeit mehr dafür.
Theoretisch sollte es aber alles klappen.
Beste Grüße
Felix
Hey Felix,
wollte nur mal kurz ein dickes Danke sagen, das Projekt ist der Hammer,
v.a. dass Du hier mehr oder weniger im Monolog so fleißig Updates
postest und dokumentierst.
Ich bin komischerweise erst gestern auf den Thread gestoßen obwohl ich
mich schon seit einer Weile mit der merlin beschäftige, bisher mit
dieser (1) Lösung, die allerdings die Modifier (Shift etc.) nur
sequentiell auswertet, also nur sehr umständlich zu bedienen ist. Dass
die bei Dir jetzt anstandslos laufen und dann noch eine Maus-Emulation
dabei ist, macht es für mich zur perfekten Lösung für RetroPie und
ähnliche Sachen, die Tastatur/Maus nur gelegentliche zu Wartungsarbeiten
brauchen. Habe dann auch gleich die FDC-3402 ausprobiert, die Wipp-Maus
ist für meine Anforderungen völlig ausreichend - genial, so brauche ich
nur ein USB-Gerät statt zwei.
Ich habe Deinen Thread bisher wohl immer ignoriert, da im Threadtitel
nur der xmega erwähnt wird, mit dem ich bisher nciht arbeite. Dass
inzwischen auch der mega8 unterstützt wird habe ich gestern erst
gesehen. Vielleicht kann man ja den Titel mal anpassen, vielleicht
finden auch andere deswegen nicht her.
Bei der Gelegenheit meine Frage: Könnte das Ganze nach Deiner
Einschätzung auch noch auf einen tiny85 passen? Die vielen Pins braucht
es hier ja gar nicht und auf UART/debug könnte ich verzichten.
(1)
http://testblog.arles-electrique.de/2012/12/ruwido-merlin-ir-usb-hid-receiver.html
Hallo huj,
freut mich zu hören das zumindest einer meine Software nutzt!
Das mit dem XMega im Titel hat mich auch ein wenig gestört deshalb hatte
ich ein Zweites aufgemacht, leider wurde es sofort hierher verschoben
und angehangen.
Ich habe rausgeholt was ging, leider bringt nur die Merlin Ruwido
Tastatur ein wirklich Sinnvoll Protokoll mit.
Ich möchte gerne nochmal betonen das alle Modelle eine Maus Funktion
unterstützen, bei denen die nicht direkt eine Hardware Maus mitbringen
kann die Maus mittels makro + m Taste in der Regel auf die Pfeiltasten
gemapt werden. Dies funktioniert genau so gut wie die Hardware Maus, bis
auf das man natürlich umschalten muss.
Mehr dazu steht in den jeweiligen Readmes zu den Tastaturen, weil das
mapping ja unterschiedlich ist.
Ich frage mich halt auch ein bisschen warum das Projekt nicht mehr
aufmerksamkeit bekommen hat.
Weil man muss es ja leider so sagen, es ist für die unterstüzten
Tastaturen bei weiten das stabilste und umfangreichste.
Beste Grüße
Felix
Oh sorry, letzte Frage nicht gelesen, das mit dem Tiny sollte kein
Problem sein, der hat doch 8K.
Frühe Versionen passen auch auf einen Chip mit 4K, ich habe eine
zusätzliche Abstraktionsebene eingebaut damit es einfacher wird neue
Tastaturen einzuarbeiten. Dies macht leider auch etwas zusätzlichen
Speicher notwendig.
Ich habe jedoch leider keinen Tiny mit dem ich das Testen kann.
Es kann sein das noch ein Paar defines gesetzt werden müssen. Das wird
dir jedoch der Compiler sagen wenn du es probierst.
Ist das dein Blog?
Sieht ganz nett aus:)
Grüße
3 pins sollten reichen, allerdings nur mit Software modifikationen.
Die UART Debug geschichte läuft mit über USB. Und geht eh nicht über den
Mega weil der nur einen LOW-Speed endpoint hat, weil das so eine
Software Geschichte ist.
5 pins sollten ohne Software Modifikationen gehen:
2 Leds (Kann drauf verzichtet werden)
2 USB
1 Sensor.
LG
Hi Felix,
ja, die Maus-Emulation ist gut dokumentiert, nur die wipp-Maus der FDC
finde ich doch deutlich näher am Original also die Emulation auf Basis
der Pfeiltasten, die aber als Notnagel auch sehr nützlich ist.
Nein, das ist nicht mein Blog, nur die Lösung, die ich bisher verwenden
wollte, bevor ich auf Deine Lösung gestoßen bin.
Attiny85 habe ich gestern schon mal probiert, indem ich im makefile
MCU=attiny85 definiert habe (wäre das überhaupt der richtige Weg?). Die
Fehler am Anfang waren noch leicht zu beheben (auskommentieren der
Debug-LEDs), aber spätestens bei den Timern/Interrupts ist offenbar doch
einiges anderes, defines wie TCCR1B und ISC10 laufen hier ins Leere und
da komme ich doch recht schnell ans Ende meiner derzeitigen
Möglichkeiten, wie das auf dem tiny85 adäquat zu ersetzen wäre.
Aber auch mit der mega8-Lösung komme ich definiv schon ein ganzes Stück
weiter.
Ok, ich empfehle dir erstmal den Mega8 aber falls ich die nächsten Tage
nochmal Zeit habe schaue ich es mir gerne nochmal an. Allerdings kann
ich es nicht testen, deshalb müsstest du dann übernehmen, wenn du
interesse hast wäre es praktisch wenn du mit mal deine jabber-id per pn
schickst.
Beste Grüße
Felix
Felix H. schrieb:> Das mit dem XMega im Titel hat mich auch ein wenig gestört deshalb hatte> ich ein Zweites aufgemacht, leider wurde es sofort hierher verschoben> und angehangen.
Das hättest Du in Deinem Zweitthread deutlicher herausstellen sollen.
Ich ändere jetzt mal Deinen Threadtitel.
Servus Felix!
Allerbesten Dank für das Veröffentlichen dieses Projektes!
Wollte schon immer genau so etwas haben!
Ich habe die FDC-3402 im Einsatz, funktioniert recht gut, jedoch ist die
Reichweite bei mir sehr gering. Ich verwende einen VS1838B-Receiver.
Evtl. liegts auch daran, dass ich keinen 10µF-Kondensator sowie 100
Ohm-Widerstand bei der Versorgung des Revceivers verbaut habe, wie immer
in den Datenblättern vorgeschlagen.
Einziger Verbesserungsvorschlag wäre evtl. die Widerholrate bei lang
gedrückter (oder kurz gedrückter, wo der Loslass-IR-Code nicht mehr
ankam...) Taste zu reduzieren. Tolle Arbeit jedenfalls.
lG,
Daniel
Hallo Daniel,
ich nehme Leider an das, dass mit der geringen Reichweite gut am
Receiver liegen kann, die Pulse der Tastatur sind halt leider wirklich
relativ Kurz :(
Ich habe leider nur ein China Datasheet für den Receiver gefunden, da
musste ich raten was die Zahlen bedeuten :)
Weiter scheint der Empfänger relativ große Offsets zu haben.
Wenn also ein signal zum beispiel mit 200 µS toggled wird der etwas
daraus machen wie:
//Beispielhafte Darstellung//
__ _______ ____
|_______| |_______| ...
... 300 µS - 100 µS - 300 µS - 100 µS
Anstatt
... 200 µS - 200 µS - 200 µS - 200 µS
Das ist halt relativ schade man braucht für die Keyboards halt relativ
hochwertige und damit oft auch teure Empfänger.
Normal ist so ein Offset halt nicht krischtisch wenn die Pulse 2000µS
statt nur 200 µS breit sind, weil (2100µS:1900µS) ist halt nicht so
wild.
Deshalb habe ich auch zum Programmieren den TSOP1138 freund genutzt
obwohl der >1€ kostet und damit wahrscheinlich sogar ein schlechtes
Preis-Leistungs-Verhältnis hat.
Wenn du ein DOS hast würde ich mir da mal anschauen was so ankommt.
Vielleicht liegt es wirklich ein bisschen mit den Defines für die
Timings zu spielen.
Auch wenn du keines hast würde sich rumspielen mit den Timings
vielleicht lohnen.
Man muss halt leider auch einfach sagen die FDC-3402 hat das Dreckigste
unüberlegteste Protokoll mit dem ich es je zu tuen hatte. Es ist einfach
überhaupt nicht failsafe. Allein wie Dumm einfach das Batteriefach
aufgebaut ist, schricht schon für bemerkenswerte Dummheit der
Entwickler... Bei dem Preis muss man da halt durch, es ist nur
dooferweise einfach so das man im Empfänger nicht alle Fehler Ausbügeln
kann, deshalb brauch man gerade bei dieser Tastatur einen Sehr
zuverlässigen Receiver.
//Vorschlag 2
Was du auch noch probieren könntest, ist ein Pullup an out
anzuschließen, bekommen diese Receiver einfach ihr Beinchen nicht wieder
schnell genug hoch.
Was deinen Vorschlag angeht muss ich zugeben das ich nicht genau
verstehe von Welchen Wiederholraten du redest, weil die der Tastatur
kann ich natürlich nicht beeinflussen. Was natürlich schade ist weil die
echt sehr dumm gesendet werden. Und per USB, werden die Keycodes halt
insbesondere genau dann gesendet wenn es nötig ist.
Auf dem Weg USB<->PC sollte also nichts verloren gehen.
Beste Grüße und viel Glück
Felix
Felix H. schrieb:> Ok, ich empfehle dir erstmal den Mega8 aber falls ich die nächsten Tage> nochmal Zeit habe schaue ich es mir gerne nochmal an. Allerdings kann> ich es nicht testen, deshalb müsstest du dann übernehmen, wenn du> interesse hast wäre es praktisch wenn du mit mal deine jabber-id per pn> schickst.
Testen kann ich gerne übernehmen, aber mit jabber o.Ä. kann ich leider
nicht dienen, wir müssten das hier über das Forum abwickeln, wenn das
geht.
Rufus Τ. Firefly schrieb:> Ich ändere jetzt mal Deinen Threadtitel.
Wobei sich nicht nur der Kreis der Plattformen, sondern auch der der
IR-Tastaturen erweitert hat.
Daniel A. Maierhofer schrieb:> Ich habe die FDC-3402 im Einsatz, funktioniert recht gut, jedoch ist die> Reichweite bei mir sehr gering. Ich verwende einen VS1838B-Receiver.
Was heißt sehr gering bei Dir? Ich benutze einen TSOP...38 und bin mit
der Reichweite zufrieden, noch weiter weg und ich kann eh nichts mehr
lesen.
Oha, schlechtest timing hui,
ich war gerade dabei den Text vom letzten Post zu Korrigieren und die
Grafik zu reparieren... Wusste halt nicht, dass man das nicht mehr darf
wenn jemand anderes geantwortet hat :(
Ich bin halt einfach immer froh wenn ich das schon mal abgesendet habe,
weil die Post mir halt schon soo oft aus unterschiedlichsten Gründen
verloren gegangen sind... :(
Egal, dann bleibt halt bei mehreren Fehlern :)
Aber nochmal kurz die Grafik:
@ Daniel
//Beispielhafte Darstellung//
1
__ _______ ____
2
|_______| |_______| ...
... 300 µS - 100 µS - 300 µS - 100 µS
Anstatt
... 200 µS - 200 µS - 200 µS - 200 µS
@hui
huj schrieb:> Felix H. schrieb:>> Ok, ich empfehle dir erstmal den Mega8 aber falls ich die nächsten Tage>> nochmal Zeit habe schaue ich es mir gerne nochmal an. Allerdings kann>> ich es nicht testen, deshalb müsstest du dann übernehmen, wenn du>> interesse hast wäre es praktisch wenn du mit mal deine jabber-id per pn>> schickst.>> Testen kann ich gerne übernehmen, aber mit jabber o.Ä. kann ich leider> nicht dienen, wir müssten das hier über das Forum abwickeln, wenn das> geht.
Auch nicht mail oder PN weil ich würde den Thread so ungerne so
fürchterlich unübersichtlich machen...
Wenn du Zeit hast kann ich die Änderung sofort vornehmen.
> Rufus Τ. Firefly schrieb:>> Ich ändere jetzt mal Deinen Threadtitel.>> Wobei sich nicht nur der Kreis der Plattformen, sondern auch der der> IR-Tastaturen erweitert hat.
Sinnvolles Kommentar!
Felix
@hui
Nochmal zu deiner Frage ob das auf dem tiny85 auch läufen würde... Ich
habe bei meiner Antwort leider nicht genug nachgeforscht, ich bin davon
ausgegangen das jeder aktuelle Atmel Controller 2 Externe IRQs
mitbringt. Das ist leider nicht der Fall, der Tiny bringt halt nur einen
Multi channel IRQ mit. Und das ist ein Problem. Ich versuche es zu
erklären.
Die V-USB Geschichte braucht einen Hardware Interrupt um auf
zeitkritische USB request zu reagieren und ich benutze einen weiteren um
bei einen Toggle auf dem Sensor-Pin um die Zeit vom Timer zu loggen.
Meine Application ist nicht sehr Zeit kritisch und braucht halt auch
nicht sehr lange. Die USB Geschichte schon. Der Host ist sofort
beleiding wenn man nicht rechtzeitig antwortet, weil man damit den BUS
blockieren würde und andere Geräte in der Zeit nicht antworten können.
Bei einen Multichannel Externen IRQ braucht man mindestens eine Software
Weiche und auszuwerten welcher PIN tatsächlich getriggert hat. Das macht
das mit dem Timing schon mal schwieriger. Weiter ist es auch so, dass
ich tiefgehende Änderung an der V-USB Geschichte vornehmen müsste. Was
mir die Abstrationsebene nimmt und die Möglichkeit verwehrt ohne
weiteres die V-USB Geschichte zu aktualliesieren oder auszutauschen.
Eine alternative Methode wäre die Toggles an Sensor pin nicht per IRQ zu
loggen sondern per timer zu pollen. Das würde jedoch erheblich mehr MCU
Zeit benötigen, welche neben V-USB nur sehr schwer zuerübrigen ist.
Weiter müsste man mit der Genauigkeit ebenfalls erheblich runter gehen,
was mir nicht gefallen würde.
Zusätzlich wäre der Programmieraufwand relativ hoch.
Es gibt also leider keine elegante Möglichkeit den Tiny85 zu
unterstützen.
Sorry wegen des Irrtumes.
Felix
Felix H. schrieb:> Es gibt also leider keine elegante Möglichkeit den Tiny85 zu> unterstützen.
Hey, Felix, kein Thema und danke für die anschauliche Erklärung.
Irgendwie hatte ich sowas schon im Gefühl, als ich nach den
anderen/fehlenden defines ein wenig gegoogelt hatte, dass die Interrupts
da nicht äquivalent sind.
Es gibt ja offenbar Adaptionen auf den attiny85, die nicht allzu komplex
aussehen (1) (2), aber das würde ja nicht das Problem lösen, dass Du
einen zweiten IRQ brauchst.
Naja, ich sitze eh schon an der Platine für einen atmega8, beim
laufenden Projekt kein Problem, da die mit dem raspberry zusammen in
einem größeren Gehäuse verschwindet. Ich dachte beim tiny85 nur an eine
zukünftige Lösung für einen on-the-fly IR-Dongle, da wäre der tiny halt
ein Stück kleiner und schicker.
(1)
http://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/
(2) http://www.ruinelli.ch/how-to-use-v-usb-on-an-attiny85
Danke für Deine ausführliche Erklärung Felix!
Sehr gering ist bei mir max. 20cm, wo ich normalerweise viele Meter
gewohnt bin. ;)
Mit Wiederholrate meinte ich, dass wenn ich eine Taste drücke & der
Tastencode fürs Loslassen der Taste nie beim IR-Empfänger ankam, dann
hab ich am Computer ziemlich schnell viele Wiederholungen der selben
Taste, wie wenn ich eine Taste gedrückt halte, nur eben noch schneller &
öfter als auf der normalen Tastatur.
Jetzt verstehe ich, was mit langsam gemeint ist bei den TSOP & Co.
Ich hab jetzt leider grad kein DSO zur Hand, aber auch ein 1kOhm-Pullup
hat keine Abhilfe gebracht. Muss ich mir wohl einen besseren Empfänger
suchen.
Eventuell könnte man Dein Projekt mit IRMP kombinieren...
Gibt es ja in der Form als Tastatur noch nicht. ;)
Thread beobachten
Seitenaufteilung abschalten