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 von
anderen 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:

HidD_GetFeature (hole Daten vom AVR):
ID1:  (6 Bytes) aktueller empfangener IR-Code, Daten entsprechen der Irmp Struktur.
ID2:  (1 Byte, Boolean) aktueller Status ob PowerOn Funktion aktiviert ist oder nicht.
ID3:  (6 Bytes) aktueller trainierter IR-Code fuer die PowerOn Funktion, Daten entsprechen der Irmp Struktur.
ID7:  (4 Bytes) aktuell verwendete Irmp Version. (Day[Byte], Month[Byte], Year[Word])

HidD_SetFeature (schicke Daten zum AVR):
ID4:  (1 Byte, Boolean) setze PowerOn Funktion aktiv/inaktiv.
ID5:  (6 Bytes) setze/loesche trainierten IR-Code im EEProm.
ID6:  (1 Word) setze IR-Polling Frequenz.

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

> 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:

//enter here the Irmp build date:
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

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:

19:07:34: USB IR Remote Receiver connected
19:07:38: Irmp Version: 17.03.2010
19:07:40: PowerOn Function status: 1
19:07:41: Trained IR Code: Protocol : RC6, Address: 0x0027, Command: 0x000C, Flags: 0x00
19:07:45: Protocol : RC6, Address: 0x0027, Command: 0x0010, Flags: 0x00
19:07:46: Protocol : RC6, Address: 0x0027, Command: 0x0011, Flags: 0x00
19:07:47: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x00
19:07:48: Protocol : RC6, Address: 0x0027, Command: 0x0059, Flags: 0x00
19:07:48: Protocol : RC6, Address: 0x0027, Command: 0x005C, Flags: 0x00
19:07:49: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x00
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01
19:07:50: Protocol : RC6, Address: 0x0027, Command: 0x0058, Flags: 0x01

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?

                    for (i = 0; i < c_startcycles; ++i)
                    {
                        irmp_uart_putc ('0');                                   // the ignored starting zeros
                    }

Da weis ich nähmlich nicht wieviele Interrupts zusammen kommen...

So könnte es einen Versuch wert sein:

                    uint16_t i;
                    static uint8_t  s_data_buffer[9];
                    
                    s_data_buffer[0] = ReportIDLogging;
                    s_data_buffer[1] = 0x00;                    

                    for (i = 0; i < c_startcycles; ++i)
                    {
                        while (!usbInterruptIsReady()) usbPoll();          // check if USB int is ready
                            usbSetInterrupt(&s_data_buffer[0], 2);              // send ReportID + IR data  
                    }

                    for (i = 0;i < (s_dataIdx - c_endBits + 20) / 8; ++i)       // transform bitset into uart chars
                    { 
                        memcpy(&s_data_buffer[1]), &s_data[i*8], 8);
                        
                        while (!usbInterruptIsReady()) usbPoll();          // check if USB int is ready
                            usbSetInterrupt(&s_data_buffer[0], 9);              // send ReportID + IR data                        
                    }

                    s_dataIdx = 0;

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?
>

                    for (i = 0; i < c_startcycles; ++i)
>                     {
>                         irmp_uart_putc ('0');
> // the ignored starting zeros
>                     }

> 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

Danke,

...das mit Interrupt im Logging wird nicht gehen.

Besser wird es so auf die Art sein:

typedef struct
{
  uint8_t               s_startcycles;                                        // number of start cycles
  uint16_t              s_datacount;                                          // number of data bytes
  uint8_t               s_data[700];                                          // data bytes
} IRMP_DATA_LOGGING;

/*---------------------------------------------------------------------------------------------------------------------------------------------------
 *  Get IRMP logging data for USB
 *  @details  gets logged data
 *  @param    pointer in order to store logged data
 *  @return    TRUE: successful, FALSE: failed
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
irmp_get_logging_data (IRMP_DATA_LOGGING * irmp_data_logging_p)
{
  irmp_data_logging_p->s_startcycles = s_startcycles_p;
  irmp_data_logging_p->s_datacount = s_datacount_p;
  memcpy(&irmp_data_logging_p->s_data[0], &s_data_p[0], s_datacount_p);
  
  if ( irmp_logging_ir_detected )
  {
    irmp_logging_ir_detected = FALSE;
    return !irmp_logging_ir_detected;
  }   
  else
  {
    return irmp_logging_ir_detected;
  }
}

static volatile uint8_t                     s_startcycles_p;
static volatile uint16_t                    s_datacount_p;
static volatile uint8_t                     s_data_p[700];
static volatile uint8_t            irmp_logging_ir_detected;

static void
irmp_logIr (uint8_t val)
{
    static uint8_t  s_data[c_datalen];                                  // logging buffer
    static uint16_t s_dataIdx;                                          // number of written bits
    static uint8_t  s_startcycles;                                      // current number of start-zeros
    static uint16_t s_ctr;                                              // counts sequenced highbits - to detect end

    if ((val == 0) && (s_startcycles < c_startcycles) && !s_dataIdx)    // prevent that single random zeros init logging
    {
        ++s_startcycles;
    }
    else
    {
        s_startcycles = 0;
        s_startcycles_p = 0;
        s_datacount_p = 0;

        if (    (val == 0)                                              // start or continue logging on "0"
            || ((val == 1) && (s_dataIdx != 0)))                        // "1" cannot init logging
        {
            if (val)
            {                                                           // set or clear bit in bitarray
                s_data[(s_dataIdx / 8)] |=  (1<<(s_dataIdx % 8));
            }
            else
            {
                s_data[(s_dataIdx / 8)] &= ~(1<<(s_dataIdx % 8));
            }

            ++s_dataIdx;

            if (val)
            {                                                           // if high received then look at log-stop condition
                ++s_ctr;

                if (s_ctr > c_endBits)
                {                                                       // if stop condition (200 sequenced ones) meets, output on uart
                    uint16_t i;
                    s_datacount_p = c_startcycles;

                    for (i = 0;i < (s_dataIdx - c_endBits + 20) / 8; ++i)       // transform bitset into uart chars
                    {
                      s_datacount_p++;
                      s_data_p[i] = s_data[i];
                    }

                     irmp_logging_ir_detected = TRUE;
                    s_dataIdx = 0;
                }
            }
            else
            {
                s_ctr = 0;
            }
        }
    }
}

Muss ich mich aber noch durch arbeiten!!

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...

... aber nur wenn DIESE source-Datei neu übersetzt wird.
Im Makefile also ein "touch" auf diese Datei einfügen.

Danke,
aber es ist ja nicht das eigentliche Build-Date, sondern die Version
(Build Date) von Irmp ;)

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.

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

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:

The DLL PluginName is: USB IR Remote Receiver

The DLL version is: 1.0.0.3

The DLL Copyright is: written 2010 by Portisch

Please define if DLL init by native IR Data or by PAnsiChar!
Press [1] for native IR Data
Press [2] for IR Data in PAnsiChar

Please enter a command!
Init DLL with InitPAnsiChar successfull

Press [s] to show settings dialog
Press [x] to exit

Please enter a command!
IR Data received: Protocol: NEC, Address: 0x7282, Command: 0x0084, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7080, Command: 0x00C7, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7080, Command: 0x00C1, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7282, Command: 0x00D0, Flags: 0x00
IR Data received: Protocol: NEC, Address: 0x7282, Command: 0x00D1, Flags: 0x00

*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

Schau einmal in das PDF:
http://www.promixis.com/pdfs/GirderUserManual.pdf

Punkt 6.13 Window Picker

Bei diesem Fenster kann man definieren wohin der Befehl geschickt werden
soll.

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)

28.04.2010:
    DLL:    v1.0.0.5, Added possibility to flash or update the device firmware direct with the USB IR Remote Receiver settings/option dialog.
    AVR:   Bugfix code repeats
                Updated Irmp to 28.04.2010
                Added modified booloadHID to be able to flash the device without setting a jumper or needed disconnect/reconnect of the device
                The booloadHID will boot if:
                    + no USB IR Remote Receiver firmware is flashed
                    + jumper is set
                    + 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!

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
> 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 Beitrag "Brauche Hilfe beim Bau einer Uhr", 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

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 nochmal...

Kannst du mal testen ob das Tool http://www.eventghost.org/ geht? die
haben ein HID Plugin:
http://www.eventghost.org/forum/viewtopic.php?t=571

>> 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!

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

Update 18.05.2010

USB IR Remote Receiver

Neue IRMP Version - siehe Beschreibung im Artikel

Hugo Portisch schrieb:

> Neue IRMP Version - siehe Beschreibung im Artikel

Du bist aber flott :-)

Gruß,

Frank

Ehrlich gesagt habe ich heute zufällig gesehen das es eine neu IRMP
Version gibt ;)

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.

Nur ein kurzes Update für Irmp vom 26.06.2010:

USB IR Remote Receiver

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

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

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.

@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.

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 :

Jan 30 11:18:31 ion kernel: [ 1735.172036] usb 4-1: new low speed USB device using uhci_hcd and address 12
Jan 30 11:18:31 ion kernel: [ 1735.356189] usb 4-1: configuration #1 chosen from 1 choice
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 :

ll /dev/input/wake-up
insgesamt 0
drwxr-xr-x 2 root root  80 2011-01-30 11:36 ./
drwxr-xr-x 5 root root 320 2011-01-30 10:49 ../
lrwxrwxrwx 1 root root  17 2011-01-30 11:36 pci-0000:00:1d.2-usb-0:1:1.0 -> ../../usb/hiddev0

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

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!

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.

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.

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

> 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...

> Gibt es deinerseits Bestrebungen das für MediaPortal zu realisieren?
Eigentlich schon, aber ich finde kein Source Beispiel wie das in
Mediaportal funktioniert!

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.

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

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:

#define MAX_REMOTE_CONTROLS     2    // 2 remote controls, e.g. RC5 + NEC
#define MAX_KEYS                32   // 32 keys per remote control

struct
{
    uint8_t  protocol;
    uint16_t address;
    uint16_t command[MAX_KEYS];
    uint8_t  key[MAX_KEYS];
} cmdkey[MAX_REMOTE_CONTROLS];

uint8_t search_key (uint8_t protocol, uint16_t address, uint16_t command)
{
    uint8_t p;
    uint8_t c;

    for (p = 0; p < MAX_REMOTE_CONTROLS; p++)
    {
        if (cmdkey[p].protocol == protocol && cmdkey[p].address == address)
        {
            for (c = 0; c < MAX_KEYS; c++)
            {
                if (cmdkey[p].command[c] == command)
                {
                    return cmdkey[p].key[c];
                }
            }
            break;
        }
    }
    return (0xff);
}

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

> 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.

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#Sourc...

Zitat:

Möchte man IRMP und IRSND parallel verwenden (also als Sender und
Empfänger) schreibt man die ISR folgendermaßen:

ISR(TIMER1_COMPA_vect)
{
  if (! irsnd_ISR())          // call irsnd ISR
  {                           // if not busy...
      irmp_ISR();             // call irmp ISR
  }
  // call other timer interrupt routines...
}

Das heisst: Nur wenn irsnd_ISR() nichts zu tun hat, dann rufe die ISR des
Empfängers auf. Damit ist der Empfänger solange abgeschaltet, während
irsnd_ISR() noch Daten sendet. Die Timer-Initialisierungsroutine ist für
IRMP und IRSND dann natürlich dieselbe. 

Gruß,

Frank

> 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.

Also ich fände ja auch eine Anbindung an MediaPortal super :)

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.

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...

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.

@ 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").

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.

Hört sich auch gut an mit der Maske. Ich wäre ja dafür auch gleich das
MePo plugin zu machen :P

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.

Warte, ich mache einen Screenshot. Siehe Anhang sry für evtl falsche
Bildgröße, Format, was auch immer ich habe gerade nur sehr wenig Zeit

LG, Hendi

Aktualisierte Version im Anhang. Versuch es mal damit.

@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.

Ahaaaa, na dann probier ich das doch gleich nochmal aus.

>> 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 ;)

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?

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.

Maniac schrieb:
> Ich glaub ich habs gefunden. Folgendes müsste das auf active high ändern
> oder?
>
> irmpconfig.h Zeile 81
>

#define input(x)               ((x) & (1 << IRMP_BIT))

> ändern in
>

#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

#define input(x)                 ((x) & (1 << IRMP_BIT))

ändern in

#define input(x)                 (!((x) & (1 << IRMP_BIT)))

Gruß,

Frank

Dietmar schrieb:
> kann man dieses Projekt auch unter Linux einsetzten?

Wenn du den Thread gelesen hättest wäre dir dieser

Beitrag "Re: USB IR Remote Receiver (V-USB + IRMP)"

aufgefallen.

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?

Will this programmer work ?
http://wearcam.org/ece385/avr/avr_programmer_from_...
asking because i already have it

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.

@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.

Thank You Michael K. (Gast)
I successfully build it..Everything is working fien. Now i want to make
it short and stable (in eventghost read below for the problem)
Now i would like to know few thing also you can consider some bug..

1)Adding short crystal than the long one.
I added full (big) Quartz Crystal Q1 12Mhz it works. I tried to replace
it with 12Mhz Small crystal (cut one) but it doesn't work.. The system
gives error when connected "USB DEVICE NOT RECOGNIZED". Can u tell me
how can i do it ? How to make this circuit short also which component to
use to make it short ? I saw a SMD version above do we have a schematic
or component list ?
small(cut) =
http://webbuilder.asiannet.com/617/comm/upimage/p_...
Full =
http://webbuilder.asiannet.com/617/comm/upimage/p_...

2) DLL intialization and also UNintialize it via windows
In eventghost (program) i add the plugin and done few thing with it. Was
working fien. but there are few things still giving problem...
A---In event ghost the mouse movement doesn't work  (it is so slow
slow). I tried to work that out with mouse relative macro. Can u explain
why we can't use the normal mouse up, down etc thing. This thing works
perfectly with Igorplug and LIRC receivers which i already have but they
have limitation like com port windows xp etc etc.
B---In event ghost even after setting the "DISABLE POWERON
intialization" it doesn't function properly. I mean after selecting the
option it must do this
 a) Do not work after Initialization (by windows ? or by eventghost ?)
 b) Do work after windows shutdown (here is the problem it works one
time after that it doesn't)
So in short,
How to make it work how to intialize the plugin and also UNintialize it
via windows.
How to enable/disable the PowerON function via window "COMMAND LINE"?

3) Can you provide any smaller version of the schematic ? i mean smd and
normal both ? in eagle cadsoft http://www.cadsoftusa.com/?lang=en

4) One thing more will this support windows 7 32bit and also 64bit
version ?

Thank you

VERY GOOD PROJECT I LIKE IT..I am trying to make it work and good. I am
a hobbyist in electronics.

Yes, there is a bug with the "PowerOn Function" in the DLL with
EventGhost.
The function gets disabled but not anymore enabled so you can't switch
on the PC with the optocoupler.
It is already fixed but i missed to upload the new DLL.

I will do this in this week!

New DLL is now online: USB IR Remote Receiver

Hallo!

Ich habe den Empfänger laut Anleitung aufgebaut, funktioniert tadellos.
Allerdings habe ich ein kleines Problem:

Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
einige weitere).
Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
Alle anderen werden einwandfrei erkannt.

Hat jemand eine Idee, woran das liegen könnte?
Der einzige Unterschied in meinem Aufbau ist, daß ich einen TSOP 1136
verwende.....kann es daran liegen?

Daniel S. schrieb:
> Die (Noname) Fernbedienung, welche ich mit dem Empfänger verwenden
> möchte, hat einige Tasten, die nicht erkannt werden ("8", "Mute" und
> einige weitere).

Im IRMP-Artikel findest Du eine kleine Anleitung, wie Du Scans von
Deiner Fernbedienung machen kannst.

  http://www.mikrocontroller.net/articles/IRMP

Zugehöriger Thread:

  Beitrag "IRMP - Infrared Multi Protocol Decoder"

> Diese Tasten funktionieren jedoch über den IgorPlug problemlos.
> Alle anderen werden einwandfrei erkannt.

Wenn Du mir die Scans zuschickst, kann ich den IRMP entsprechend
erweitern.
Ich bräuchte Scans von funktionierenden Tasten, wie 1-7 und 9, und dann
noch die von den nicht-funktionierenden.

Gruß,

Frank

Hallo,
ich habe die Schaltung in SMD nachgebaut, allerdings nicht den ATMEGA8
sondern den ATMEGA168P-20AU genommen und versuche nun den mit Ponyprog
über die parallele Schnittstelle zu programmieren.
Leider klappt das ums verrecken nicht. Nun habe ich hier irgendwo
gelesen, dass Ponyprog den 168p nicht unterstützt.
Stimmt das und wenn ja, mit was programmiere ich das Ding dann? Brauche
ich einen anderen Programmer, bis jetzt habe ich nur das ganz einfache
ISP-Interface (siehe Schaltplan hier vom Projekt).

Vielen Dank
Gruß
Stefan

Habe es selber nicht probiert, aber hier geht es anscheinend:
Beitrag "ATmega168 und PonyProg ?"

Hi,
danke, ich habe mittlerweile AVRdude probiert, damit sieht's bis jetzt
ganz gut aus. Jetzt fehlen mir nur noch die richtigen Fuse-Bits. Das
wird aber hoffentlich auch noch.

Gruß
Stefan

Hallo,
ich beschäftige mich gerade mit V-USB als ich dieses Projekt gefunden
habe, habe ich mir gedacht das es ein guter Einstieg in das Thema wäre.
Mein Problem ist nur das ich keine Verbindung mit dem PC erreiche.

Ich habe mir auf ein Steckboard ein Widerstand-Spannungsteiler aufgebaut
weil ich keine Z-Dioden mit 3.6V habe. Desweiteren habe ich die
usbconfig.h verändert und PD2 an D- und PD3 an D+ sowie einen 1.1k Ohm
Widerstand an PD4 angeschlossen. In Ermangelung eines 68 ohms
Widerstandes habe ich mit parallelgeschalteten Widerständen 88_Ohm
erreicht. Mein Mega8 läuft mit einen 20Mhz Quarz wobei ich mein
compilieren 12Mhz eingestellt habe. Das Gerät wird hin und wieder mal
angezeigt aber wird einfach nicht erkannt. Ständig meint Windows das es
ein "unbekanntes Gerät" sei. Auf was muss ich bei V-USB genau achten
damit ich eine Verbindung bekomme?

im Anhang mal der Spannungsteileraufbau.

Viele Grüße

Hallo,
habe jetzt auch mal den Referenzschaltplan hinzugefügt, den ich versuche
aufzubauen, nur halt mit anderen Bauteilen.
Geht das ganze eigentlich mit 20Mhz und ein Spannungsteiler oder bewege
ich mich in eine völlig falsche Richtung?
Ich habe übrigens die IRMP-Bauteile vollkommen weg gelassen, ich wollte
mich erstmal mit V-USB beschäftigen und das Projekt als mein
Referenzprojekt nehmen.

Irgendwo muss man ja Anfangen :-)

Viele Grüße

@Lars L.
Das kann so wie du es aufgezeichnet hast nicht funktionieren.
Auch habe ich einmal deine Schaltung vereinfacht nachgezeichnet.

1. Du machst einen Kurzschluss mit D+ und D-.
2. Es gehört nur D- auf ~3,6V Pegel, D+ hängt in der "Luft". Es wird nur
der Pegel beider Datenleitungen auf 3,6V begrenzt um keine Probleme mit
moderneren USB Host zu haben.
3. Der 1,5k Ohm Pullup bei D- ist wichtig weil ansonsten der PC nicht
erkennt ob USB 1.11 oder USB 2.0 Device.
4. Die 68 Ohm begrenzen den Strom zwischen AVR und PC in den
Datenleitungen, sonst nichts.

Mit Spannungsteilern das aufzubauen ist nicht so einfach und geht
weniger gut. Der AVR spuckt 5V aus und es dürfen aber nur 3,6V an die
Datenleitung.

Mann kann auch 2x1N4184 Dioden in die Versorgung als Spannungsabfall (5V
- 0,6V - 0,6V = 3,8V) des AVRs hängen - wenn dieser dann noch läuft.
Dann kann man sich die Z-Dioden an den Datenleitungen sparen.

Das einfachste ist und bleiben die 2 Z-Dioden. Die kosten dann auch
nicht die Welt.

Und wenn du mit 12Mhz kompilierst solltest du auch einen 12Mhz Quarz
einsetzen.

Hallo,
danke für die Antwort hat mir erstmal geholfen :-)
Also reintheoretisch und aus mein Bauchgefühl heraus müsste ich also
zwei Spannungsteiler mit widerständen aufbauen und vermutlich noch ein
paar Gleichrichterdioden einbringen damit es keine Rückkopplung gibt und
die Pegel sauber an die Datenleitungen gebracht werden?
Bald ist ja wieder Geld aufn Konto da denke ich mal wird Reichelt ne
Bestellung von mir bekommen :D

Viele Grüße
Lars

Stefan Meyer schrieb:
> Und was auch noch richtig klasse wäre: LEDs, die von einer Software
> angesteuert Zustände anzeigen. Z.B. wenn VDR auf Tuner1 aufzeichnet,
> oder wenn AC3-/DTS Ton aktiv ist, etc.

Dafür würde ich dir dieses Ding hier empfehlen:
http://www.pearl.de/a-HPM1184-5618.shtml

Dafür gibt es einen Hack und Support für VDR mit graphlcd Plugin:
http://www.vdr-portal.de/board1-news/board2-vdr-ne...

Hier noch Infos zum Hack (ist aber etwas veraltet):
http://bastel.dyndns.info/~dockstar/lcd/

Michael K. schrieb:
> Wobei die Hardware natürlich auch unter Linux lauffähig ist, eine
> entsprechende Applikation vorausgesetzt.

Ich habe einen lirc-kompatiblen Daemon auf Basis von inputlirc für den
Receiver geschrieben, läuft ohne Probleme am VDR. Der kann natürlich die
zusätzlichen Features nicht.

Wollte ich bei Gelegenheit mal releasen, aber die Nachfrage nach Linux
Support war bisher eher gering außerdem habe ich meinen Receiver erst
mal wieder eingemottet.

Ich habe den lirc-kompatiblen Daemon hier
http://www.vdr-portal.de/board18-vdr-hardware/boar...
released.

jar schrieb:
> Hintergrund, eigendlich will ich übers Netz (VNC) meinen VCR
> programmieren, brauche also vordergründig IRSND, IRMP wäre ein nettes
> Gimmik zur PC Fernbedienung, der ATmega168 ist ja groß genug für beides
> mit reichlich Protokolle

Habe ich mit meinem Sohn exemplarisch aufgebaut:

     PC -> my-AVR-USB-UART-Converter -> ATTiny85

also nicht über V-USB.

Am Attiny85 (kleiner µC mit nur 8 Pins) hängen TSOPxxxx, IR-Sendediode,
eine LED und RX/TX - realisiert als Soft-UART. Über den Soft-UART nimmt
der ATTiny die Sende-Befehle entgegen und "strahlt" sie mit IRSND ab.
Empfangene IR-Frames über den TSOP sendet er über die Soft-UART an den
PC, damit der PC "lernen" kann.

Wir haben das noch nicht veröffentlicht, weil wir im Moment nur ein
kommandozeilen-orientiertes PC-Programm zum Senden der IR-Befehle und
zum "Lernen" der Codes haben. Das funktioniert aber schon. Im Moment
programmiert mein Sohn noch an der graphischen Benutzeroberfläche,
welche eine frei gestaltbare Fernbedienung unter Windows werden soll.

Wenn Du an der Software für den µC und an dem Kommandozeilenprogramm
interessiert bist, schreib mir eine PN, dann kann ich Dir den aktuellen
Stand schon mal schicken. Damit solltest Du das gewünschte realisieren
können.

Gruß,

Frank

Hallo,

Sorry fuer die dummen Fragen, aber ich habe keine Ahnung von windows und
brauche "Starthilfe":

Ich moechte den USB_Remote_Receiver als Basis verwenden fuer eine
Erweiterung , so dass der Empfaneger per IR oder Funk angesprochen
werden kann und dann einen linux-PC-steuert. Ich habe bereits andere
Anwendungen mit V-USB auf AVR mit Linux zum Spielen gebracht - wollte
aber zuerst alles "out of the box" mit windows ausprobieren.
Ich habe die Original Sources genommen, USE_BOOTLOADER in
configUSBIRREmoteReceiver.h auf 0 gesetzt und alles mit AVR-studio
kompiliert. Ich hoffe, ich brauche den BootLoader nicht, denn ich weiss
ehrlich gesagt nicht wirklich was das ist.
Ich habe das hex-file mit avrdude unter linux geflasht(ATMEGA8-16PU).
Die fuses stehen auf 0xd0(high) und 0xe1 (low).
Wenn ich den controller per USB mit einem windows-XP host verbinde,
erscheint die Meldung: "USB-Geraet wurde nicht erkannt". Ich habe zwar
noch keinen IR-Empfaenger angeschlossen, aber das sollte bis hierher ja
wohl egal sein. Daher hier meine Fragen:

1)Kann ich wie beschrieben ohne den Bootloader arbeiten?

2)Welche fuse-Einstellungen solle ich nehmen (bitte in Hex, in meinem
GUI (avrfuse) heissen die Bits offenbar anders.

3)wie kann ich XP beibringen, die DLL zu laden?

Danke,

Wolfgang

für die Fuses:
http://www.engbedded.com/fusecalc/

Der Bootloader hat den Vorteil:
Es muss nur einmal der Bootloader mit dem Programmer programmiert
werden. Danach kann über die DLL die Firmware einfach neu runtergespielt
werden.
http://www.mikrocontroller.net/articles/USB_IR_Rem...

Wenn der Empfänger am PC nicht erkannt wird:
Ist ein Programm auf dem AVR?
Ist der Pullup R1 in Ordnung?
Richtiger Quarz?

> 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.

Wenn noch immer nichts geht dann einmal R1 von 1,5 KOhm auf 960 Ohm
ändern.

XP kannst du gar nicht beibringen die DLL zu laden:
http://www.mikrocontroller.net/articles/USB_IR_Rem...

Hallo,

ich fuerchte ich brauche noch konkretere Hilfe. Was bisher geschah:
-Ich habe die fuses geaendert auf
 Low:  0x1F
 high: 0xC1

-Ich arbeite weiterhin mit USB_BOOTLOADER = 0

-Mittlerweile scheint XP das device zu erkennen: Im Geraetemanager
werden zwei neue USB-HID-devices als betriebsbereit angezeigt.

-Wenn ich aber .../Demo_Sources/Releases/DLL_Demo.exe anklicke bekomme
ich ein Fenster, in dem ich nur load DLL anklicken kann. Wenn ich das
tue, passiert nichts weiter.

-Wenn ich von der DOS-Console aus DLL_Demo_Console.exe starte, bekomme
ich die Fehlermeldung
ERROR: unable to load DLL

Was mache ich falsch? Muss ich die DLL irgendwo hinkopieren? Welche DLL?

Sorry fuer die dummen Fragen, aber ich bin ein UNIX-Mensch und weiss von
Windows eigentlich nur, wie man es ausschaltet.

Danke

Wolfgang

Wolfgang Buesser schrieb:

> Sorry fuer die dummen Fragen, aber ich bin ein UNIX-Mensch und weiss von
> Windows eigentlich nur, wie man es ausschaltet.

Warum nimmst du dann nicht einfach irmplircd den Daemon für Linux?

http://www.vdr-portal.de/board18-vdr-hardware/boar...

Danke fuer den link. Das ist ziemlich genau das, was ich machen will!
Werde ich testen.
Mittlerweile laeufts auch unter windows (ich musste die DLL neben das
.exe kopieren). Ein 3-zeiliges howto auf der Webseite waere vielleicht
hilfreich.
Gibt es eigentlich zu IRSND auch einen V-USB-wrapper? So wie ich das
verstehe stellen die sources "nur" eine subroutine zur Verfuegung.

Wolfgang

@Moto:
Dazu sind mehr Infos notwendig? Ist der Source neu kompeliert worden?
Für welche Frequenz, welche Frequenz hat der Quarz,....
Bei den Fusebits muss der 2048 Bytes Bootloader aktiviert sein...

Moto schrieb:
> ich habe mir den USB IRMP als prototyp auf lochraster nachgebaut, das
> flaschen ging einwandfrei (bootloadHID.hex aus atmaga8/default/).
> allerdings wir er jetzt von windows als unknowen device erkannt. jemand
> eine idee woran das liegen könnte?

Wie immer am Erbauer.

Habe die Schaltung laut Schaltbild aufgebaut.
(alle Teile außer Jumper und Pony-Interface)
Nur den Bootloader geflasht.

Beim Einstecken wird er bereits als HID Interface erkannt.
Also nix unbekanntes!

Die Firmware ist noch nicht drauf, nur der Bootloader!


Peter

Moto schrieb:
> Leiter bahnen sollten passen bauteile eben so. Kalte lötstellen waren
> unter dem mikroscope auch keine ersichtlich

Mein Hinweis sollte Dir dienen um den Fehler in
der selbstgebauten Hardware zu suchen.

Finden ist da wohl nicht Deine Stärke.

Antworten wie "sollten passen" sind schlecht bzw. oberflächlich.
Kalte Lötstellen und Mikroskop, haha.
Mit dem Ohmmeter "durchgeklingelt" wäre schon besser.

Der fertigen Software nicht trauen,
dann selbst kompilieren und klappt auch nicht,
meinem Hinweis auf "aufgebaut und klappt"
und den erfolgreichen vorgenannten Erfolgsmeldungen
auch keinen Glauben schenken.

Ich würde Dir ja eine Leiterplatte überlassen,
aber wenn Du die dann fehlerhaft aufbaust ziehst Du mich runter.

Peter

Stelle doch mal ein Bild Deiner Hardware hier ein.

Ich selber habe bei meinem letzen Aufbau mit der Tonertransfermethode:
http://www.mikrocontroller.net/articles/USB_IR_Rem...

eine TSOP4838 verwendet. Die ist um einiges kleiner als die "alte" TSOP
1738. Geht ohne Probleme!

Wichtig für die IR-Diode ist:
>> Die maximale Versorgungsspannung muss 5V oder höher sein
>> Frequenz für das benutzte IR Protokoll (meistens 38kHz ausreichend)
>> Ausgang Active Low. Dies kann aber sicher ansonsten im IRMP Source >>
irgendwo ausgedreht werden.

@ Andy P.
Was genau willst du denn erreichen? Aus Windows/Linux heraus IR codes
senden, oder empfangene codes weiterreichen?

Ich arbeite gerade an einer Version, die letzteres kann und
darüberhinaus eine Uhr zum Aufwecken des PCs und die Möglichkeit den PC
zu resetten beinhaltet. Ich hatte aber auch schon darüber nachgedacht
eine Funktion zum Senden von IR codes von Windows/Linux zu
implementieren. Wäre keine große Sache mehr.

Leider kann ich nur gelegentlich abends daran arbeiten, weswegen das
Ganze schon eine Weile dauert und auch noch eine Weile dauern wird.
Wobei die Firmware schon recht weit ist, die Host-Software ist noch die
größere Baustelle.

@Andy P.
schaut nicht so schlecht aus. Kann es leider nicht durchtesten da ich
hier kein AVR 4.x Studio habe.

Der usbHidReportDescriptor scheint richtig zu sein. Die Länge passt dann
auch.

Vom PC schickt man dann per SetFeature:
http://msdn.microsoft.com/en-us/library/windows/ha...

die Daten zum AVR.

Der ReportBuffer ist dann:
0A   >> Report ID
02   >> Protokol ID
0000 >> Adresse
0000 >> command
00   >> Flags

  else if ( DoWriteReport == SndIRCodeOut )
  {
   irmp_data.protocol = IRMP_NEC_PROTOCOL;
     irmp_data.address  = 0x00FF;
     irmp_data.command  = 0x0001;
     irmp_data.flags    = 0;
     irsnd_send_data (&irmp_data, TRUE);                          // Send IR code out
  }

Sollte dann so sein:

  else if ( DoWriteReport == SndIRCodeOut )
  {
    memcpy(&irmp_data, &data[1], sizeof(irmp_data));    
    irsnd_send_data (&irmp_data, TRUE);                          // Send IR code out
  }

Ist aber nicht getestet und mit irsnd habe ich gar keine Erfahrung...
Bei Delphi ist es zusätzlich wichtig ein "Packed" Record zu verwenden.
http://www.delphibasics.co.uk/RTL.asp?Name=Packed

Ich glaub, dass ist aber Visual Studio sowieso so!?

Jetzt wirklich ungetestet, da ich hier keinen Receiver rumliegen habe!

Im AVR Source ist nun IRSND eingebaut, per USE_IRSND deaktivierbar.
Das kompelierte HEX ist für den Atmega168(p), 12MHz.
Zum IR-Senden wird PD3 verwendet.

In IRSND nur die Standard Protokolle aktiviert.

Anbei auch eine Überarbeitung der Delphi Demo wo man nun einen IR Code
zum AVR schicken kann. (Auch nicht getestet)

Frage zwischendurch da ich IRSNd noch nie benützt habe:
Kann ich einfach eine alte Fernbedienung wegen der IR Diode
ausschlachten!?
Muss diese über einen Transistor geschaltet werden oder kann ich die
Diode direkt auf den Ausgang des AVRs hängen?

EDIT:
Jetzt habe ich ganz vergessen, dass dieses Projekt mit AVR Studio 5
bearbeitet wurde!