Announcement: there is an English version of this forum on Hier ist ein kleines Nebenprodukt eines größeren AVR-basierten Embedded-Projekts, an dem ich dieser Tage arbeite: Ein pinchange Interrupt basierender, MIT-lizensierter Dekoder fuer die RUWIDO Merlin Infrarottastatur (gibt's derzeit fuer 2,95 EUR bei Pollin - und kommt sogar im US-Layout :) ) Was diese Implementierung grundsaetzlich von IRMP (welches ein tolles Projekt ist - meiner Erfahrung nach fuer alles ausser der Ruwido Tastatur ;) ) unterscheidet ist, dass der Timer nur als Zeitnormal genommen wird, die Interrupt-Routine wird dagegen nur dann aufgerufen, wenn tatsaechlich eine Veraenderung am Eingangspin eintritt (pinchange-Interrupt). Das Vorgehen hat einige Vorteile: - geringere CPU-Last (weil die ISR nur aufgerufen wird, wenn wirklich was zu tun ist) - robuster wenn viel andere CPU-Last auftritt (weil seltener Interrupts abzuarbeiten sind entsprechend geringer die Gefahr, welche zu verpassen) Der Code erkennt auch das NEC-Protokoll und sollte an viele andere Protokolle angepasst werden koennen, DEBUG/LOG - Moeglichkeiten sind vorhanden. Die Schnittstelle / Datenstrukturen sind sehr aehnlich zu IRMP. Natuerlich darf mein Code und alle daraus gewonnenen Erkenntnisse in IRMP verwendet werden - falls hier jemand vom IRMP Projekt mitliesst :) Mehr infos siehe ir/ir.h und ir/ir.c . Das enthaltene Test-Programm loggt einfach die erkannten IR-Events auf der seriellen Schnittstelle (38400 8N1): IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x0AB4 flags=000 cnt=030 data=0x0AAACAB4 IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x02B5 flags=000 cnt=028 data=0x02AAB2B5 IR: adr=0x2AAB cmd=0x02B5 flags=000 cnt=028 data=0x02AAB2B5 IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x2AAB cmd=0x0000 flags=001 cnt=016 data=0x00002AAB IR: adr=0x22D6 cmd=0x0867 flags=000 cnt=032 data=0x22D69867 IR: adr=0x22D6 cmd=0x02CD flags=000 cnt=032 data=0x22D632CD IR: adr=0x22D6 cmd=0x0A75 flags=000 cnt=032 data=0x22D68A75 IR: adr=0x22D6 cmd=0x00DF flags=000 cnt=032 data=0x22D620DF IR: adr=0x22D6 cmd=0x08D7 flags=000 cnt=032 data=0x22D628D7 0x2AAB ist RUWIDO, 0x22D6 ist NEC. Die Tastatur schickt dauernd events wenn eine Tastate gedrueckt gehalten wird (flags==0) und produziert auch key-up events, wenn sie losgelassen wird (flags==1). Code haengt an diesem Posting, englischer Blogeintrag samt Bildchen dazu: https://sites.google.com/site/guenterbartsch/blog/avratmega48ruwidomerlinirkeyboarddecoder
Sorry, dem Anhang fehlte die File-Extension (war ein tar.gz). Hier nochmal mit extension.
Guenter B. schrieb: > Was diese Implementierung grundsaetzlich von IRMP (welches ein tolles > Projekt ist - meiner Erfahrung nach fuer alles ausser der Ruwido > Tastatur ;) ) unterscheidet ist, dass der Timer nur als Zeitnormal > genommen wird, die Interrupt-Routine wird dagegen nur dann aufgerufen, > wenn tatsaechlich eine Veraenderung am Eingangspin eintritt > (pinchange-Interrupt). Das Vorgehen hat einige Vorteile: Du hast vollkommen recht: die Ruwido-Tastatur wird von IRMP nicht unterstützt. Die Idee, den PinChange-Interrupt zu verwenden, habe ich auch schon gehabt. Natürlich sinkt dadurch die CPU-Last. Ich wollte schon immer im IRMP einbauen, dass die Methode, ob PCINT oder Timer als Basis verwendet werden soll, konfigurierbar ist. Bisher habe ich die Arbeit daran aber gescheut. Da zudem IRMP mittlerweile auch auf PIC und STM32 portiert ist, weiß ich nicht, was da alles noch notwendig ist, um das Ganze noch portabel zu halten. > Der Code erkennt auch das NEC-Protokoll und sollte an viele andere > Protokolle angepasst werden koennen, DEBUG/LOG - Moeglichkeiten sind > vorhanden. Die Schnittstelle / Datenstrukturen sind sehr aehnlich zu > IRMP. Natuerlich darf mein Code und alle daraus gewonnenen Erkenntnisse > in IRMP verwendet werden - falls hier jemand vom IRMP Projekt mitliesst Ich lese mit - seit heute. Gute Arbeit, ich werde Dein Projekt weiter verfolgen :-) Gruß, Frank
> Du hast vollkommen recht: die Ruwido-Tastatur wird von IRMP nicht > unterstützt. Die Idee, den PinChange-Interrupt zu verwenden, habe ich > auch schon gehabt. Natürlich sinkt dadurch die CPU-Last. Ich wollte > schon immer im IRMP einbauen, dass die Methode, ob PCINT oder Timer als > Basis verwendet werden soll, konfigurierbar ist. Bisher habe ich die > Arbeit daran aber gescheut. Da zudem IRMP mittlerweile auch auf PIC und > STM32 portiert ist, weiß ich nicht, was da alles noch notwendig ist, um > das Ganze noch portabel zu halten. kann ich gut nachvollziehen - IRMP hat eine enorme Breite, sowohl was Plattformen als auch Protokolle angeht (Hut ab!) - ich dachte ehrlich gesagt auch eher daran, den Ruwido-Support in IRMP zu verbessern - bin aber nicht sicher, wie schwierig das ist (ich steige durch den IRMP-Code nicht komplett durch, bin also nur eine begrenzte Hilfe). Was mir aufgefallen ist: Die Tastatur arbeitet mit variabler Anzahl bits - mal sendet sie nur 16 (wenn eine Taste losgelassen wurde), mal 26 bis hin zu 33 bits, wenn eine Taste gedrueckt wird. Und leider kann man am Prefix nicht erkennen, wie viele Bits noch kommen werden. Noch unangenehmer ist, dass die Tastatur nicht immer Pausen macht zwischen den einzelnen Paketen - vor allem, wenn man schnell tippt oder Tasten gedrueckt haelt oder mehrere Tasten gleichzeitig drueckt. Ich habe sogar beobachtet, dass Datenpakete einfach abgebrochen werden und sofort ein neues, vollstaendiges Paket beginnt. Wirklich festhalten kann man sich nur an den Pausen: wenn man auf eine Pause trifft kann man recht sicher sein, dass die letzten 16 oder 26-33 Bits gueltig gewesen sein muessten. Weiss nicht, ob diese Erkenntisse hilfreich sind - war aber das, was mich Zeit und Nerven gekostet hat. > >> Der Code erkennt auch das NEC-Protokoll und sollte an viele andere >> Protokolle angepasst werden koennen, DEBUG/LOG - Moeglichkeiten sind >> vorhanden. Die Schnittstelle / Datenstrukturen sind sehr aehnlich zu >> IRMP. Natuerlich darf mein Code und alle daraus gewonnenen Erkenntnisse >> in IRMP verwendet werden - falls hier jemand vom IRMP Projekt mitliesst > > Ich lese mit - seit heute. Gute Arbeit, ich werde Dein Projekt weiter > verfolgen :-) Ich muss gleich dazusagen, dass ich an dem IR-Code an sich gar nicht mehr so viel machen werde in naechster Zeit - wie gesagt, ist Teil eines groesseren Embedded Projekts und da gibt es noch einiges an anderer Firmware zu schreiben, dem werde ich mich bald zuwenden. Aber, heute gibt es auf jeden Fall noch ein Update: Ich habe einen kleinen FIFO eingefuehrt (8 Slots) in dem die IR-Eingaben gepuffert werden - damit auch ein langsames main() diese halbwegs sicher abholen kann - Update haengt an diesem Posting. Gruesse, Guenter
Hi, siehst du irgendwo Schwierigkeiten beim Versuch das Ganze auf einen USBasp zu portieren (atmega8, 12Mhz; INT0 PD2, PB0, PB1 belegt). Es wäre ja noch ein Interrupt frei (INT1). Wie kritisch sind die 12 Mhz? Ziel ist eine HID USB Tastatur mit V-USB zu bauen. muebau
Hi! Fridolin Onteca schrieb: > Hi, > siehst du irgendwo Schwierigkeiten beim Versuch das Ganze auf einen > USBasp zu portieren (atmega8, 12Mhz; INT0 PD2, PB0, PB1 belegt). > Es wäre ja noch ein Interrupt frei (INT1). kenne den usbasp selber leider nicht - der freie Interrupt ist aber auf jeden fall schonmal ein Anfang :) Spontan frage ich mich noch, ob das v-usb in Timingprobleme laufen kann, wenn es durch den Hardware-Interrupt gestoert wird > Wie kritisch sind die 12 Mhz? Timer1 wird als Zeitnormal verwendet - die Konstanten in ir/ir.c
1 | #define RUWIDO_SHORT_MIN 10
|
2 | #define RUWIDO_SHORT_MAX 16
|
3 | |
4 | #define RUWIDO_LONG_MIN 23
|
5 | #define RUWIDO_LONG_MAX 30
|
6 | |
7 | #define RUWIDO_MIN_NUM_BITS 26
|
8 | #define RUWIDO_MAX_NUM_BITS 33
|
9 | |
10 | ...
|
sind dann alle in Timer-Einheiten experimentell ermittelt - und die
stimmen dann natuerlich nicht mehr, wenn sich der CPU-Takt aendert.
Naheliegend gibt es zwei Loesungsmoeglichkeiten:
- Timer umkonfigurieren, dass er wieder so schnell wie mit 16MHz laeuft
- die Werte oben umrechnen (t * 12 / 16 muesste eine guten Startwert
liefern)
> Ziel ist eine HID USB Tastatur mit V-USB zu bauen.
oh, das klingt natuerlich wie ein schoenes Projekt :)
viele gruesse,
guenter
Fridolin Onteca schrieb: > Ziel ist eine HID USB Tastatur mit V-USB zu bauen. aber warum dann usbasp? es gibt auf der V-USB-Seite auch Beispielprojekte, die direkt eine HID-Tastatur implementieren.
Vlad Tepesch schrieb: > Fridolin Onteca schrieb: >> Ziel ist eine HID USB Tastatur mit V-USB zu bauen. > > aber warum dann usbasp? > es gibt auf der V-USB-Seite auch Beispielprojekte, die direkt eine > HID-Tastatur implementieren. Hi, nun der USBasp wird von mir nur als billige Hardwareplattform verwendet. Seit dem es den für ~$3 (ca. 3 €) bei ebay.com aus China gibt, verwende ich den oft für solche Spielereien. Die Bauteile sind bei Reichelt teurer als diese kompletten Platinen. muebau BTW: Sollte jemand eine ähnlich billige Alternative kennen immer her damit.
Hallo, ich habe mal den Decoder mit V-USB zusammengestrickt. Näheres hier: Beitrag "RUWIDO Merlin IR-USB-HID Receiver" Gruß, Ali
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.