Hi,
schon langsam wird mein Projekt fertig. Deswegen will ich hier einmal
die Vorabversion zur Verfügung stellen. Der eine oder andere kann mir
sicher helfen den AVR-Code noch etwas zu optimieren ;).
Erst einmal vielen Dank an das Forum + Community!
Auch spezielen Dank an Frank M. für sein IRMP: IRMP
Anlass für dieses Projekt war mein veralteter Igor AVR USB AT90S2312-10,
der nur RC5 konnte. Hier war die IR-Code Erkennung nicht ausreichend gut
genug um ein schönes Anwenden zu gewährleisten.
Deswegen habe ich Irmp mit V-USB verbunden um einen IR-MultiCode
Empfänger für die USB Schnittstelle zu haben.
Die Serielle COM Schnitstelle will ich nicht haben, da heutzutage viele
PCs schon nicht mehr über einen COM-Port verfügen.
Der Aufbau des Projektes unterscheidet sich in folgenden Dingen vonanderen IR-Empfänger
IR Multi Protokol Empfänger (Irmp),
Empfangene IR-Codes werden native an den Host übertragen: dies bedeutet,
dass jeder wie er will die IR-Codes am Host auswerten kann. Z.B. ein
Input Plugin für Girder oder auch einfach ein Mapping der IR-Codes zu
globalen Tastendrücken.
Der erste Empfangene IR-Code wird im EEProm abgespeichert. Dieser wird
für die sogenannte "PowerOn" Funktion verwendet.
Die PowerOn Funktion
Entspricht der empfangene IR-Code dem gespeichertem IR-Code wird für
~200ms ein Ausgang des AVR geschaltet. An diesem Ausgang kann z.B. ein
Optokoppler angeschlossen werden um damit den Power-Schalter des PCs zu
betätigen. Die PowerOn Funktion im AVR läßt sich von der Host-Software
einschalten/ausschalten.
Aufbau des AVRs
Verwendet habe ich den Atmega8-16,
mit 12MHz Quarz,
IR-Empfänger (definiert in irmp.c): TSOP1736 an PD4 (siehe Irmp
Beschreibung)
Optokoppler (definiert in main.c): an PC5
D- (defniert in usbconfig.h): PD0
D+ (defniert in usbconfig.h): PD2 (INT0)
Optional Jumper to GND for Bootloader: PD3 (siehe bootloader config)
Datenaustausch AVR <-> Host Software
Der Datenaustausch basiert auf dem Beispiel von V-USB: hid-data.
Es werden per Feature-Requests Daten gesendet/empfangen.
Dazu gibt es folgende Report IDs:
Um an die aktuellen IR-Code zu kommen muss das Feature ID1 durch Polling
abgefragt werden (~10-50ms).
Über die ID6 kann die Polling Frequenz des IR-Empfängers On-The-Fly
geändert werden. Bei mir waren mit der TSOP1736 115µs am besten.
(Bin mir jedoch hier noch nicht sicher ob diese Berechnung richtig ist,
dazu kann mir hier sicher jemand Auskunft geben).
Getestet habe ich das RC5, NEC & SIRCS Protokol.
Bootloader
Durch V-USB bietet sich ein Bootloader an. Um diesen zu benützen müssen
die Fuses richtig gesetzt werden (Screenshot im bootloader.zip). Durch
setzen des Jumpers auf PD3 kann dann einfach per der Software
"HIDBootFlash.exe" eine neue Version des USB IR Remote Receivers
eingespielt werden.
Host Software
Anbei ein Beispiel einer Host-Software mit Delphi2010 Source. Es wird
die JVCL TJvHidDeviceController Komponete benötigt. Mit der
Host-Software kann man alle Funktionen des AVR ausprobieren. Es wird
auch gezeigt wie das Repeat-Flag von Irmp ausgewertet wird. Wird ein
IR-Code mehr als 5 mal wiederholt wird er wieder normal weitergeleitet
(Tastenentprellung).
Hallo Hugo,
Hugo Portisch schrieb:
> schon langsam wird mein Projekt fertig. [...]
Eine interessante Anwendung von IRMP :-)
Mich interessiert die V-USB-Anbindung, damit habe ich bisher noch nicht
gearbeitet. Das scheint aber eine preisgünstige Möglichkeit zu sein,
AVRs an einen PC anzubinden... werde mich da mal einarbeiten.
> *Host Software*> Anbei ein Beispiel einer Host-Software mit Delphi2010 Source.
Ich habe kurz in den Source reingeschaut. Das sieht auf Host-Seite
ziemlich aufwendig aus, ein paar Bytes von links nach rechts zu
schubsen. Ich bin auch kein Freund von Pascal/Delphi, gibt es da
vielleicht irgendwo irgendeinen Beispiel-Source für den Host, der in
C/C++ geschrieben ist?
> Es wird die JVCL TJvHidDeviceController Komponete benötigt.
Ist das ein Treiber? Ich dachte, wegen Hid braucht man keine Treiber?
Ich weiß, dass Du zunächst mit einem PC-Mainboard und V-USB Probleme
hattest. Die sind mit dieser JVCL-Komponente weg... wo bekommt man diese
Komponente? Sorry für die vielleicht blöde Frage.
Gruß,
Frank
Frank M. schrieb:
> Das sieht auf Host-Seite> ziemlich aufwendig aus, ein paar Bytes von links nach rechts zu> schubsen. Ich bin auch kein Freund von Pascal/Delphi, gibt es da> vielleicht irgendwo irgendeinen Beispiel-Source für den Host, der in> C/C++ geschrieben ist?
Kommt halt immer drauf an was man vorhat. Hugo möchte auf PC-Seite die
"Rohdaten" haben und die dann dort weiterverarbeiten. Mein Ansatz wäre
es den AVR als HID-Tastatur zu nutzen. Dadurch dürfte die zu
übertragende Datenmenge wesentlich geringer ausfallen und noch dazu ist
eben keine spezielle Software auf PC-Seite nötig, sondern man kann quasi
mit der FB Texte schreiben (ohne irgendwelche Treiber o.ä.).
> Beispiel-Source für den Host, der in C/C++ geschrieben ist?
Ja, es gibt vom V-USB Paket das Example "hid-data".
In C/C++ kann das HID-Gerät glaube ich nativ angesprochen werden.
Das Beispiel zeigt einen Datatransfer down & up von 128Bytes. Man müsste
es umbauen, damit die Feature Request IDs und die richtigen Anzahl von
Bytes unterstützt werden. Dazu habe ich aber zu wenig Ahnung von C...
http://www.obdev.at/products/vusb/download.html> Ist das ein Treiber?
Nein, kein Treiber. Eine Komponente. Sie wird nur zum Kompilieren des
Sources benötigt. Original kann man mit Delphi nicht mit HID-Geräten
arbeiten. Hatte es zuerst auf Native Art versucht (über hid.dll usw).
Dadurch sind die Probleme entstanden, die ich bei meinem anderen Thread
genannt hatte (V-USB geht nicht an jedem USB-Port).
JVCL ist eine Sammlung von Komponenten, eben auch die HID-Komponente um
einfach mit dem Device arbeiten zu können. JVCL per Google: JEDI Visual
Component Library.
USB-Treiber wird wegen HID nicht benötigt! War auch einer der
Hauptgründe warum ich vom Igor USB weg bin!
Derzeit bin ich daran:
Irmp-Version besser als "String" zu übertragen,
neueste Irmp Version einfügen...
@Frank M.: wenn ich alle Prokolle in irmp.c aktiviere werden ja alle
Protokolle mit kompeliert. Dann kann man aber nicht mehr verschiedene
Protokolle "OnTheFly" deaktivieren/aktivieren, oder?
Dies wäre von Vorteil, denn dann werden einfach alle Protokolle
kompeliert und je nach IR-Diode usw per Host-Software
deaktivieren/aktivieren. -> AVR-Source muss nicht extra kompeliert
werden.
Zu dem IR-Polling-Timer:
Er soll ja ~1/10000-1/15000 sein.
Rechne ich so richtig?: (1/10000) / (1/12000000) -1; = 1199 = 100µs?
für 1/15000:
(1/15000) / (1/12000000) -1; = 799 = 66,58µs?
Zählt der Timer von 0 zu 1199? Eignetlich hatte ich gedacht das er von x
zu 0xFFFF zählt. Das würde sich aber nicht ausgehen.
Es geht darum ob die Berechnung, die im Delphi Source drinnen ist,
richtig ist.
Danke!
Hier gleich zuerst noch ein Update!
Es wird die Irmp Version nun so definiert:
1
//enter here the Irmp build date:
2
const char StrIrmpVersion[] = "17.03.2010";
Maximale Laenge: 11 Char (0-terminierung inkludiert).
Etwas zusammenräumen... Auch hatte ich im ersten Post den falschen
Bootloader hochgeladen.
Delphi Source ist nun auch 1.0.0.1 wegen Änderung Irmp Version auf
C-String.
mfg
Hugo Portisch schrieb:
> Ja, es gibt vom V-USB Paket das Example "hid-data".
Danke für den Tipp, schaue ich mir bei Gelegenheit an.
> @Frank M.: wenn ich alle Prokolle in irmp.c aktiviere werden ja alle> Protokolle mit kompeliert. Dann kann man aber nicht mehr verschiedene> Protokolle "OnTheFly" deaktivieren/aktivieren, oder?
Warum möchtest Du die on-the-fly deaktivieren/aktivieren?
> Dies wäre von Vorteil, denn dann werden einfach alle Protokolle> kompeliert und je nach IR-Diode usw per Host-Software> deaktivieren/aktivieren. -> AVR-Source muss nicht extra kompeliert> werden.
Du kannst einfach alle einschalten (das ist ja auch der Standard). IRMP
erkennt das von der FB gesandte Protokoll automatisch. Ich verstehe
jetzt nicht, warum man da welche abschalten soll - ausser man hat
zuwenig Platz im Flash. Und das hat nur Sinn "At-Compile-Time".
> Zu dem IR-Polling-Timer:> Er soll ja ~1/10000-1/15000 sein.> Rechne ich so richtig?: (1/10000) / (1/12000000) -1; = 1199 = 100µs?> für 1/15000:> (1/15000) / (1/12000000) -1; = 799 = 66,58µs?
Das wird per C-Preprocessor in der Beispiel-main.c doch automatisch
"ausgerechnet":
void
timer_init (void)
{
OCR1A = ((F_CPU / F_INTERRUPTS) - 1);
}
Also bei 12MHz und 10kHz :
OCR1A = ((12000000 / 10000) - 1);
Und das macht 1199 für 10 kHz <==> 100µs bzw 799 für 15 kHz <==> 66µs.
Deine obige Rechnung istg also soweit korrekt.
> Zählt der Timer von 0 zu 1199?
Jepp.
Warum musst Du da was im Delphi-Source berechnen? Warum muss der PC
wissen, mit welcher Interrupt-Frequenz der AVR läuft?
Gruß,
Frank
> Warum möchtest Du die on-the-fly deaktivieren/aktivieren?
Hab mir nur gedacht, dass dann im fertigem Paket eine Hex Datei mit
drinnen ist. Nicht jeder ist in der Lage den Source zu kompelieren.
Somit könnte man dann ein HEX-File haben und je nach dem die Protokolle
benutzen. Wenn es ausser Platzersparnis nix bringt bringt es eigentlich
wirklich nichts...
> Das wird per C-Preprocessor in der Beispiel-main.c doch> automatisch "ausgerechnet":
Ja, dass stimmt! Jedoch geht es bei mir (mit V-USB + TSOP1736) bei 115µs
besser als bei 100µs. Deswegen habe ich mir gedacht diesen Wert
einstellbar zu machen. Derzeit habe ich RC5, RC6, NEC + SIRCS
erfolgreich testen können. (Philips Prestigo sei Dank!)
> Warum musst Du da was im Delphi-Source berechnen? Warum muss der PC> wissen, mit welcher Interrupt-Frequenz der AVR läuft?
Danke für den Tipp! Die Berechnung könnte ich natürlich in den AVR
auslagern! Dann wird die AVR Frequenz am Host nicht mehr benötigt.
Hatte ja in Delphi direkt OCR1A berechnet, dieser neue Wert wurde per
USB runtergeschrieben.
Werd's so umbauen, dass einfach die µs runtergeschickt werden. OCR1A
kann dann ja im AVR berechnet werden.
Habe eh schon wieder einiges am Code herumgeschraubt...
21032010: Update
New
Timer0 (Startup Delay) wird nicht mehr benötigt. Die Timer1 Interrupt
Routine kann nun vom USB Transfer unterbrochen werden. Somit gibt es
keine Probleme mehr beim USB-Init mit dem Host. Das Erkennen von
IR-Codes scheint deswegen aber nicht beeinträchtigt zu sein. ;)
Sonstige Code Optimierungen...
Anbei der aktuelle Irmp+V-USB AVR Source und ein Update vom Delphi
Source.
Auch ist im AVR Source ZIP-File nun eine Schematik des Aufbaues
enthalten.
Auch ein kleines Bild wie man z.B. die IR-Codes am Host dann verwenden
kann.
mfg
Portisch
Update 26032010
Die vom Irmp dekodierten IR-Signale werden nun per USB-Interrupt zum
Host übertragen. Dadurch braucht man den AVR nicht mehr per Polling
abzufragen.
Die Tastenentprellung wird nun im AVR durchgeführt (MinRepeats). Bleibt
die Taste gedrückt wird der Counter durch das Irmp-Repeat-Flag erhöt.
Durch die Variable MinRepeats kann man festlegen wie oft der Befehl
wiederholt werden muss bis er wieder zum Host durchgelassen wird.
Die Anzahl der Widerholungen kann OnTheFly vom Host verstellt werden.
Ein guter Wert sollte so ca. 3-5 sein.
Anbei die neue AVR Version für Interrupt-Übertragung und eine neue Host
Software Demo. Der Code ist weniger geworden, da die Tastenentprellung
nun im AVR erledigt wird.
@Frank M.:
Ist es vielleicht möglich das Debugging auch per USB-Interrupt zu
erledigen? Habe hier eine Universal-Fernbedienung, bei der Irmp beim
NEC-Protokoll das Repeat-Flag erst nach dem 2. mal setzt. Daher kann ich
das nicht entprellen...
Vielleicht wenn man die '0' und '1' per Counter/Bitshift in ein Word
packt und dieses dann überträgt?
Beispiel des LOGs der Demo Software:
EDIT:
Für das Debug wäre es doch eine Idee die Irmp Struktur um 1 Byte/Word
für den Debug zu erweitern. Dann wird der Debug Wert einfach immer bei
einer Eingabe mitgesendet. Am Host kann man den Hexwert ja wieder auf
Text '0000101010...' zurück wandeln.
Hugo Portisch schrieb:
> @Frank M.:> Ist es vielleicht möglich das Debugging auch per USB-Interrupt zu> erledigen?
Du meinst Logging, nicht Debugging, oder?
Könnte gehen. Wie schnell bekommst Du denn Daten mit V-USB über die
Leitung? Bei eingeschaltetem Logging puffert IRMP die Daten bis zu einem
Timeout, bevor sie über UART ausgegeben werden. Damit beeinflusst die
Log-Ausgabe nur unwesentlich das Zeitverhalten der ISR.
> Habe hier eine Universal-Fernbedienung, bei der Irmp beim> NEC-Protokoll das Repeat-Flag erst nach dem 2. mal setzt. Daher kann ich> das nicht entprellen...
Es gab da ein Problem, auf das ich heute hingewiesen wurde: Ein
NEC-Repetition-Frame wird nur einmal erkant, danach werden weitere
Repetition-Frames verworfen. Ich habe das Problem glücklicherweise
schnell finden können und habe eben eine neue IRMP-Version erstellt -
liegt zum Download bereit, siehe
Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"> Vielleicht wenn man die '0' und '1' per Counter/Bitshift in ein Word> packt und dieses dann überträgt?
Könnte klappen, schau Dir bitte mal irmp_logIr() näher an. Hier müssten
die Aufrufe von irmp_uart_putc() durch geeignete USB-Funktionen ersetzt
werden.
> 19:07:41: Trained IR Code: Protocol : RC6, Address: 0x0027, Command:> 0x000C, Flags: 0x00
Sehe ich das richtig, dass Deine RC6-FB korrekt erkannt wird? Kannst Du
mir mal Hersteller und Bezeichnung nennen? RC6 ist ja (noch) ein kleines
Sorgenkind von IRMP.
> Du meinst Logging, nicht Debugging, oder?
Klar, mein Fehler!
> Könnte gehen. Wie schnell bekommst Du denn Daten mit V-USB über die> Leitung?
Ich glaube damit könnte es Probleme geben. Bei meinen Messungen mit dem
Oszi habe ich Zeiten von ~4-20ms gemessen.
> NEC
Danke! Werde die neue Version testen.
> RC6
Das müsste ein Nokia Sat-Rekorder sein (jedoch von meiner
Universal-Fernbedienung). Genauer Daten liegen mir davon nicht vor.
Hatte es mit z.B. auch mit Humax versucht, jedoch war hier das Problem
mit dem Repeat-Flag. Welches Gerät das genau ist muss ich in der
Geräte-Liste nachsehen (wenn ich die dann einmal finde)
> Logging
Hatte die Logging Funtkion irmp_logIr (uint8_t val) etwas falsch
verstanden. Nach deinem Hinweis habe ich es jetzt so verstanden:
Es kommt ein Signal über den Input Pin,
Daten werden in den Buffer: static uint8_t s_data[c_datalen]; geladen
Wenn "längere" Zeit kein Input mehr kommt wird der Byte Buffer (max.
c_datalen 700) in '0' und '1' per bitshift zerlegt und am Uart
ausgegeben.
Somit wird sich anbieten gleich s_data[c_datalen] per USB zu übertragen.
Die Zerlegung in nullen und einsen kann dann ja der Host erledigen.
Per Interrupt kann man maximal 8 Bytes auf einen Schwung übertragen.
Somit würden 88 Übertragungen für 700 Bytes notwendig sein. Dies wird
jedoch sowieso durch die for-Schleife abgekürzt.
Per Feature Request kann man die 700 Bytes schon "auf einen Schwung"
übertragen, doch dieser Wert muss dann vom Host angefragt werden.
Wird diese Ausgabe wirklich benötigt?
1
for(i=0;i<c_startcycles;++i)
2
{
3
irmp_uart_putc('0');// the ignored starting zeros
4
}
Da weis ich nähmlich nicht wieviele Interrupts zusammen kommen...
So könnte es einen Versuch wert sein:
1
uint16_ti;
2
staticuint8_ts_data_buffer[9];
3
4
s_data_buffer[0]=ReportIDLogging;
5
s_data_buffer[1]=0x00;
6
7
for(i=0;i<c_startcycles;++i)
8
{
9
while(!usbInterruptIsReady())usbPoll();// check if USB int is ready
10
usbSetInterrupt(&s_data_buffer[0],2);// send ReportID + IR data
11
}
12
13
for(i=0;i<(s_dataIdx-c_endBits+20)/8;++i)// transform bitset into uart chars
14
{
15
memcpy(&s_data_buffer[1]),&s_data[i*8],8);
16
17
while(!usbInterruptIsReady())usbPoll();// check if USB int is ready
18
usbSetInterrupt(&s_data_buffer[0],9);// send ReportID + IR data
Hugo Portisch schrieb:
> Nach deinem Hinweis habe ich es jetzt so verstanden:> Es kommt ein Signal über den Input Pin,> Daten werden in den Buffer: static uint8_t s_data[c_datalen]; geladen> Wenn "längere" Zeit kein Input mehr kommt wird der Byte Buffer (max.> c_datalen 700) in '0' und '1' per bitshift zerlegt und am Uart> ausgegeben.
Korrekt.
> Somit wird sich anbieten gleich s_data[c_datalen] per USB zu übertragen.> Die Zerlegung in nullen und einsen kann dann ja der Host erledigen.
Ja, genau. Bei UART werden 0en und 1en übertragen, weil man diese ganz
einfach per Copy&Paste mit jedem Terminalemulationsprogramm abgreifen
kann. Bei USB kann man natürlich auch das Array übertragen, damit
schrumpft dann die Datenmenge auf ein Achtel.
> Wird diese Ausgabe wirklich benötigt?>
1
for(i=0;i<c_startcycles;++i)
2
>{
3
>irmp_uart_putc('0');
4
>// the ignored starting zeros
5
>}
> Da weis ich nähmlich nicht wieviele Interrupts zusammen kommen...
Ja, die Ausgabe wird gebraucht. Und zwar gibt es in der Log-Funktion
eine Art "Störfilter", die erstmal abwartet, wie lang denn da der Puls
ist und einfach nur mitzählt. Erst wenn der Puls eine gewisse Breite
hat, wird mitprotokolliert, d.h. der Scan wird erst dann gestartet.
Obige Schleife schreibt den ersten Impuls des Frames. Du könntest aber
einfach den Wert von c_startcycles übertragen und der Host wandelt das
dann in die entsprechende Zahl von 0en.
> So könnte es einen Versuch wert sein:
Schick mir einfach mal einen Scan-Buffer, den Du über USB übertragen
hast. Ich sag Dir dann, ob der okay ist ;-)
Gruß,
Frank
Update 29032010
Es ist nun die neue Irmp Version vom 29032010 drinnen.
Bei NEC wird nun das Repeat-Flag richtig erkannt! Thx Frank M.
Das mit dem Logging über USB habe ich noch nicht geschafft. Mal sehen ob
das noch was wird...
Das is ja ma was, das ist genau das, was ich suche!! Bei mir
funktioniert das Igor Teil wegen 64 bit betriebssystem nicht...deswegen
suche ich eine Alternative und da scheint mir das genau richtig
Funktioniert schon alles (z.B. RC5)? Was ich noch nicht ganz beim
Überfliegen verstanden hab: wofür genau braucht man das Delphi Programm?
Ist vielleciht für euch eine ziemlich blöde Frage xD
Werde das morgen mal aufm Steckbrett aufbauen, hoffe ich habe alle Teile
da aber sieht gut aus. Bin schon sehr gespannt!
Gruß, Hendi
Danke für das Lob!
Das Delphi Programm ist eine Demo wie man mit dem USB IR Remote Receiver
Daten empfangen/senden kann.
Ich bin gerade dabei eine Demo für C++ Win32 Konsole (VS2008) zu
schreiben.
Auch werde ich noch eine DLL machen, die sich um die Handhabung der
Hardware kümmern soll. Durch die DLL kann man dann einfach mit dem
Empfänger arbeiten ohne mit HID herumzuspielen zu müssen. Die DLL kann
dann ja von anderen Programiersprachen (egal C++, C#,...) verwendet
werden.
RC5 geht sicher. Selber habe ich RC5, RC6, NEC & SIRCS probieren können.
Einfach die letzte Version vom 29032010 nehmen. Die Host-Software-Demo
dazu ist die: Irmp_V-USB_mit_INT_1.0.0.0.zip
mfg
Portisch
Da muss ich mich erst durchlesen...
Ich weis nicht ob WinLirc mit Plugins arbeitet, oder ob die
Hardwareunterstützung direkt in WinLirc enthalten ist.
Wenn es über ein Plugin (ähnlich wie bei Girder) läuft sollte man recht
einfach ein Plugin für Winlirc erstellen können, dass dann die "USB IR
Remote Receiver DLL" (die's "noch" nicht gibt) benutzt um mit der
Hardware zu reden.
Hugo Portisch schrieb:
> Das Delphi Programm ist eine Demo wie man mit dem USB IR Remote Receiver> Daten empfangen/senden kann.
Ah ok praktisch :)
Auch werde ich noch eine DLL machen, die sich um die Handhabung der
Hardware kümmern soll. Durch die DLL kann man dann einfach mit dem
Empfänger arbeiten ohne mit HID herumzuspielen zu müssen. Die DLL kann
dann ja von anderen Programiersprachen (egal C++, C#,...) verwendet
werden.
Nicht schlecht du entwickelst wirklich gerade das Rundumsorglos paket!
Darf ich fragen, wie weit du schon bist?
Naja, mit der DLL habe ich noch nicht angefangen.
Bin noch am Überlegen wie man das am besten Umsetzt.
Die C-Demo ist bis auf den Interrupt Receive eigentlich fertig. Für das
mit dem Interrupt-Receive kenne ich C zu wenig.
Zu Lirc:
Ist Linux, benutze nur Win. Man müsste dort einmal nachfragen ob die den
Empfänger aufnehmen wollen...
Zu Winlirc:
Es scheint so als unterstüzt Winlirc nur IR-Empfänger für RS232 - nix
USB.
Zur DLL überlege ich auch noch folgendes:
derzeit habe ich schon eine DLL die mit DVBViewer als Input-Plugin
läuft. Diese werde ich hernehmen und extra Funktionen exportieren, damit
diese auch für andere Programme verwendet werden kann. Auch überlege ich
in diese DLL einen Support von z.B. Girder zu implementieren. Mal sehen
was die Zeit bringt.
So,
hab jetzt schon einiges geschafft. Es gibt nun eine DLL die direkt im
DVBViewer & Girder verwendet werden kann.
Auch kann man per eigener "Auswerte-Software" die DLL laden und die
IR-Codes empfangen.
Somit muss man sich nicht um das Hardware-Handling kümmern.
Es ist eine Doku dabei, was den Gebrauch für Delphi und C erklärt.
Ob die C Doku ganz stimmt kann ich nicht sagen, da ich es zwecks zuwenig
C Kenntnissen nicht überprüfen kann!
Ob's auch auf 64Bit Systemem geht... hab ich nicht probiert!
Für Probleme/Kritik bin ich jederzeit bereit!
mfg
Portisch
Ich bin schon sehr gespannt!! leider hab ich im mOm wenig Zeit da ich
viele Klausuren schreibe. Ich möchte demnächst ein paar Teile bestellen
und ich hab gesehn dass ich doch nicht alles da habe sonst hätte ichs
schon aufgebaut. Welche Dioden hast du verwendet?
Dioden?
Die Z-Dioden sind 3,6V 0,5W
Bin mit der 1.0.0.3 schon fast fertig!
Zu dieser habe ich dann auch noch eine Demo-Console-Programm in C für
VS2008:
*Update 1.0.0.3*
Es wird nun DVBViewer, Girder und selbst erstellte Programme von der DLL
unterstützt.
Auch ein großes Docu Update...
Auch neu ein VS2008 Demo Console Programm wie man die DLL lädt und IR
Codes empfängt.
mfg
Portisch
Update 1.0.0.4
DLL:
Bugfix mit DVBViewer Settings/Option Dialog,
es kann nun im INI File ein Tastenunterdrückung eingestellt werden (Key
Suppression).
Default ist keine. Siehe USB_IR_Remote_Receiver_DLL_help.htm
AVR:
Optimierung der IR Code Erkennung für die PowerOn Funktion,
Bugfix wenn eine Taste länger als 255 Wiederholungen gedrückt war
mfg
Portisch
Hi,
Hab deinen Empfänger mal aufm Steckbrett nachgbaut. Wird unter Windows
XP SP3, Windows7 32 bit und Windows7 64 bit korrekt erkannt =)
Hab mir mal die Trial von Girder 5.nochwas runtergeladen, plugin in
Ordner und gestartet.Erst gings gar nicht, bis ich drauf gekommen bin ,
dass ich noch ein Häckchen bei dem IR Remote Receiver setzen musste. Jo
die Fernbedienungsaktionen werden einwandfrei un sehr schnell erkannt
und ich kann diese dann zuordnen. So wenn ich jetzt aber z.B. definiert
habe, dass wenn ich den Play knopf drücke, dass dann Play/Pause sein
soll und den Mediaplayer oder VLC aufmache und ein Film starte und jetzt
auf der Fernbedienung den Play bzw Pause Knopf drücke passiert nichts
aber in Girder sehe ich unten links, was gerade für ein Code übertragen
wird. Aber wie gesagt es bleibt alles ohne Funktion?! Woran kann das
kiegen? Ich kenne mich mit Girder leider gar nicht aus deswegen meine
Frage. Hoffe du kannst mir da weiterhlefen. Ansonsten TOP Arbeit!!
Gruß, Hendi
Michael M. schrieb:> girder ist seeehr verbreitet und außerdem auch vom hersteller> hervorragend dokumentiert...> du solltest wirklich alles wichtige finden können.
Also ich kriegs einfach nicht gebacken es funktioniert jetzt alles bis
auf Play/Pause im mediacenter und Mediaplayer. Woran leigt das denn das
kann doch wohl nicht sein?! Grad eine der wichtigsten Tasten. Ich habe
leider nicht gefunden wie ichs beheben kann sonst hätte ich nicht
gepostet, hoffe mir kann jemand helfen!
Gruß, Hendi
Mhm also ich verwende Girder 5 und ich hab keine Ahnung, wo diese
Funktion sein soll sry. ich hab gerade alles durchgeschaut und nichts
gefunden. Ich bin mittlerweile sowet, dass es ansatzweise funktioniert
wenn ich Play und Pause auf zwei getrennte Tasten lege aber es
funktioniert auch nicht richtig, da es eher Zufall ist ob er Pause oder
Play macht.Es sieht dannn so aus als würde man Pause drücken und sofort
wieder Play und das die ganze Zeit.
Soo also ich habs jetzt einigermaßen hingekriegt. Zwar nicht mit dem
Window Picker sondern: Hab mir eine GML fürs Windows 7 Mediacenter
runtergeladen und dann im Expertenmodus nochmal alles neu eingestellt.
Ich hab jetzt festgestellt, dass man einfach nur eins von beiden
definieren darf (glaub ich hab jetzt Pause genommen) und das andere
einfach leer lässt. Es ist zwar so sehr empfindlich aber es geht. D.h.
man muss entweder nur ganz kurz oder länger drücken wenn man ganz
"normal" drückt funktionierts nicht wirklich.Wie bekommt man das ganze
denn ein bisschen unempfindlicher, es reagiert insgesamt sehr
empfindlich?
Hendi schrieb:> Es ist zwar so sehr empfindlich aber es geht. D.h.> man muss entweder nur ganz kurz oder länger drücken wenn man ganz> "normal" drückt funktionierts nicht wirklich.Wie bekommt man das ganze> denn ein bisschen unempfindlicher, es reagiert insgesamt sehr> empfindlich?
Was für eine Fernbedienung ist das? Normalerweise erkennt IRMP
Frame-Wiederholungen, die aufgrund eines längeren Tastendrucks entstehen
und setzt dann das entsprechende Bit IRMP_FLAG_REPETITION in der
flags-Variablen der IRMP_DATA-Struct.
Ich weiss jetzt nicht, ob Hugo das Flag gegenprüft, also alle Frames mit
gesetztem Bit IRMP_FLAG_REPETITION unterdrückt und damit dann die Tasten
"entprellt". Wenn nicht, sollte man wie im IRMP-Artikel
http://www.mikrocontroller.net/articles/IRMP
(nach IRMP_FLAG_REPETITION suchen)
angegeben vorgehen.
Gruß,
Frank
Ja, die 1.0.0.4 AVR Version hat einen Fehler mit der Entprellung!
Hab's selber erst später gemerkt, da durch die Tastenunterdrückung (Key
Suppression) mir das nicht aufgefallen ist. ;)
Aber heute ist ein guter Tag! Ist sich genau mit einer neuen
Irmp-Version ausgegangen!
>> Update 1.0.0.5 (28.04.2010)
1
28.04.2010:
2
DLL: v1.0.0.5, Added possibility to flash or update the device firmware direct with the USB IR Remote Receiver settings/option dialog.
3
AVR: Bugfix code repeats
4
Updated Irmp to 28.04.2010
5
Added modified booloadHID to be able to flash the device without setting a jumper or needed disconnect/reconnect of the device
6
The booloadHID will boot if:
7
+ no USB IR Remote Receiver firmware is flashed
8
+ jumper is set
9
+ the firmware itself is reseting the device for bootloader modus
Mit dem modifizierten Bootloader kann nun einfach einen neue Firmware
runter gespielt werden ohne den Jumper setzen zu müssen oder das Device
aus/ein zu stecken.
Da es hier im Forum wirklich nicht schön ist Software-Revisionen
unterzubringen habe ich nun das Projekt in den Artikeln angelegt:
USB IR Remote Receiver
Bei Fragen, Wünschen oder sonstiges bitte einfach weiter hier rein
schreiben!
Hi gute Idee mit dem Eintrag! Ist jetzt alles schön übersichtlich. Also
ich habe deinen neuen Code gerade nochmal getestet und es funktioniert
jetzt alles wunderbar. auch Play/Pause wo er vorher immer durcheinander
gekommen ist. Lässt sich nun alles sehr komfortabel steuern. Danke für
deine tolle Arbeit!!!
Gruß, Hendi
Schön zu hören ;)
Wollte den Artikel schon früher einstellen, hatte aber bis jetzt nicht
die Motivation dazu da es ganz schön viel Arbeit ist.
Naja, die größte Arbeit ist nun geschafft!
Hugo Portisch schrieb:> Da es hier im Forum wirklich nicht schön ist Software-Revisionen
so?
- du kannst eine datei im wiki hochladen, musst sie aber nicht mal
einstellen. man kann auch direkt darauf verlinken.
- es gibt einen svn-server, der einen direkten zu einem tarball aus
deinem projekt bereitstellt.
Hugo Portisch schrieb:> Da es hier im Forum wirklich nicht schön ist Software-Revisionen> unterzubringen habe ich nun das Projekt in den Artikeln angelegt:>> USB IR Remote Receiver
Sehr schön, ich hsbe nun im IRMP-Artikel direkt mal einen Link darauf
eingefügt :-)
Michael M. schrieb:> - du kannst eine datei im wiki hochladen, musst sie aber nicht mal> einstellen. man kann auch direkt darauf verlinken.> - es gibt einen svn-server, der einen direkten zu einem tarball aus> deinem projekt bereitstellt.
Ja, das kann man natürlich so machen.
Ein eigener Artikel hat aber einen unschlagbaren Vorteil: er bietet
sämtliche notwendigen Infos in kompakter Form an. Ich denke da nur an
den Thread http://www.mikrocontroller.net/topic/156661#new, der ohne
eigenen (begleitenden) Artikel im Chaos versinken würde.
SVN ist eigentlich primär dafür gedacht, mit mehreren Leuten
"konkurrierend" an ein und demselben Quellcode zu arbeiten. Zur
Präsentation von Informationen ist SVN eher weniger geeignet. Daher hat
so ein eigener Artikel durchaus seine Berechtigung.
Gruß,
Frank
Frank M. schrieb:> Ein eigener Artikel hat aber einen unschlagbaren Vorteil: er bietet
ja!
> SVN ist eigentlich primär dafür gedacht, mit mehreren Leuten> "konkurrierend" an ein und demselben Quellcode zu arbeiten. Zur
und ja!
> Präsentation von Informationen ist SVN eher weniger geeignet. Daher hat> so ein eigener Artikel durchaus seine Berechtigung.
ich hab auch nie gegen den artikel gewettert. mein wettern galt nur der
aussage, man können hier keinen code vernünftig preisgeben.
das projekt an sich finde sehr gelungen.
Super Projekt!
Aber...
>Wenn eine neue Irmp Version kompiliert wird sollte das Build Datum von Irmp>in der main.c geändert werden:>//enter here the Irmp build date:>const char IrmpVersion[] = "28.04.2010";
Ich meine das geht auch per _DATE_ also ein vordef. DEFINE...
>> Ich meine das geht auch per DATE also ein vordef. DEFINE...
Hatten wir schon mal, ist nicht der Build Date vom Projekt sondern das
Release Datum von Irmp!
Dewegen muss dieses manuell eingegeben werden.
Eventghost....
Es ist anscheinend auch Möglich DLLs zu laden und CallBacks (Empfang von
IR-Codes) auszuwerten. Somit braucht man nicht direkt mit dem HID-Gerät
arbeiten.
Jedoch ist das Plugin dann in Python zu programmieren, da habe ich
leider Überhaupt keine Idee wie man das Umsetzt.
Vielleicht kann das ja jemand hier aus dem FF - ich kann und werde auf
jeden Fall Hilfe dazu geben wie man mit der DLL umgeht!
Hugo Portisch schrieb:> Es ist anscheinend auch Möglich DLLs zu laden und CallBacks (Empfang von> IR-Codes) auszuwerten. Somit braucht man nicht direkt mit dem HID-Gerät> arbeiten.
Und was ist mit dem HID Plugin, vlt ist ja schon alles da? Ich denk dein
Teil ist ein HID Gerät?
Also EventGhost->HID-Plugin hinzu(schon dabei)->deine Hardware
Werde mir das mit Eventghost noch genauer ansehen.
Bin mir nicht sicher wie das mit dem HID-Plugin genau gehen soll und ob
es besser ist geich über die DLL zu gehen.
So,
habe jetzt einmal was für EventGhost fertig.
Die Datei einfach im EventGhost\Plugins\USBIRRemoteReceiver entpacken.
Die DLL muss sich dann auch in diesem Ordner befinden.
Jedoch habe ich EventGhost selber noch nie benützt und kann deswegen
nicht sagen ob das Plugin schon so fertig ist.
(kleiner Tipp: beim ersten Laden des Plugins kann man den
Settings/option Dialog nicht öffnen! Zuerst zumachen und dann nocheinmal
auf Configure gehen)
Mal sehen wie's geht!
Habe heute ein kleines Update im Artikel
09.05.2010: USB IR Remote Receiver
vorgenommen!
Neu ist ein Plugin für EventGhost,
DLL v1.0.0.6, kleiner Bugfis mit Standby,
Docu Update
Hi wollte hier mal ein paar Bilder von meinem aktuellsten Empfänger
reinstellen. Denke damit kann sich jeder gut vorstellen, wie so ein
fertiger Empfänger aussehen könnte. Die Platine ist wie ihr seht
doppelseitig aber hat noch ein paar kleinere Mängel^^. Werde versuchen,
diese zu beheben und die Größe noch weiter zu drücken.(Die erste Version
war ungefähr 4 mal so groß aber es ist immer noch Potential vorhanden
:D)
Gruß, Hendi
Hallo!
Ich hab da mal ne Frage betreffend der Power ON/OFF Funktion durch den
Opptokoppler. Wie soll das Gerät den PC einschalten, wenn der PC
heruntergefahren ist. Die Schaltung hat doch garkeine Spannung um zu
funktionieren. Oder übersehe ich da etwas ?
mfg,
Bjoern
Tishima schrieb:> Die Schaltung hat doch garkeine Spannung um zu> funktionieren. Oder übersehe ich da etwas ?
Kommt drauf an wie sie versorgt wird. Viele Mainboards bieten die
Möglichkeit auch im ausgeschalteten Zustand (eine oder mehrere)
USB-Buchsen mit Spannung zu versorgen.
Micha schrieb:> Kommt drauf an wie sie versorgt wird. Viele Mainboards bieten die> Möglichkeit auch im ausgeschalteten Zustand (eine oder mehrere)> USB-Buchsen mit Spannung zu versorgen.>
Ah, Danke für die Info wusste ich noch garnicht, mir ist so ein
Mainboard noch nicht untergekommen.
gruß,
Bjoern
Hi,
hab gerade den Empfänger auf dem Steckbrett aufgebaut - was soll ich
sagen? "Works like a charm!"
Was mir zur Hardware eingefallen ist: Wie wäre es, die Firmware auf den
Attiny85 zu portieren? Die Pins würden ausreichen und der Quarz
wegfallen. Ich würde schon fast behaupten, das Teil auf 2cm²
Platinengröße zu bringen.
Als Empfängerbaustein dürfte sich der "SFH 5110-36" von Reichelt
anbieten, der doch einiges kleiner als die TSOP ist und bei der
Empfindlichkeit mithalten dürfte.
Einziger Knackpunkt (nach dem Überfliegen des Quelltextes): der nicht
vorhandene 16-Bit-Timer.
Noch eine kleine Frage an Hugo: Gibt es zur DLL auch einen Quelltext?
Wäre auf jeden Fall interessant :)
Viele Grüße
Chris
Chris R. schrieb:> Was mir zur Hardware eingefallen ist: Wie wäre es, die Firmware auf den> Attiny85 zu portieren? Die Pins würden ausreichen und der Quarz> wegfallen. Ich würde schon fast behaupten, das Teil auf 2cm²> Platinengröße zu bringen.
Müsste gehen.
> Einziger Knackpunkt (nach dem Überfliegen des Quelltextes): der nicht> vorhandene 16-Bit-Timer.
Nicht schlimm, dann nimmst Du halt einen 8-Bit-Timer. Wichtig ist
lediglich, dass F_INTERRUPTS exakt ist und einen Wert möglichst zwischen
10000 und 15000 hat.
Gruß,
Frank
Muss mich korrigieren, nach Studium von
http://www.obdev.at/products/vusb/index-de.html
klappts nicht mit dem ATTiny85, jedenfalls nicht ohne Quarz.
Zitat:
"Can be clocked with 12 Mhz, 15 MHz, 16 MHz or 20 MHz crystal or from a
12.8 MHz or 16.5 MHz internal RC oscillator."
Da der interne Oszillator vom ATTiny85 nur max. 8MHz liefert, ist der
Quarz zwingend erforderlich.
Gruß,
Frank
> Ah, Danke für die Info wusste ich noch garnicht, mir ist so ein> Mainboard noch nicht untergekommen.
Das nennt man dann 5VSB. Das bedeutet das 5V auch im ausgeschalteten
Zustand mit kleiner Anschlussleistung (0,5-2W) zur Verfügung stehen.
Neue Mainbaords & ATX Netzteile haben das eigentlich von Haus aus
drinnen. Früher musste, falls vorhanden, eventuell ein Jumper gesetzt
werden.
> "Can be clocked with 12 Mhz, 15 MHz, 16 MHz or 20 MHz crystal or from a> 12.8 MHz or 16.5 MHz internal RC oscillator."
Ja, da wird VUSB nicht mitmachen! Hatte bei den ersten Versuchen die
Fusebits falsch gesetzt und der Atmega8 ist mit dem internen Oscillator
gelaufen. Da wurde dann beim Anstecken kein USB-Gerät erkannt.
Jedoch ist der ATiny85 schon interessant. Werd mal sehen ob ich die SOIC
Version (kostenlos) bekomme.
> Noch eine kleine Frage an Hugo: Gibt es zur DLL auch einen Quelltext?> Wäre auf jeden Fall interessant :)
Gibt's schon, aber "noch" NonPublic ;)
Aber die DLL macht eigentlich das gleiche wie die Interrupt Demo was
weiter oben zu finden ist:
Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)"
Die anderen Demos im Complete Packet zeigen wie man die DLL selber
nutzen kann. Man braucht sich dann nicht mehr um die Kommunikation
Host <-> Gerät kümmern.
Portisch
Hugo Portisch schrieb:
> Ja, da wird VUSB nicht mitmachen! Hatte bei den ersten Versuchen die> Fusebits falsch gesetzt und der Atmega8 ist mit dem internen Oscillator> gelaufen. Da wurde dann beim Anstecken kein USB-Gerät erkannt.
das ist kein Problem, es gibt eine Version von V-USB die direkt auf die
Tinyx5 zugeschnitten ist.
Mit der Taktkalibrierung per USB-Framelength braucht man sich auch über
das Einstellen der PLL keinen Kopf mehr machen.
> Gibt's schon, aber "noch" NonPublic ;)> Aber die DLL macht eigentlich das gleiche wie die Interrupt Demo was> weiter oben zu finden ist:
Danke, werde ich mir mal anschauen.
Viele Grüße
Chris
Hi,
hier mein erster Versuch, den Empfänger auf den Attiny85 zu portieren.
Leider will das Teil noch nicht so recht.
Ich weiß zwar, wo der Fehler liegt, habe aber keine Möglichkeit
gefunden, ihn zu beseitigen:
Der Timer scheint V-USB auf dem AVR so stark zu beeinflussen, dass er
nicht mehr erkannt wird.
Ob es mit der Kalibrierung zu tun hat, kann ich nicht sagen, vermute
aber eher nein, da es auch nicht funktioniert, wenn ich timer_init()
nach dem Aufruf von calibrateOscillator() (Zeile 471) aufrufe.
Ich habe auch schon versucht, den Timer erst nach einigen Durchläufen
der Endlosschleife in main() zu initialisieren, mit selbem Ergebnis.
Kommentiere ich timer_init(); aus, wird das Device am USB erfolgreich
erkannt.
Da ich anfangs vermutet habe, dass der ISR nicht stimmt, lasse ich im
Interrupt PB0 togglen, dabei kommt ein Rechteck von ca. 5,3kHz raus, was
in etwa den 10kHz Abfragerate entspricht.
Habe zusätzlich zu meinen veränderten Quellen auch einen Standard-Diff
rangehängt (Ordner diff), damit ihr meine Änderungen nachvollziehen
könnt.
Vielleicht fällt einem noch etwas ein, wie man das Teil zum fliegen
bring ;)
Viele Grüße
Chris R. schrieb:> Da ich anfangs vermutet habe, dass der ISR nicht stimmt, lasse ich im> Interrupt PB0 togglen, dabei kommt ein Rechteck von ca. 5,3kHz raus, was> in etwa den 10kHz Abfragerate entspricht.
"In etwa" hört sich so an, als ob der ATTiny mit internem Oszillator
läuft... mit Quarz sollten da schon 5,0kHz rauskommen oder?
Gruß,
Frank
Frank M. schrieb:> "In etwa" hört sich so an, als ob der ATTiny mit internem Oszillator> läuft... mit Quarz sollten da schon 5,0kHz rauskommen oder?
In etwa, weil sich der AVR anhand der USB-Framelänge kalibriert
(zumindest sollte er das). In etwa auch, weil ich bei einem Vortteiler
von 8 und dem 8-Bit Timer nicht genau auf 10kHz komme. Entweder bisschen
drunter oder drüber.
Hi, ich bins mal wieder. Da die Girder Testversion schon länger
abgelaufen ist wollte ich mal Eventghost probieren. Aber das Programm
macht mich grad wahnsinnig!! Hat jemand, der sich mit dem Proggi
auskennt schon mal den Eventghost Plugin ausprobiert?
Ich will am Anfang einfach mal, dass im Mediacenter Pause gemacht wird,
wenn ich einen bestimmten Knopf auf der FB drücke aber egal was ich
mache es geht nix ich kann kein Makro, Ereignis oder sonst noch was
konfigurieren, er zeigt kein gesendeten IR Code an oder wie läuft das
eigentlich in dem Programm? Ich finde immer nur total Oberflächliche
Anleitungen, die anscheinend vorraussetzen, das man das Programm kennt.
Ihh habe allerdings keine Ahnung davon aber das muss ja funktionieren,
schließlich wird es immer in den höchsten Tönen gelobt?!
Naja vielleicht kann ja jemand mal einen Tipp abgeben bzw. sagen,ob das
überhaupt funktioniert.
Gruß, Hendi
Also mit EventGhost funktioniert das alles einwandfrei hatte nur zuerst
Probleme mit der Benutzerkontensteuerung, die hat geblockt jetzt
funktioniert alles, wie es soll!
hallo!
ich habe ein problem mit dem remote-receiver. vorweg: ich bin kein
elektronik-profi ;-)
die schaltung habe ich schon gelötet. wenn ich den receiver per usb
anschließe, wird auch schon mal ein unbekanntes usb-gerät angezeigt. der
usb standard scheint also schon mal zu stimmen.
nun habe ich versucht den receiver per ponyprog2000 zu programmieren.
ich habe die anleitung von portisch schritt für schritt befolgt. beim
auslesen der fuse-bits schon das erste prob: anfangs hat er immer
"missing device" gemeldet; nach ein paar mal "retry" hat er aber die
bits ausgelesen. ich habe die bits richtig gesetzt und dann "write"
geklickt. das hat dann auch funktioniert. jedenfalls kam keine
fehlermeldung.
danach habe ich auf "write all" für das programm geklickt. anfangs ging
es wieder nicht, aber nach ein paar mal "retry" hat es funktioniert und
er hat geschrieben, verifiziert,...und dann kam "write failed".
ich habe den receiver nun schon x mal abgesteckt, den reset-pin gesetzt
usw, aber er reagiert nun nicht mehr. wenn ich bei den fuse-bits auf
"read" klicke, kommt immer "missing device".
was könnte da nicht stimmen? wäre für ein paar tipps wirklich sehr
dankbar!
habe alles nach der liste von portisch gebaut. IC ist also ein atmega8.
zickzack schrieb:> was könnte da nicht stimmen? wäre für ein paar tipps wirklich sehr> dankbar!
Den Fehler in PonyProg suchen.
"Calibration" durchgeführt ?
pk
hi,
ja, calibration habe ich durchgeführt. eben genau die anleitung von
portisch befolgt.
den lpt-port hatte ich beim ersten versuch auf SPP. dann habe ich auf
EPP+ECP umgestellt, jedoch hat es deswegen auch nicht funktioniert.
zickzack schrieb:> den lpt-port hatte ich beim ersten versuch auf SPP. dann habe ich auf> EPP+ECP umgestellt, jedoch hat es deswegen auch nicht funktioniert.
Ich nutze PonyProg mit dem seriellen Interface.
War für mich schneller und einfacher zu bauen.
ParPort mag ich nicht.
pk
Hallo Leute, ich kann nur sagen: Tolles Projekt!
Ich hab mal alles fix zusammen gebaut und was soll ich sagen, es hat auf
Anhieb funktioniert. Ich bin über die Suche nach einer Möglichkeit eine
FDC-3402 Tastatur unter WIN und Linux zu betreiben, auf dieses schöne
Projekt gestoßen. Leider habe ich zu meinen Lötkolben ein besseres
Verhältnis, als zur AVR Programmierung. Kann mir jemmand einen Tipp
geben, was ich machen müsste, damit der IRMP Empfänger sich wie eine
ordinäre Tastatur unter Windows bzw. Linux verhält?
Vielen Dank.
Zur Tasttaur Simulation muss man beim USB IR Remote Receiver eine
Hostsoftware verwenden. Z.B. Girder.
Da kann man einstellen welcher empfangene IR-Code z.B. ein 'a' oder 'b'
ist.
Oder man macht sich eine eigene kleine Software mit der man die Codes in
Tastendrücke umsetzt.
Hugo Portisch schrieb:> Oder man macht sich eine eigene kleine Software mit der man die Codes in> Tastendrücke umsetzt.
Das ist halt meine Schwäche ;-)
Mit der Tastatur Simulation ist mir schon klar, ich habe auch schon mit
EventGhost die Sache halbwegs unter Windows zum laufen bekommen. Aber
wie ich das Ganze unter Linux zum Laufen kriege, da bin ich noch
ziemlich planlos, zumal der USB IR Remote Receiver nicht von lirc
erkannt wird und es auch noch ohne X, in der Konsole funktionieren soll.
In meinem unwissenden Leichtsinn dachte ich, dass es kein größeres
Problem seien sollte, die AVR Firmware so zu kompilieren, das sich der
AVR als HID Keyboard beim Betriebssystem anmeldet und dann die
entsprechenden Keycodes für eine USB Tastatur sendet.
Hi,
sorry for using english, I don't know any German. I am the winlirc
developer. The winlirc plugin design is really flexible, so you can do
really what you want internally. The only thing you must do is spit out
the name of the button on the remote when a button is pressed, how you
get there doesn't really matter. It looks like you guys have spent a
great deal of effort writing your own decoder for many remotes ? If you
can supply the raw pulse/space lengths we can easily decode all
protocols with winlirc :)
Hi Ian,
it's nice to hear that you are interrested. You are invited to take a
look at this Project, it's cheap to build and work very well. The output
of the USB IR Remote Receiver is a with IRMP decoded IR Protocol
Information
(not a Pulse or. Space lengths).
Perhaps can you support the USB IR Remote Receiver in your lirc Software
in the Future? (I hope it) Sorry for my bad english. ;-)
@Ian
I was already taking a look to Winlirc. But I was thinking it support
only RS232 IR receiver.
USB IR Remote Receiver is an USB-HID Device.
So no virtual COM Port or something else is used.
Also I didn't found anything how to write plugins for Winlirc.
Would be nice if the receiver can be supported by Winlirc.
The included DLL already support NATIVE, DVBViewer, Girder, EventGhost.
I can include also Winlirc support in the DLL if I know how to...
Take a look to the included demos how to use this receiver.
The receiver will send the native IRMP data to the host:
irmp_data_p->protocol
irmp_data_p->address
irmp_data_p->command
irmp_data_p->flags
The handling of the command(s) is done by the host.
Kann mir jemand verraten welche Fusebits im AVRStudio setzen muss. Am
bestens wäre ein Screenshot. Ich denke das macht schon Sinn, da das
Projekt mit dem AVR-Studio umgesetzt ist. Danke für eure Hilfe.
Hallo,
feine Sache dieser IR Decoder, aber hat es denn nun schon mal jemand
unter Linux "nativ" ( ohne Tools im wine o.ä. ) zum laufen bekommen oder
gibt's vielleicht schon eine lirc Unterstüzung?
Hi,
gibt es vielleich schon eine Quelle, wo alles diesbezüglich
zusammengefasst ist? Ich würde es auch gerne nachbauen, habe aber leider
keine Zeit ein eigenes Layout zu entwerfen. Ich bin bislang immer ganz
gut mit dem IgorPlug gefahren, aber seit win7(64bit) kann ich diesen
nicht mehr verwenden. Wäre also super nett, wenn mir Jemand eine
Zusammenfassung schreiben kann, wie weit die Entwicklung dieses tollen
Adapters ist und ob dieser mit Girder unter win7(64bit) funktioniert.
Wenn ja dann wäre ich auch dankbar für jegliche Layouts mit Stücklisten
(egal wie viele Layer die Platine hat und wie klein die SMD-Bauteile
sind, ich kann alles verbauen, selbst tqfc Gehäuse. Habe auf der Arbeit
eine Durchlichteinheit)
Würde mich dafür auch erkenntlich zeigen und euch einige Platinen zum
Selbstkostenpreis mitbestücken.
Danke!
Hi, also es gibt sowei ich weiß auch einen Artikel, wo alles drin steht.
Außerdem istr in dem zip Archiv eine Anleitung enthalten. Funktionieren
tut das ganze wirklich einwandfrei, ich benuttze es mitlerweile mit
EventGhost, da dieses Programm kostenlos ist. Mit der Testversion von
Girder hat aber auch alles sehr gut funktioniert. SMD Layouts habe ich
mittleriwel über 3 versheidene.
1. Sehr großzügig geroutet, mit richtiger ISP Buchse Maße ca 4x4cm
dinseitig
2. so groß, wie ein USB Stick, noch recht viele Vias, Programmierung
über Platine möglich aber nicht mit ISp Adapter, doppelseitig, mit THT
IR Empfänger
3 neuestes Layout, aber bisher noch nicht getestet, da Bauteile fehlen,
sehr weinge Vias trotz übersichtlichem Layout, doppelseitig, noch
kliner/kürzer als variante 2, mit SMD IR Empfänger
Frohe Weihnachten, Hendi
Chris R. schrieb:> Autor:>> Chris R.> (hownottobeseen)
Hi Chris,
I finded the resolution to your problem. You must use these code:
void usbEventResetReady(void) {
cli(); // usbMeasureFrameLength() counts CPU cycles, so disable
interrupts.
calibrateOscillator();
sei();
I recommend check the code on this place:
else if ( DoWriteReport == SetIRPollingTime ) {
OCR1A = (F_CPU PRESCALER ((data[2] << 8 ) | data[1])) - 1;
You used Timer 0 and here is OCR1A, you should use the PRESCALER here
maybe.
P.
Hallo!
Ich hab mit viel Interesse den Großteil des Beitrages und Wikis gelesen.
Nun hätte ich noch ein paar Fragen:
- Muss zu dem Empfänger zwingend Sichtkontakt bestehen oder kann ich ihn
einfach hinter den Rechner legen / ihn aus einer Lüfteröffnung "gucken"
lassen? (danach richtet sich dann ja auch ob ich es an einen internen
oder externen USB Anschluss klemme)
- Ist der Jumper für das erstmalige Bespielen mit PonyProg2000 notwendig
oder kann man ihn mit der "neuen" bootloadHID komplett weglassen?
- Wie ich gelesen hab, reicht der Flashspeicher des Atmega8 nicht mehr
für die komplette Unterstützung von Irmp. Gibt es eine Alternative, die
von der Schaltung genauso verbaut wird und wo das gesamte Irmp in den
Flashspeicher passt?
- Ich hab keine anderen Möglichkeiten als die Schaltung auf einer
Lochrasterplatine zusammenzubauen, hat jemand für diesen Fall ein klein
bauenendes Layout was er zur verfügung stellen würde (mit PowerON)? Auf
welche Abmaße kommt man auf einer Lochrasterplatine ca.? Ich würde gern
gleich bei Reichelt noch ein kleines passendes Kunsstoffgehäuse o.ä.
mitbestellen.
Ich würde mich über Anregungen freuen!
Willi
Hallo!
Das Projekt klingt wirklich interessant. Hatte mir grade einen
Igor-USB-IR-Empfänger gebastelt - um dann festzustellen, dass dieser mit
meinem Win7 x64 nur über Umwege funktioniert.
Hat jmd schon irgendwo ein Layout bereitgestellt, dass ich nachbauen
könnte?
Auf der Projektseite selbst sieht man nur ein Foto einer fertigen
Lochraster-Platine.
Ich wär auch dran interessiert, wenn jmd einige Platinen ätzen möchte :)
Außerdem wollte ich fragen ob man bei dem Design noch ne LED einbauen
könnte, die den Empfang von Infrarotsignalen bestätigt (blinkt) -
zumindest hatte meine jetzige Version (Igor) diese Funktion
Gruß
Mock
Habe Heute einmal ein Update des Artikels gemacht!
USB IR Remote Receiver> - Muss zu dem Empfänger zwingend Sichtkontakt bestehen oder kann ich ihn> einfach hinter den Rechner legen / ihn aus einer Lüfteröffnung "gucken"> lassen? (danach richtet sich dann ja auch ob ich es an einen internen> oder externen USB Anschluss klemme)
IR braucht Sichtkontakt. Ist ja Licht - und nicht Funk!
Es kann sein, dass es hinten auch geht. Vielleicht ein kleiner Spiegel
dahinter um das IR Licht umzulenken!?
> - Ist der Jumper für das erstmalige Bespielen mit PonyProg2000 notwendig> oder kann man ihn mit der "neuen" bootloadHID komplett weglassen?
Mit dem "neuen" Bootloader kann man ihn komplett weglassen! Man
programiert nur den Bootloader mit PonyProg2000 auf den AVR.
Die eigentlich Anwendung wird dann über die Flash-Option draufgespielt.
> - Wie ich gelesen hab, reicht der Flashspeicher des Atmega8 nicht mehr> für die komplette Unterstützung von Irmp. Gibt es eine Alternative, die> von der Schaltung genauso verbaut wird und wo das gesamte Irmp in den> Flashspeicher passt?
Vielleicht ein Atmega16!? Der hat 16KB Speicher. Oder ein Atmega32 mit
32KB Speicher. Alle Protokolle wird man aber nie brauchen, deswegen
sollte der Atmega8 ausreichen.
> - Ich hab keine anderen Möglichkeiten als die Schaltung auf einer> Lochrasterplatine zusammenzubauen, hat jemand für diesen Fall ein klein> bauenendes Layout was er zur verfügung stellen würde (mit PowerON)? Auf> welche Abmaße kommt man auf einer Lochrasterplatine ca.? Ich würde gern> gleich bei Reichelt noch ein kleines passendes Kunsstoffgehäuse o.ä.> mitbestellen.
Es ist beim Beitrag ein Foto von einem Lochrasteraufbau dabei. Ich habe
es auch einfach nach Schaltplan aufgebaut.
> Hat jmd schon irgendwo ein Layout bereitgestellt, dass ich nachbauen> könnte?> Auf der Projektseite selbst sieht man nur ein Foto einer fertigen> Lochraster-Platine.> Ich wär auch dran interessiert, wenn jmd einige Platinen ätzen möchte :)> Außerdem wollte ich fragen ob man bei dem Design noch ne LED einbauen> könnte, die den Empfang von Infrarotsignalen bestätigt (blinkt) -> zumindest hatte meine jetzige Version (Igor) diese Funktion
Ich selber habe kein Layout erstellt. Vielleicht später noch einmal.
kommt drauf an ob wir hier einen PCB-Protoyper bekommen...
Für die Led-Anzeige müsste es reichen wenn du die Kathode der Led an dem
IR Dioden Ausgang hängst. Die Led Anode über einen Widerstand (~560-1000
Ohm) auf +5V hängen. Den Widerstand halt nicht zu gering auswählen
ansonsten kann es zu Problemen der Stromversorgung über den USB-Port im
Ruhezustand/Standby kommen.
Hallo und Danke für das Klasse Projekt.
Aufgebaut, geflasht , funktioniert ....
Leider nur unter Windows :-(
Ich würde das Teil gern unter Linux einsetzten da ich bis jetzt mit
(fast) allen anderen Varianten mehr oder weniger gescheitert bin.
(es funktioniert nur ein UIRT2 über einen USBtoSerial-Wandler, aller
andere mit MCE oder imon nur teilweise)
Jetzt dachte ich das Teil hier wäre DIE Lösung. Leider auch noch nicht.
Beim einstecken kommt das im Log :
1
Jan 30 11:18:31 ion kernel: [ 1735.172036] usb 4-1: new low speed USB device using uhci_hcd and address 12
2
Jan 30 11:18:31 ion kernel: [ 1735.356189] usb 4-1: configuration #1 chosen from 1 choice
3
Jan 30 11:18:31 ion kernel: [ 1735.411161] generic-usb 0003:16C0:05DF.000A: hiddev96,hidraw0: USB HID v1.01 Device [www.dvbviewer.info USB IR Remote Receiver] on usb-0000:00:1d.2-1/input0
Unter /proc/bus/input/devices wird leider kein neuer Eintrag erzeugt.
Aber es erscheint ein :
Doch wie kann ich das nutzen ?
Mit inputlircd scheint es nicht zu gehen.
Hat jemand eine Idee wie ich das unter Linux benutzen kann ?
Vielen Dank Ronald
Hi!
Ich habe mich mal rangesetzt und die Schaltung Rasterplatinen-kompatibel
aufgezeichnet. Ist die so korrekt? Hatte noch keine Gelegenheit die
nachzubauen. Alle Leitungen sind auf der Unterseite der Platine wobei
die roten isolierte Kabel sein sollten, da sie die dunkelblauen sonst
kreuzen. Die Widerstände R2-R4 dienen gleichzeitig als Brücken.
Ich hoffe der Plan kann einigen weiterhelfen
Hoppla... da hab ich doch glatt die Pins des TSOP vertauscht :)
Für meine Zwecke verbaue ich die die IR Diode auf der Unterseite und
klappe sie um, so dass sie von der Platine weg zeigt. Alternativ kann
man ja auch Pins hinlöten und die IR Diode über ein Kabel verbinden.
Habe gleich eine korrigierte version geuploadet
ich schrieb:> Ob die 16k reichen weiß ich allerdings nicht.
Zur Not gibt es auch noch den ATmega328 mit 32K.
Ist alles pinkompatibel, da eine Familie. Aber ich glaube, dass Du mit
den 16K dicke auskommst :-)
Gruß,
Frank
@Ronald
ja, der Receiver ist ein USB HID Device. Deswegen braucht man auch keine
Treiber ;)
Ich kann dir für Linux leider nicht helfen, aber vielleicht findet sich
ja was per Google wie man in Linux mit einem HID Device spricht.
Ich bin mir jetzt nicht sicher ob die HID Kommunikation mit dem Device
im Source enthalten ist. Ich glaub da ist nur mehr der Source wie man
mit der DLL umgeht dabei. die geht unter Linux natürlich nicht.
Ansonsten melde dich bei mir, ich kann dir dann den Source für Windows
zumindest geben. Dann kann man sich die HID Handhabung für Linux
abschauen.
Sollte was daraus werden würde ich gerne den Linux source mit in das
Projekt aufnehmen!
Danke für die Antworten!
> Willi schrieb:>> Gibt es eine Alternative, die von der Schaltung genauso verbaut wird und>> wo das gesamte Irmp in den Flashspeicher passt?> Mega168 ist pinkompatibel. Nötige SW-Anpassungen siehe:> http://www.atmel.com/dyn/resources/prod_documents/...> http://www.atmel.com/dyn/resources/prod_documents/...
Ohje, davon hab ich ja mal garkeinen Ahnung :( Ich hab ja gelesen, dass
die sogenannten fuse-bits geändert werden müssen (was das auch immer ist
;) )
Sind sonst noch Anpassungen in dem Programmcode/Plugin nötig oder "nur"
der bootloader (wo mir vielleicht jemand helfen könnte!?)
Wenn nicht nehm ich halt den direkt unterstützten Atmega8!
Also ich habe hier einen Atmega168 und einen Atmega168p rumliegen.
Die Firmware selber habe ich schon zum laufen gebracht.
Jedoch geht der Bootloader nicht. Habe die Address auf 0x3800 geändert
aber es wird kein USB Device erkannt.
Mit dem Fuse Calc:
http://www.engbedded.com/fusecalc/
Hätte ich diese eingestellt:
Low 0xDF
high 0xD5
Ext 0xF8
Jedoch läuft es nicht. Hatt jemand einen Tipp?
Hugo Portisch schrieb:> Jedoch geht der Bootloader nicht. Habe die Address auf 0x3800 geändert> aber es wird kein USB Device erkannt.
0x3800 (in Bytes, 0x1C00 in Worten) wäre korrekt.
> Hätte ich diese eingestellt:> Low 0xDF> high 0xD5> Ext 0xF8
Der µC läuft doch mit 5V, oder? Dann hätte ich folgendes genommen:
Low 0xFF
high 0xD4
Ext 0xF8
Die Unterschiede sind marginal: Längere Anlaufzeit für den Quartz und
Brown-Out-Level auf 4,3 statt 2,7 Volt.
Gruß,
Frank
> 0x3800 (in Bytes, 0x1C00 in Worten) wäre korrekt.
Ja klar, Word = 2 Bytes.
Beim Atmega8 0xC00 Words -> 0x1800 in Bytes.
Ich habe im Forum von www.obdev.at auch andere gefunden, die auch das
Problem hatten, dass es auf den Atmega168 nicht geht.
die Modifizierte Version schreibt ja ein Byte in das EEPROM und dieses
wird auch geschrieben. Jedoch geht V-USB trotzdem nicht.
D.H. der Bootloader startet zwar, aber irgendwas anderes stimmt hier
nicht.
Auch mit der originale Version vom Release 2010-07-29 bekomme ich V-USB
nicht zum Laufen.
Ok, habe jetzt den originalen bootloader doch zum laufen gebracht. Der
brauchte ja den Jumper ... ;)
Jedoch beim Atmega168p:
> Device: atmega168p>> Program: 2078 bytes (12.7% Full)> (.text + .data + .bootloader)>> Data: 60 bytes (5.9% Full)> (.data + .bss + .noinit)
Das geht sich nicht in den bootloader aus. Mal sehen ob man hier was
kürzen kann.
Hugo Portisch schrieb:> Jedoch beim Atmega168p:>> Device: atmega168p>>>> Program: 2078 bytes (12.7% Full)>> (.text + .data + .bootloader)>>>> Data: 60 bytes (5.9% Full)>> (.data + .bss + .noinit)
Wie sieht das beim ATmega168 ohne P aus? Generiert der Compiler
tatsächlich so viel anderen Code für den 168P?
> Das geht sich nicht in den bootloader aus. Mal sehen ob man hier was> kürzen kann.
Wo kann man sich den Bootloader anschauen? Mittlerweile kenne ich da ein
paar Tricks, wie man hier und da ein paar Bytes einsparen kann.
Gruß,
Frank
Es lag an dem "p". V-USB hat ein Update gebraucht.
Das Speicherproblem habe ich auch in den Griff bekommen indem ich nun
statt eeprom_write_block ein eeprom_write_byte verwende. as hat mir ~100
Bytes verschafft.
Ich habe nun den Artikel USB IR Remote Receiver erneuert.
Im Download ist nun auch der Source für dem Atmega168p mit dabei.
Also neuer bootLoader (für beide Microcontroller) und neuer USB IR
Remote Receiver.
Die 16kB reichen wirklich bei Weitem! Das Project braucht ~8300 Bytes.
> Wo kann man sich den Bootloader anschauen?
Naja, nicht richtig anschauen ;)
Im Bootloader wurde nur Automatisch ein eeprom_write durchgeführt und im
Programmer habe ich dann die Warnung erhalten, dass das EEPROM nicht
leer ist. Somit musste der Bootloader angelaufen sein.
Hallo,
ich bin auf der Suche nach einer Anbindung für meine Logitech Harmony an
den HTPC (XBMC) und dabei auf dieses Projekt gestoßen.
Gibt es die Möglichkeit die auf MCE-Einsatz eingestellte Harmony über
den IR Empfänger anzubinden? Wenn der Atmega auf RC6 programmiert ist,
würde das dann direkt erkannt werden?
freundliche Grüße
Christian
Der Empfänger kann die Harmony sicher empfangen.
Ich habe meine Universal Fernbedienung z.b. auf ein Humax PVR
eingestellt (NEC-Protokol).
Jedoch weis ich nicht wie die Auswertung der Daten erfolgen soll.
Unterstützt XBMC Inputplugins? Dann könnte ich den Support in der DLL
hinzufügen.
Ansonsten kann man es über EventGhost oder Girder auswerten und die
IR-Befehle in Tastendrücke umwandeln.
Hallo,
danke für die schnelle Antwort!
Ich habe mich ein wenig eingelesen und es gibt im Internet Lösungen das
Programm XBMC über Girder oder Eventghost zu steuern.
Dann ist ja eigentlich alles bestens :-D
Die Logitech Harmony unterstützt sehr viele Codes. Ich kann ich mir dann
einen zum flashen auswählen.
Ich werde mich auf die Suche nach den Bauteilen machen.
Schwierig ist scheinbar die Fotodiode TSOP 17**. Meinst Du ich kann
dafür auch die Osram SFH 5110 einsetzen? Die Betriebsspannung und der
Betriebsstrom sind laut Datenblatt recht nah beieinander.
In welcher Bauform benötige ich die Kondensatoren?
Die im Foto verbauten sehen aus wie Tantal-Kondensatoren?
Christian schrieb:> Schwierig ist scheinbar die Fotodiode TSOP 17**. Meinst Du ich kann> dafür auch die Osram SFH 5110 einsetzen? Die Betriebsspannung und der> Betriebsstrom sind laut Datenblatt recht nah beieinander.
Ja, geht. Beachte aber die inkompatible Pinbelegung.
Gruß,
Frank
Hugo Portisch schrieb:> Im Download ist nun auch der Source für dem Atmega168p mit dabei.
Funktioniert das beiliegende hex-file auch mit nem Mega168 ohne P?
> Funktioniert das beiliegende hex-file auch mit nem Mega168 ohne P?
Also ich habe den Source (bootloadHID und USB IR Receiver) gerade für
den Atmega168 neu kompiliert.
Es kommt das gleiche Hex File wie beim "p" raus.
Sollte also gehen...
Hugo Portisch schrieb:> Also ich habe den Source (bootloadHID und USB IR Receiver) gerade für> den Atmega168 neu kompiliert.> Es kommt das gleiche Hex File wie beim "p" raus.> Sollte also gehen...
Danke. Werde ich demnächst testen.
Hugo Portisch schrieb:> Zur DLL überlege ich auch noch folgendes:> derzeit habe ich schon eine DLL die mit DVBViewer als Input-Plugin> läuft. Diese werde ich hernehmen und extra Funktionen exportieren, damit> diese auch für andere Programme verwendet werden kann.
Gibt es deinerseits Bestrebungen das für MediaPortal zu realisieren?
> Gibt es deinerseits Bestrebungen das für MediaPortal zu realisieren?
Eigentlich schon, aber ich finde kein Source Beispiel wie das in
Mediaportal funktioniert!
Hugo Portisch schrieb:> Eigentlich schon, aber ich finde kein Source Beispiel wie das in> Mediaportal funktioniert!
Irgendwo in "RemotePlugins" gibt es vermutlich was worauf man aufbauen
könnte, aber beschäftigt habe ich mich damit noch nicht.
Danke,
habe aber hier trozdem keinen durchblick wie das in Mediaportal
funktioniert. Wohin und wie werden die Empfangenen IR Daten an
Mediaportal gesendet? Wo wird das Mapping der IR Codes auf Mediaportal
Funktionen gemacht? Kann man die wie bei Girder für jeden IR-Code
anlernen?
Mal sehen ob ich noch mehr finde.
Hugo Portisch schrieb:> Wohin und wie werden die Empfangenen IR Daten an Mediaportal gesendet? Wo> wird das Mapping der IR Codes auf Mediaportal Funktionen gemacht?
Leider kenne ich mich damit nicht aus da ich ebenfalls noch nie etwas
für MePo entwickelt habe.
Hugo Portisch schrieb:> Kann man die wie bei Girder für jeden IR-Code anlernen?
Das wäre das Schönste.
Im Prinzip könnte man es so lösen, dass der USB-IRRR sich wie eine
HID-Tastatur verhält (à la
http://www.obdev.at/products/vusb/hidkeys.html) und IR-Codes als
Tastendrücke weitergibt. Das Problem ist allerdings, dass eine Tastatur
maximal ein Datenbyte verschicken darf. D.h. man dürfte nur
entsprechende IR-Codes (NEC) verwenden. Mir persönlich würde das
reichen, aber insgesamt ist das wohl zu unflexibel.
Kannst du mir auf die schnelle sagen wo ich für den Mega168 einstellen
kann an welchem Pin der Jumper angeschlossen ist? Ich habe eine etwas
andere Pinbelegung gewählt als du. Evtl. wäre das noch was für die
"configUSBIRRemoteReceiver.h".
Was hältst du von der zusätzlichen Integration von IRSND? Ich habe bei
mir das Problem, dass mein Verstärker etwas verdeckt steht und nicht
alle IR-Kommandos mitbekommt. Daher würde ich gerne die empfangenen
Kommandos 1-zu-1 "weiterleiten".
Micha schrieb:> Im Prinzip könnte man es so lösen, dass der USB-IRRR sich wie eine> HID-Tastatur verhält (à la> http://www.obdev.at/products/vusb/hidkeys.html) und IR-Codes als> Tastendrücke weitergibt. Das Problem ist allerdings, dass eine Tastatur> maximal ein Datenbyte verschicken darf. D.h. man dürfte nur> entsprechende IR-Codes (NEC) verwenden. Mir persönlich würde das> reichen, aber insgesamt ist das wohl zu unflexibel.
Da eine FB eine sehr beschränkte Anzahl von Tasten hat, reicht dieses
eine Datenbyte vollkommen aus. Man braucht lediglich eine Tabelle,
welche das empfangene Kommando (evtl. in Zusammenhang mit der Adresse)
auf ein eindeutiges Byte mappt. Das ist dann für alle von IRMP
unterstützten Protokolle möglich, nicht nur für NEC.
Gruß,
Frank
Frank M. schrieb:> Man braucht lediglich eine Tabelle, welche das empfangene Kommando (evtl.> in Zusammenhang mit der Adresse) auf ein eindeutiges Byte mappt.
... was aber nicht ganz einfach ist, vor allem wenn man mehrere
Eingangscodes erlaubt (z.B. NEC und RC5). Oder wie würdest du die
Tabelle aufbauen um nicht unnötig viel Rechenzeit und Speicher zu
verbrauchen?
Micha schrieb:> ... was aber nicht ganz einfach ist, vor allem wenn man mehrere> Eingangscodes erlaubt (z.B. NEC und RC5). Oder wie würdest du die> Tabelle aufbauen um nicht unnötig viel Rechenzeit und Speicher zu> verbrauchen?
zum Beispiel so:
1
#define MAX_REMOTE_CONTROLS 2 // 2 remote controls, e.g. RC5 + NEC
Das habe ich ins Unreine getippt, sollte aber soweit funktionieren. Die
Daten der Struct könnte man über PROGMEM noch ins Flash legen, wenn der
Speicher knapp werden sollte.
Gruß,
Frank
Frank M. schrieb:> Das habe ich ins Unreine getippt, sollte aber soweit funktionieren. Die> Daten der Struct könnte man über PROGMEM noch ins Flash legen, wenn der> Speicher knapp werden sollte.
Hmm - das sieht ziemlich gut aus. Und falls die Funktion 0xff
zurückgibt, wird der entsprechende Code mit IRSND "weitergeleitet". Das
gefällt mir! Vielen dank!
> Kannst du mir auf die schnelle sagen wo ich für den Mega168 einstellen> kann an welchem Pin der Jumper angeschlossen ist? Ich habe eine etwas> andere Pinbelegung gewählt als du. Evtl. wäre das noch was für die> "configUSBIRRemoteReceiver.h".
Der Jumper wird nur für den Originalen Bootloader gebraucht und ist im
bootloadHID Source zum einstellen.
Der veränderte bootloadHID braucht den Jumper nicht. Dieser wird gar
nicht mehr abgefragt.
Natürlich kann man die Auswertung der IR Daten und Zuordnung im AVR
definieren. Jedoch ist dann die Zuordnung fix und für jede Veränderung
muss eine neue Firmware eingespielt werden. Das passt aber nicht zum USB
IR Remote Receiver Konzept.
Der AVR sollte als einfacher Übersetzer gehandhabt werden und die
Auswertung sollte am Host gemacht werden. Den eine Tabelle im AVR passt
halt dann nur für den einen Typ von Fernbedienung. Hat man eine andere
muss auch die Tabelle im AVR angepasst werden.
Über IRSend habe ich noch nicht nachgedacht, da ich selber dies nicht in
Verwendung habe. Dazu wäre die Frage von wo IRSend gesteuert werden
soll. Vom AVR selber oder vom Host. Ich meine von wo IRSend die Befehle
erhaltet die was gesendet werden sollen.
Hugo Portisch schrieb:> Jedoch ist dann die Zuordnung fix und für jede Veränderung muss eine neue> Firmware eingespielt werden.
Naja, man könnte das Dingens ja lernfähig machen. Z.B. vom PC aus
anweisen neue Befehle zu erhalten und zu speichern. Als
Benutzeroberfläche würde im Prinzip ein Text-Editor ausreichen.
Hugo Portisch schrieb:> Dazu wäre die Frage von wo IRSend gesteuert werden soll. Vom AVR selber> oder vom Host. Ich meine von wo IRSend die Befehle erhaltet die was> gesendet werden sollen.
In meinem Fall sollte es einfach die per IRMP empfangenen Befehle 1-zu-1
mittels IRSND versenden. Sprich der AVR empfängt ein IR-Kommando und
"verschickt" es gleich wieder. Es muss halt garantiert sein, dass er
Kommandos, die er selbst verschickt hat nicht wieder empfangen kann -
eine gewisse räumliche Trennung muss also gegeben sein.
Micha schrieb:> In meinem Fall sollte es einfach die per IRMP empfangenen Befehle 1-zu-1> mittels IRSND versenden. Sprich der AVR empfängt ein IR-Kommando und> "verschickt" es gleich wieder.
Vorsicht, ein Gerät, das beide Signale empfängt (von der FB und von
IRSND), bekommt dann alles doppelt ab.
> Es muss halt garantiert sein, dass er> Kommandos, die er selbst verschickt hat nicht wieder empfangen kann -> eine gewisse räumliche Trennung muss also gegeben sein.
Siehe dazu entsprechenenden Abschnitt unter
http://www.mikrocontroller.net/articles/IRMP#Source-Code_IRSND
Zitat:
1
Möchte man IRMP und IRSND parallel verwenden (also als Sender und
2
Empfänger) schreibt man die ISR folgendermaßen:
3
4
ISR(TIMER1_COMPA_vect)
5
{
6
if (! irsnd_ISR()) // call irsnd ISR
7
{ // if not busy...
8
irmp_ISR(); // call irmp ISR
9
}
10
// call other timer interrupt routines...
11
}
12
13
Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR des
14
Empfängers auf. Damit ist der Empfänger solange abgeschaltet, während
15
irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine ist für
> Naja, man könnte das Dingens ja lernfähig machen. Z.B. vom PC aus> anweisen neue Befehle zu erhalten und zu speichern. Als> Benutzeroberfläche würde im Prinzip ein Text-Editor ausreichen.
Ok, man könnte die Empfangen IR-Daten am Host dann einen Key zuweisen (1
Byte). Dann den IR-Code mit dem Key im EEPROM ablegen. Dies würde dann 7
Bytes pro Key in Anpruch nehmen.
Zusätzlich kommt noch das, dass die HID Struktur umgebaut werden muss.
Der AVR muss sich dann als HID Tastatur ausgeben damit der Host die
Befehle als Tastendrücke ausführt. Da sehe ich das größere Problem. Ich
glaube das es da Probleme mit GetFeature/Setfeature gab als ich es als
HID-Tastatur versucht hatte. Der Erstellung des HID Reports war
eigentlich die größte Arbeit!
Derzeit:
0x0b, 0x01, 0x00, 0x00, 0xff, // USAGE (Vendor Defined Page 1:Vendor
Usage 1)
Muss dann:
0x09, 0x06, // USAGE (Keyboard)
werden. Ich werde zuerst einmal rumspielen ob der USB IR Remote Receiver
normal funktioniert, wenn er sich als Keyboard anmeldet. Wenn das nicht
geht weis ich nicht weiter!
Auch das Runterladen der Daten muss angepasst werden. Derzeit kann man
nur einen IR-Code runterladen der für die PowerON Funktion verwendet
werden soll. Dies ist Momentan auch nicht in Verwendung und wird nur zum
Löschen des PowerOn IR-Codes verwendet.
Hendrik S. schrieb:> Also ich fände ja auch eine Anbindung an MediaPortal super :)
Mir geht es auch primär darum. Am liebsten per Plugin oder eben als
Tastatur. Via Eventghost funktioniert zwar, gefällt mir aber wegen des
"Umweges" nicht und perfekt funktioniert hat es bei meinem letzten
Versuch auch nicht. Zugegebenermaßen lief das allerdings auch nicht mit
dem USB-IRRR, sondern auf einer anderen Hardware mit PIC (-> Y.A.R.D.).
Zu MediaPortal: Ich finde einfach keine Doku dazu wie das genau
funktioniert. Und hier alle Sourcen durchzustöbern habe ich Moment gar
keine Lust. Beim DVBViewer oder Girder gibt es eine schöne Doku wie mann
das macht. Ausserdem ist die DLL in Delphi geschrieben und Mediaportal
ist C#. Das macht es nicht gerade einfacher weil man hier noch weniger
bis gar kein Beispiel findet.
Micha schrieb:> Via Eventghost funktioniert zwar, gefällt mir aber wegen des> "Umweges" nicht und perfekt funktioniert hat es bei meinem letzten> Versuch auch nicht
Also ich habe das leider nicht zum laufen gebracht jedenfalls noch nicht
. Gut ich habe mich jetzt nicht intensiv damit auseinandergesetzt(erst
am wochenende)sondern nur mal kurz getestet. Habe jetzt auch mal ein
neues Layout gemacht -> ohne den Jumper und heute das mit dem Bootloader
getestet -> funktioniert astrein, bin echt beeindruckt, was hier aus dem
Projekt schon alles geworden ist.
Also die Umsetzung für den Support von MediaPortal in der DLL schaut
naja aus.
Also in der DLL glaube ich gar nicht, da sich Delphi Win32 und .NET
Assemblies einfach nicht vertragen.
Eine Lösung wäre eine extra DLL die in .NET/C# geschrieben ist um mit
Mediaportal zu funktionieren, die aber auch die nativen DLL Funktionen
der USB_IR_Remote_Receiver.dll verwendet.
Sozusagen eine Brücke MP <-> DLL.
Das könnte auf jeden Fall funktionieren.
Hugo Portisch schrieb:> Eine Lösung wäre eine extra DLL die in .NET/C# geschrieben ist um mit> Mediaportal zu funktionieren, die aber auch die nativen DLL Funktionen> der USB_IR_Remote_Receiver.dll verwendet.
Eine reine .NET-dll würde nicht funktionieren? Nutzt du egtl. irgenetwas
spezielles zur Kommunikation? libusb oder dergleichen?
Nein, aber ich habe zu wenig Erfahrung mit .NET und die DLL müsste auch
komplett neu geschrieben werden.
ich bin gerade dabei mir Sachen wie das hier anzusehen:
http://atozed.com/CrossTalk/index.de.aspx
Jedoch bekomme ich bis jetzt nur einen Absturz wenn ich die Core.dll von
Mediaportal hinzufügen will.
Hugo Portisch schrieb:> Jedoch bekomme ich bis jetzt nur einen Absturz wenn ich die Core.dll von> Mediaportal hinzufügen will.
Noch immer? Bei mir gibt es keine Probleme mit VC# 2008 EE.
Geht nicht, nein. Die Utils.dll funktioniert z.B.
Bei der Core.dll -> Absturz.
Mit VS2008 habe ich auch kein Problem die Metadaten einzulesen. Nur mit
Hydra und Crosstalk geibt es Probleme.
Ich habe eben mal ein bisschen mit dem "generic_hid_cs"-Beispiel von Jan
Axelson (http://www.lvr.com/hidpage.htm) und dem USB-IRRR gespielt.
Ergebnis anbei.
DLL_Demo.txt -> 2x eine Sequenz aus 5 Tasten mit Hugos DLL_Demo
empfangen
generic_hid_cs.PNG -> 1x dieselbe Sequenz aus 5 Tasten mit o.g.
"generic_hid_cs"-Beispiel ohne irgendwelche Anpassungen (außer VID &
PID). Bei "Bytes to Send" oben 01 eintragen und das Häkchen entfernen
oder lassen (macht erstmal keinen Unterschied). Dann auf "Once" klicken
und FB-Taste drücken.
IDE ist VC#2008EE, wie geschrieben ohne weitere Anpassungen, dlls (auch
NICHT die "USB_IR_Remote_Receiver.dll" von Hugo) oder Sonstiges...
Ich habe ehrlich gesagt sehr wenig Erfahrung mit VC# und USB aber so
schlecht sieht das nicht aus, finde ich. Kommentare sind ausdrücklich
erwünscht.
Michael K. schrieb:> Bei "Bytes to Send" oben 01 eintragen und das Häkchen entfernen oder> lassen (macht erstmal keinen Unterschied).
Das scheint das Ganze insgesamt nicht zu beeinflussen.
Die gleichen Ergebnisse lassen sich mit der "generic_hid_vb", ebenfalls
von o.g. Seite, und VB2008EE erzielen. Nur für den Fall dass jemand
Basic bevorzugt...
Hi,
ich würde halt empfehlen die DLL mit deren Funktionen zu benutzen.
Dann spart man sich das ganze HID Zeugs und man hat auch die Optionen
Oberfläche der DLL und auch das Neuflashen des AVR ist gleich mit drin.
Also einfach die DLL über die InitNative benützen.
Sonst macht man sich halt Arbeit, was eh schon gemacht ist...
Hugo Portisch schrieb:> ich würde halt empfehlen die DLL mit deren Funktionen zu benutzen.> Dann spart man sich das ganze HID Zeugs und man hat auch die Optionen> Oberfläche der DLL und auch das Neuflashen des AVR ist gleich mit drin.> Also einfach die DLL über die InitNative benützen.>> Sonst macht man sich halt Arbeit, was eh schon gemacht ist...
Klar, will ich schon so machen. Vorausgesetzt die DLL lässt sich im
Visual Studio benutzen...
Das oben habe ich rein interessehalber einfach mal versucht. Das
Ergebnis wäre ja auch noch stark verbesserungswürdig, stimmt aber nicht
unbedingt negativ.
Die DLL Funktionen sollten sich eigentlich von VS ohne Problem benutzen
lassen. Es ist ja auch eine VS2008 Konsole Demo dabei.
Ist halt nicht .NET aber da kann man sicher auch externe DLL Funktionen
definieren.
Hello everyone!
Sorry for english.
I try build this remote receiver.I use Atmega8. First i try bootLoadHID
v1.1 compile under AVRStudio with AVRGCC and i get this warnings.(you
will see on attached picture) What is the problem and the solution? (The
USB IR Remote Receiver 1.6 compile is working correctly, i am not
getting warning message) Thank You.
@ Hugo
nochmal zum Thema MediaPortal: arbeitest du an der Integration (nativ,
per dll, wieauchimmer) oder nicht?
Ich habe ein bisschen mit VC# und deiner DLL gepielt, aber empfangene
IR-Daten konnte ich dem Ganzen nicht entlocken, sondern lediglich die
Infos à la "PluginName", "Version" und "Copyright". Sachen wie das von
dir erwähnte "CrossTalk" habe ich allerdings nicht probiert.
@San398:
Just ignore this warnings!
@Michael K.:
Nein, habe im Moment keine Zeit mich mit C# oder .NET herumzuschlagen.
Um die IR Daten in deinem Progamm empfangen zu können brauchst du eine
CallBack Funktion. Wenn dann die USB_IR_Remote_Receiver.dll einen Code
empfängt wird diese CallBack (in deinem Programm) aufgerufen.
Mit der Funtkion "InitNative" kann man der DLL den Pointer deiner
CallBack Funktion übergeben. Auch musst du "InitNative" oder
"InitPAnsiChar" mit einem Pointer deiner CallBack Funktion aufrufen.
Ansonsten wird das HID-Device nicht geöffnet und es ist kein IR-Empfang
möglich.
Siehe z.B. hier:
http://www.myelin.co.nz/notes/callbacks/cs-delegates.html
Sieh dir dazu am besten die verschiedenen Demos an. Es sind ja Demos in
Delphi, C++ und Phyton (EventGhost) dabei.
Das CrossTalk wär nur für mich interresant. Dies würde die Benutzung von
.NET Assemblies in Delphi VCL herstellen. Dies ist ansonsten nicht
möglich.
An die Nutzer von MediaPortal:
wie habt ihr euch die Implementierung vorgestellt?
Mir schwebt vor, dass man einfach jeder Tastaturtaste einen IR-Code
zuweist. Man muss dann MePo so konfigurieren, dass man es gut mit der
Tastatur steuern kann und anschließend die IR-Codes vergeben. ShortCuter
und dergleichen kann man trotzdem verwenden.
Nachteil ist unter Umständen, dass man sich erstmal ne Liste erstellen
muss welche Taste was macht. Da ich das aber sowieso schon habe, kann
ich damit leben... ;-)
Das Ganze funktioniert so ohne weiteres aber nur wenn MePo im
Vordergrund ist (z.B. durch "Keep MediaPortal always on top").
an sich hätte ich mit einer solchen liste kein problem. Genial wärs
natürlich, wenn man es direkt zuordnen könnte, sprich man hat alle
möglichen Kommandos, wie z.B pause,play, umschalten usw. auf die man
klickt und anschließend einfach den gewünschten knopf auf der Fb drückt.
Wie genau meinst du das mit dem on top? Es geht also nur wenn man
richtig in Mediaportal drin ist und es nicht minimiert ist? Wenn ja wäre
das für mich völlig ok so lange es nicht die ganze zeit on top ist, ich
es also minimieren kann und mal im internet surfe, es aber dann wieder
maximiere, einmal reinklicke und die fb funktioniert wieder?
lg Hendi
Ich hatte mir gedacht, dass man z.B. eine Eingabemaske mit allen
möglichen Tasten (z.B. a...z, F1...F12, Shift, Ctrl, Enter, usw.) hat.
Zum anlernen markiert man eine dieser Tasten, klickt auf einen Button
(z.B. "Lernen") und anschließend sendet man einen IR-Code. Die Anwendung
speichert diese Daten in einer xml-Datei und fortan wird ein empfangener
IR-Code wie ein Tastendruck auf der Tastatur behandelt.
Z.B.
Protocol=NEC, Address=FD02, Command=000F => Enter
Protocol=NEC, Address=FD02, Command=000A => F1
Protocol=NEC, Address=FD02, Command=00FF => A
usw.
Wie bei einer regulären Tastatureingabe wird die Eingabe aber nur von
der aktiven Anwendung empfangen, irgendeine Applikation im Hintergrund
ist davon nicht betroffen.
Man könnte das Ganze auch als Tray-Applikation erstellen um es auch mit
anderen Programmen nutzen zu können, z.B. um seine Texte in Word auf der
Fernbedienung zu schreiben. ;-)
In deinem o.g. Szenario hieße das dann aber, dass dein Browser die Taste
empfängt und entsprechend (be-)handelt.
Vermutlich werde ich in einem ersten Schritt die genannte Tray-App
schreiben und danach evtl. erst das MePo-Plugin. Mir persönlich würde
das so ausreichen, da ich den entsprechenden Rechner nur für MePo nutze.
Habe für Linux eine Lösung gefunden:
http://forum.xbmc.org/showthread.php?t=88560
die Software-Version in Beitrag #117 (und sicher auch die, die noch
folgen) funktioniert mit meinem Empfänger.
Mit der o. g. Software (hid-mapper) können den empfangenen FB-Codes
entsprechende Tasten unter X zugeordnet werden.
Lirc ist nicht notwendig.
Getestet mit xbmc.
Leider hat es etwas länger gedauert als erwartet: anbei findet ihr ein
Standalone-Programm das die zugeordnete Taste an das Fenster im
Vordergrund sendet.
Zur Benutzung beide Dateien in ein Verzeichnis entpacken, Hugos DLL in
dasselbe Verzeichnis kopieren und das Programm starten. Die xml-Datei
aus dem Anhang soll nur als kleines Muster dienen. Falls nicht vorhanden
wird die Datei beim Programmstart neu erstellt, allerdings sind die
Tastenzuordnungen dann verloren.
Geschrieben wurde das Ganze mit VC# 2008, es wird also das
.NET-Framework 3.5 benötigt.
Wenn ihr einen Bug findet, bitte eine Info an mich mit einer kurzen
Beschreibung wie sich der Fehler reproduzieren lässt.
Des Weiteren habe ich noch eine kleine "Umfrage":
wer hat Interesse an einem Timer, der den PC zu einer bestimmten Uhrzeit
wecken kann?
Ich persönlich fände das sehr praktisch, da ich den PC dann komplett
ausschalten könnte und nicht auf Standby- oder Hibernate-Modi
zurückgreifen müsste, die (zumindest bei mir) nicht zuverlässig
funktionieren.
Die Weckzeit könnte über Hugos DLL eingestellt werden, die Uhrzeit auf
dem AVR könnte mittels eines DCF-Empfängers oder mit Hilfe einer RTC
bezogen/aktualisiert werden. Über Plugins würde die jeweils nächste
Startzeit entsprechend der anstehenden Aufnahmeaufträge eingestellt.
Mhm also iwie is das bei mir komisch. Ich kann einfach kein NET
Framework 3.5 bei mir installieren, hab das 4er drauf. (Windows 7
Ultimate, 64bit) und bekomme gleich beim Start Deines programms einen
Fehler, das versucht wurde eine Datei im falschen Format zu laden. Hängt
das mit dem Net3.5 da zusammen?
LG, Hendi
Wie genau lautet die Fehlermeldung?
Ich habe ehrlich gesagt keinen PC mit Win7 oder Vista, sondern nur WinXP
Pro 32bit mit .Net 3.5. Daher habe ich es auf anderen Systemen nicht
testen können.
@Michael K.:
Du musst im VC Projekt unbedingt den CPU Type von "Any" auf x86
umstellen.
Das war auch bei mir das Problem mit dem Error 0x8007000B.
Bei x64 System wird ansonsten versucht die DLL im x64 Modus zu laden ->
Error da es eine x86 DLL ist.
(habe Win7 x64)
Hugo Portisch schrieb:> Du musst im VC Projekt unbedingt den CPU Type von "Any" auf x86> umstellen.
Das ist mit der Version von 23:21 erledigt. Da ich keine Möglichkeit zum
Testen habe, wäre ich über Rückmeldungen dankbar.
Also es sieht wesentlich besser aus, als bei der alten Version ;) Bis
jetzt funktioniert alles. Werde morgen mal bisschen genauer testen.
Werde dann natürlich Rückmeldung geben.
LG, Hendi
Hendrik S. schrieb:> Werde dann natürlich Rückmeldung geben.
Ich bitte darum - nicht nur dich, sondern auch die anderen, die sich das
Programm runtergeladen haben.
Und ich möchte nochmal an die Frage von oben
(Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)")
erinnern: wer hätte gerne die Möglichkeit seinen PC via USB-IRRR
zeitgesteuert zu starten?
Herrgott :D ich bin shcon wieder nicht dazu gekommen das mal in Ruhe zu
testen. Ich hoffe, das ich am Wochenende endlich mal Zeit finde. Mhm
also wegen mir musst du die Zeitsteuerung nicht machen. Es wäre zwar
schon interessant aber für mich (wer es brauch soll sich melden) nicht
sinnvoll, da eh alle Aufnahmen über einen Server laufen
Hi, ich habe jetzt ein bisschen rumgespielt und kann jetzt grundlegend
mit der Fernbediunung durch Mediaportal navigieren. Das Programm läuft
bis jetzt stabil und zuverlässig :) Aber ich habe noch Fragen zu der XML
Datei:
Ich will jetzt noch z.B. der Leertsaste einen IR Code zuordnen, Aber wie
mache ich das? bei linker und rechter Pfeiltaste hat es natürlich schön
geklappt mit {left} usw. bei {space} geht das nicht. Warscheinlich ist
die Frage für einen, der programmiert total doof aber ich programmiere
nur sehr selten und dazu hatte ich noch nie was mit XML zu tun ;)
Wie muss ich das also schreiben?
LG,
Hendrik
In der XML-Datei selbst musst du doch gar nichts ändern. Dazu ist der
Dialog "Key assignment" da.
Ich habe ehrlich gesagt nicht alle Tasten getestet, daher ist mir das
mit Space nicht aufgefallen. Das Problem ist, dass beim Einlesen der
XML-Datei <key> </key> nicht als Space interpretiert wird, sondern als
nichts.
In der angehängten Version 1.0.0.2 ist ein Workaround eingebaut.
Allerdings musste ich dazu von der MSDN-Dokumentation abweichen. Dort
läuft Space als " " (ohne "), im Programm muss allerdings "{space}"
(ohne ") verwendet werden.
Noch zwei Bemerkungen zum Programm:
1. es können auch Tastenfolgen verwendet werden, dazu einfach die
entsprechende Folge eingeben, z.B. "test", "{up}{down}{left}", ...
2. es wird nicht überprüft ob ein IR-Code mehrfach zugewiesen ist.
Sollte dies der Fall sein, so wird die erste Zuweisung verwendet,
spätere werden ignoriert. Die Zuweisungsliste wird dabei von oben nach
unten durchsucht.
jaa ka ich hab jetzt halt alles direkt in der XML Datei gemacht :D ist
ja auch nicht wirklich mehr Aufwand. Habs jetzt so gelöst, das ich in
der XML von Mediaportal, wo die shortcuts definiert sind einfach
play/pause auf eine andere Taste umgelegt habe. -> funktioniert perfekt.
Ja mhm also das mit {space} hatte ich auch schon drin aber wie gesagt,
es hat nicht funktioniert aber naja es hat sich ja jetzte erledigt und
dein Programm läuft immer noch einwandfrei :) Vielen Dank für die tolle
Arbeit!
Hendrik S. schrieb:> Ja mhm also das mit {space} hatte ich auch schon drin aber wie gesagt,> es hat nicht funktioniert
In der vorigen Version war diesbezüglich ein Bug und das hat tatsächlich
nicht funktioniert. Danke für den Hinweis! Mit Version 1.0.0.2 sollte
{space} aber funktionieren.
Hallo Hugo,
ich habe mit Begeisterung dein Projekt nachvollziehen, ohne dass ich
mich mit Mikrocontroller auskenne, einfach eine super Sache, Danke für
diese super Idee und Umsetzung.
Es läuft alles bestens, dennoch habe ich hier zwei Fragen:
1. Da der Powerbutton bei der ersten Betätigung gelernt wird, wie kann
man diesen wieder ändern? bzw. wie löscht man das EEProm?
2. Da ich eine Änderung der IR Code machen möchte und die im Quellcode
schon geändert habe, kenne ich mich leider nicht mit den Compiler aus,
gibt es irgend ein HowTo, der das neu erstellen einer *.hex erklärt?
LG Dietmar
>> 1. Da der Powerbutton bei der ersten Betätigung gelernt wird, wie kann>> man diesen wieder ändern? bzw. wie löscht man das EEProm?
Der gelernte Code kann durch die DLL gelöscht werden. Also Optionen
Fenster öffnen und Clear Trained Code auswählen.
Der nächste erkannte IR code wird dann wieder gespeichert.
Tipp: Den Optokoppler entfernen, ansonsten kann es passieren, dass sich
der PC ausschaltet.
>> 2. Da ich eine Änderung der IR Code machen möchte und die im Quellcode>> schon geändert habe, kenne ich mich leider nicht mit den Compiler aus,>> gibt es irgend ein HowTo, der das neu erstellen einer *.hex erklärt?
Du brauchts AVR Studio und WinAVR um den Source kompilieren zu können.
Dazu findet sich sicher einige Anleitungen.
>> @ Hugo>> Ich kenne mich nicht wirklich gut mit USB-Kommunikation aus und habe mir>> u.a. dein Projekt als Beispiel angesehen, da ich gerade ebenfalls an>> einem Projekt mit V-USB arbeite. Dabei ist mir aufgefallen, dass als>> FeatureReport-Länge maximal 6 Bytes eingetragen sind, der>> Versions-Report allerdings 10 Bytes lang ist. Kannst du das bitte kurz>> erklären? Ist das Absicht und wenn ja, wieso?
Der Irmp IR Code besteht aus 6 Bytes: 1 Byte Protokoll, 2 Bytes Adresse,
2 Bytes Command und 1 Byte Repeat Flag = 6 Byte.
>> //enter here the Irmp build date:>> const char IrmpVersion[] = "18.01.2011";
Die 10 Bytes kommen von diesem String. Das sind 10 Zeichen.
Ich selber habe einige Zeit gebraucht, mir diesen HID Report zusammen zu
stellen. Ist gar nicht so einfach:
http://www.usb.org/developers/hidpage/
Besonders habe ich mit dem HID Descriptor Tool gearbeitet.
Wie gesagt, ich selber habe ~50-100 Versuche gebraucht bis das HID
Device dann einmal richtig vom PC erkannt wurde ;)
Hugo Portisch schrieb:>>> const char IrmpVersion[] = "18.01.2011";> Die 10 Bytes kommen von diesem String. Das sind 10 Zeichen.
Richtig. Aber ich vermisse diese Längenangabe im ReportDescriptor. Bei
der Report ID 7 ist dort vier angegeben und nicht 10. Soll das so sein
und wenn ja warum?
Hmmm.. gute Frage.
Ehrlich gesagt weis ich nicht mehr warum.
Es wird auf jeden Fall die usbFunctionRead verwendet, da es mehr als 8
Bytes sind. Bei der Demo 'Irmp_V-USB_mit_INT_1.0.0.0' werden auch 11
Bytes gelesen (Ansistring, Nullterminiert).
Über diese Funktion wird der String häppchenweise zum Host geschickt.
Es könnte sein, dass so der Host weis das per ID7 4 Bytes zu erwarten
sind. Eigentlich sollten es aber 0x0B sein. Könnte egal sein, sollange
der Host die richtige Anzahl anfordert.
Die DLL wertet den HID Descriptor nicht aus sondern die Datenmengen sind
fix definiert somit kann es sein das das 0x04 kein Problem darstellt.
Also vielleicht ein "Fehler" im Source...
Hallo,
wirklich schönes Projekt. Leider gibt es im Wiki keine Stückliste und
ich habe als Elektronik-Laie etwas Probleme die Kondensatoren aus dem
Schaltplan rauszuziehen. Daher die Frage: welche Art von Kondensatoren
C1/C2, EC1/2 werden verwendet?
Dirk W. schrieb:> Daher die Frage: welche Art von Kondensatoren C1/C2, EC1/2 werden> verwendet?
Die Werte stehen dabei. Technologie ist egal, vermutlich läuft es auf
Keramik für C1/C1 und Keramik oder Tantal-Elko für EC1/EC2 raus. Sieh
einfach nach was der Lieferant deiner Wahl in der Bauform deiner Wahl
auf Lager hat.
Es befindet sich im Packet ein PDF: www.reichelt.de.pdf
Das ist eine Stückliste und zeigt was für Kondensatoren verwendet
werden.
Generell ist es nicht so dragisch ob Elko oder Tantal-Elko. Die 2 22p
sind Keramikkondensatoren. Man kann die Elkos auch in SMD Bauform nehmen
wenn man sich ein Layout erstellt.
Hugo Portisch schrieb:> Es befindet sich im Packet ein PDF: www.reichelt.de.pdf>> Das ist eine Stückliste und zeigt was für Kondensatoren verwendet> werden.
Danke für den Hinweis, in das Zip habe ich natürlich noch nicht
geschaut.
Gibts evtl noch eine Empfehlung für ein Gehäuse? Eine offene
Lochraster-Platine findet meine Frau bestimmt nicht so schick.
Ich selber habe immer noch den Lochrasteraufbau im Gebrauch.
Dieser ist aber im PC Gehäuse. Wie man am Foto erkennen kann stecke ich
ihn direkt mit einm 10 poligen IDC Flachband am internen USB-Port an.
Den Empfänger habe ich mit ~10cm Kabel (altes Audiokabel was beim
CD-Laufwerk dabei war) an die Front des PC versetzt damit er die IR
Signale empfangen kann. Somit ist gar nichts mehr sichtbar.
Aber ein Gehäuse kann man sich schnell un günstig bei Reichelt/Rs
Komponents usw besorgen.
Dein Projekt sieht für mich sehr interessant aus.
Ich möchte den Empfänger in leicht abgewandelter Form einsetzen. Und
zwar benutze ich eine Wireless Extender, dieser nimmt die Befehle von
meiner Fernbediung per Funk entgegen und schickt sie dann normaleweise
an eine IR-Diode weiter welche dann letztendlich das Gerät über IR
bedient.
Zur Zeit gehe ich mit diesem Signal aus dem Extender über einen Tiefpass
direkt auf die Com-Schnittstelle. Der Receiver wird dabei als "active
high" genutzt, das ist mit Lirc auch kein Problem. Der TSOP ist ja
"active low".
Funktioniert dein Projekt auch direkt mit "active high", falls nein, an
welcher Stelle im Code müsste ich im Code das ganze umdrehen? Dürfte ja
nur die Stelle sein, wo das Eingangssignal gelesen wird. Dort müsste es
dann einfach invertiert werden.
Ich hab vorhin schonmal ein bischen durchgeguckt, aber da meine AVR
Kenntnisse recht beschränkt sind konnte ich es nicht finden.
Maniac schrieb:> Ich glaub ich habs gefunden. Folgendes müsste das auf active high ändern> oder?>> irmpconfig.h Zeile 81>
1
#define input(x) ((x) & (1 << IRMP_BIT))
> ändern in>
1
#define input(x) ((x) | (1 << IRMP_BIT))
Nein, das ist Unsinn.
Habe ich das richtig verstanden? Willst Du statt des TSOPs einen anderen
Empfänger nutzen, der High- statt Low-Pegel ausgibt? Wenn ja, dann geht
das so:
irmpconfig.h Zeile 81
Genau, ich werde über einen Tiefpass ein Signal nutzen, welches
normalerweise eine IR-Diode ansteuert.
Danke für die Korrektur, ich werd es so mal ausprobieren.
Altainta schrieb:> can u give a alternative for the CNY17III it is not available in the> market...(use following link to check alternative)
As far as I can see, there are a couple of CNY17 available. I think you
are a bit confused because of the ...III. There is CNY17-1 to CNY17-4.
The one you mentioned is the ...-3. I would suggest using ...-3 or
...-4, but it's not a very critical part.
Altainta schrieb:> Also u had a list of the items needed for this project can you please> provide it..
You can find the recent version in the second line below this headline:
http://www.mikrocontroller.net/articles/USB_IR_Remote_Receiver#Download
In this package under
USB_IR_Remote_Receiver_Complete_28022011\AVR_Source\USB IR Remote
Receiver 1.6\www.reichelt.de.pdf you can find a kind of a BOM.
You are right michael i was confused because of III okay i will buy any
cny17 which is available..
Yeah and i also found the BOM. lol
Thx will disturb u again.. have few questions..
I am very ashamed to say this but can u provide a Item List in English
because when i saw the shoplist www.reichelt.de.pdf
it is stated that KB 817 OPTOKOPPLER which is 4 leg but in the guide
they say CNY17III which is 6 leg... Why am i keeping pressure on this
because i need a PC ON / OFF system working properly.. I have Igor plug
but i want a good solution for windows 7 as well and on off.. Destiny
guided me here..
Please provide a completely item list we are hobbyist electronic
guys..thank you
Hallo zusammen,
ich bin jetzt endlich mal dazu gekommen den Receiver aufzubauen und in
Betrieb zu nehmen. Dabei sind mir ein paar Dinge aufgefallen bzw ich
habe da noch ein Problem:
1. Es wäre schön wenn das HexFile und die Source zusammen passen würden.
Wenn man die Source mit WinAVR compiled kommt ein anderes HexFile raus,
weil das Hexfile mit Bootloader=1 übersetzt wurde, im Source aber
Bootloader=0 gesetzt ist.
2. Für die Inbetriebnahme wäre es schön die serielle Schnittstelle für
Logging benutzen zu können. IRMP und V_USB bringen von Hause aus Support
dafür mit. Die Serial kann aber nicht benutzt werden, das RxD mit USB D-
verbunden ist. Imo extrem ungeschickte Wahl für die USB Datenports.
3. Bei mir funktioniert keine F_INTERRUPTS ungleich 10000. Dann werden
keine Remote Codes mehr erkannt bzw. nur noch falsche. Wie passt das
eigentlich zusammen wenn in der Source #define F_INTERRUPTS ein fester
Wert eingestellt wird und dann an dem Schieberegler der DLL rumgezogen
wird?
Da ich sowieso einige FB bzw IR-Tastaturen benutzen will, die nur mit
neueren IRMP Versionen funktionieren, habe ich dem Receiver ein IRMP
Upgrade verpasst. Das Verhalten mit den F_INTERRUPTS ist aber das
gleiche. Hat irgend jemand F_INTERRUPTS != 10000 am laufen?
1. Compiliere es selber. Dann weißt du am besten was du hast. Solche
Unterschiede könnten auch durch unterschiedliche WinAVR-Versionen
kommen.
2. Ändere es. Dafür gibt es den Abschnitt Hardware Config in
usbconfig.h.
3. Niedrigere Werte führen bei mir dazu, dass z.B. das Protokoll von NEC
zu RC5 wird und dieselbe Taste unterschiedliche Adressen und Kommandos
produziert. Höhere Werte führen ebenfalls gelegentlich zu Fehlern. Eine
andere FB habe ich noch nicht getestet und die Einstellung habe ich auf
default da es damit am kaum Probleme gibt.
F_INTERRUPTS wird nur zur ersten Init verwendet. Danach werden die
empfangenen Werte genommen. Siehe timer_init und usbFunctionWrite.
Dirk W. schrieb:> 3. Bei mir funktioniert keine F_INTERRUPTS ungleich 10000. Dann werden> keine Remote Codes mehr erkannt bzw. nur noch falsche. Wie passt das> eigentlich zusammen wenn in der Source #define F_INTERRUPTS ein fester> Wert eingestellt wird und dann an dem Schieberegler der DLL rumgezogen> wird?
Ich habe mir das nochmal angesehen und muss dir recht geben. Das kann
gar nicht funktionieren, da F_INTERRUPTS auch in irmp.c, Zeile 385 bis
599, zur Berechnung der Zeiten verwendet wird. Durch bewegen des
Schiebereglers wird nur die Zeitbasis des Timers verändert, F_INTERRUPTS
bleibt natürlich gleich und dadurch passen die Zeiten der Protokolle
nicht mehr.
After reading few articles online i got to know that the programmer like
serial, parallel etc will only work for new chips (fuse bits) but will
not work with existing chip. So i think i am having a problem while
ready a atmega8 chip. Now i decided to buy a new chip and test it..
1) Is it necessary to add crystal ? what is the purpose ?
2) In the Schematic (usb remote) there is Pin 26,25 mentioned as shield
on printer port what to do with it? i didn't understand where to connect
it...
3) In the schematic the LPT programer things are optional ? (in case if
u have a existing programmer)
4)In the meantime i will make the LPT programmer u suggested in the
schematic.. Will it work with existing atmega8 ?
5) The programmer which i mentioned above works only with the software
they provide http://sbolt.home.xs4all.nl/e-spider_prog.html. Name is
SP12. the program is like AVRDUDE (dos based) if u know about it can u
give me fuse bit setting for it ? in dos mode ? because this is the only
programmer which saved my 2-3 ics attiny 2313 etc. And the existing chip
which i have works with it... But i do not know the command for setting
Fusebit EXACTLY!.
6) One more thing (sorry to bug u) there are two ics Atmega8A 16 Mhz and
Atmega8L 8 Mhz which one to use ? Do they need Differe MHz crystal ?
My apology for asking so many noob question but i am very desperate for
this project diy.
Hallo,
Wie der Kollege "Maniac", habe ich eine Fernbedienung mit Funkempfänger
(Harmony 900), an den 2 sog. IR-Blaster angeschlossen werden können. In
den Dingern sind lediglich IR-Dioden verbaut, was bedeutet, dass sie
über den Anschluß des Funkempfängers bereits ein "fertiges" Signal
bekommen.
Ich dachte nun daran, die "USB IR Empfänger Schaltung" direkt an einen
IR Ausgang des Funkempfängers der Harmony anzuschließen. Das Signal
müsste meiner Ansicht nach nur noch demoduliert werden, was ich gerne
direkt mit dem Atmega8 machen würde.
Frage1: Ich habe gehört, dass man diese Demodulation direkt im AVR
machen kann, indem das Signal auf einen Interrupt Eingang gelegt wird,
mit dem man dann die Flanken zählt. Ist das soweit korrekt?
Frage2: Wie müsste ich in etwa den Code anpassen um das zu erreichen? C
kann ich halbwegs, nur mit AVR Programmierung habe ich mich bislang
weniger beschäftigt.
Frage3: Momentan sind beide Interrupts des Atmega belegt. Muß der
Bootloader Jumper ausgerechnet PD2 blockieren oder kann der auch auf
z.B. PD6 umgelegt werden?
@ altainta
1. Yes, it is. The 8MHz that the internal oscillator can achieve are not
enough for V-USB
2. It should work without shield, but don't forget pin 25.
3. Exactly.
4. Yes, it should. I didn't test it myself as I have a JTAGICE mkII and
used a Mega168.
5. As written in the schematic you could use Ponyprog. On their homepage
they have also some examples of working programmers.
6. They work with the same crystals, but the 8MHz works only up to 8MHz,
while you need at least 12MHz.
@Klez:
Äh.. der Receiver macht genau das was du beschreibst. Er wandelt die
IR-Impulse in Protokolltyp, Adresse und Command um. Schaue dir am besten
einmal den Artikel von IRMP an.
Ich glaube hier liegt ein Mißverständnis vor: Der Receiver ist dafür
ausgelegt das Signal über einen IR Empfänger (z.B. TSOP) zu bekommen.
Dieser entfernt bereits die Trägerfrequenz und füttert den AVR mit dem
reinen Nutzsignal.
Der Funk-Empfänger der Harmony 900 liefert am IR Ausgang aber ein
komplett moduliertes Signal. Ich müsste daher zuerst die Trägerfrequenz
entfernen und das geht angeblich auch direkt im AVR. Darauf war meine
Frage bezogen. "Maniac (Gast)" hat so etwas ähnliches weiter oben schob
beschrieben.