Forum: Projekte & Code IRMP - Infrared Multi Protocol Decoder


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
Aktualisierung
Die IRMP-Software kann unter IRMP --> Download
heruntergeladen werden.


Hallo zusammen,

Anmerkung:

Dieser Source entstand im Rahmen des Projektes "WordClock", siehe

Artikel

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

bzw. Thread, der alles zum Auslösen gebracht hat:

   http://www.mikrocontroller.net/topic/156661

Da RC5 nicht nur veraltet, sondern mittlerweile obsolet ist und immer 
mehr die elektronischen Geräte der fernöstlichen Unterhaltungsindustrie 
in unseren Haushalten Einzug finden, ist es an der Zeit, einen 
IR-Decoder vorzustellen, der ca. 90% aller bei uns im täglichen Leben zu 
findenden IR-Fernbedienungen "versteht".

IRMP - der Infrarot-Fernbedienungsdecoder, der mehrere Protokolle auf 
einmal decodieren kann, beherrscht folgende Protokolle:

SIRCS:      Sony.
NEC:        NEC, Yamaha, Canon, Tevion, Harman/Kardon, Hitachi, JVC,
            Pioneer, Toshiba, Xoro, Orion, NoName
            und viele weitere japanische Hersteller.
SAMSUNG:    Samsung
MATSUSHITA: Matsushita
KASEIKYO:   Panasonic, Denon und andere japanische Hersteller, welche 
Mitglied
            der  "Japan's Association for Electric Home Application" 
sind.
RECS80      Philips, Nokia, Thomson, Nordmende, Telefunken, Saba


Zum Source-Code

irmp.c:

Zu Anfang werden die verschiedenen Signalformen und -Zeiten 
dokumentiert. Ein Blick darauf zum Verständnis ist bestimmt ganz 
interessant :-)

IRMP decodiert sämtliche oben aufgelisteten Protokolle in einer ISR. 
Möchte man davon einige aus Platzgründen deaktivieren, sind die 
entsprechenden Werte in irmp.c

#define IRMP_SUPPORT_SIRCS_PROTOCOL           1 // flag: support SIRCS, 
1=yes, 0=no
#define IRMP_SUPPORT_NEC_PROTOCOL             1 // flag: support NEC, 
1=yes, 0=no
#define IRMP_SUPPORT_SAMSUNG_PROTOCOL         1 // flag: support 
Samsung, 1=yes, 0=no
#define IRMP_SUPPORT_MATSUSHITA_PROTOCOL      1 // flag: support 
Matsushita, 1=yes, 0=no
#define IRMP_SUPPORT_KASEIKYO_PROTOCOL        1 // flag: support 
Kaseikyo, 1=yes, 0=no
#define IRMP_SUPPORT_RECS80_PROTOCOL          1 // flag: support RECS80, 
1=yes, 0=no

auf 0 zu setzen. Dann wird der Decoder für diese Protokolle nicht 
mitübersetzt.

Diese Protokolle weisen Bitlängen - teilweise variabel, teilweise fest - 
von 12 bis 48 Bit auf. Diese werden über Preprocessor-Defines 
beschrieben.

IRMP trennt diese IR-Telegramme prinzipiell in 3 Bereiche:

 1. ID für verwendetes Protokoll
 2. Adresse bzw. Herstellercode
 3. Kommando

Mittels der Funktion

   irmp_get_data (IRMP_DATA * irmp_data_p)

kann man ein decodiertes Telegramm abrufen. Der Return-Wert ist 1, wenn 
ein Telegramm eingelesen wurde, sonst 0. Im ersten Fall werden die 
Struct-Members

      irmp_data_p->protocol
      irmp_data_p->address
      irmp_data_p->command

gefüllt, einen Beispiel-Aufruf nebst Erklärung findet man in main.c, 
welches lediglich ein Grundgerüst darstellen soll.

Das "Working Horse" von IRMP ist die Interrupt Service Routine 
irmp_ISR() welche 10.000 mal pro Sekunde aufgerufen werden sollte. 
Weicht dieser Wert ab, muss die Preprocessor-Konstante F_INTERRUPTS 
angepasst werden. Dieser kann durchaus höher werden, aber nicht 
wesentlich kleiner. Sonst wird es kritisch mit der Protokoll-Erkennung.

irm_ISR detektiert zunächst die Länge und die Form des/der Startbits und 
ermittelt daraus das verwendete Protokoll. Sobald das Protokoll erkannt 
wurde, werden die weiter einzulesenden Bits parametrisiert, um dann 
möglichst effektiv in den weiteren Aufrufen das komplette IR-Telegramm 
einzulesen.

Um direkt Kritikern den Wind aus den Segeln zu nehmen:

Ich weiss, die ISR ist ziemlich groß. Aber da sie sich wie eine State 
Machine verhält, ist der tatsächlich ausgeführte Code pro Durchlauf 
relativ gering. Solange es "dunkel" ist (und das ist es ja die meiste 
Zeit ;-)) ist die aufgewendete Zeit sogar verschwindend gering. Im 
WordClock-Projekt werden mit ein- und demselben Timer 8 ISRs aufgerufen, 
davon ist die irmp_ISR() nur eine unter vielen. Bei mindestens 8 MHz 
CPU-Takt traten bisher keine Timining-Probleme auf. Daher sehe ich bei 
der Länge von irmp_ISR überhaupt kein Problem.

Achja, ein Quarz ist nicht unbedingt notwendig, es funktioniert auch mit 
dem internen Oszillator des AVRs, wenn man die Prescaler-Fuse 
entsprechend gesetzt hat, dass die CPU auch mit 8MHz rennt ... Die 
Fuse-Werte für einen ATMEGA88 findet man in main.c

Zur Hardware: IRMP sollte so ziemlich für alle ATMegas übersetzbar sein, 
das Beispiel-Projekt wurde auf ATMEGA88 eingestellt.

Der Pin, an dem der IR-Empfänger angeschlossen wird, ist frei wählbar 
und wird in irmp.c über

    #define IRMP_PORT  PORTB
    #define IRMP_DDR   DDRB
    #define IRMP_PIN   PINB
    #define IRMP_BIT   6       // use PB6 as IR input

eingestellt.

Als letztes:

irmp.c lässt sich auch unter Linux direkt kompilieren, um damit 
Infrarot-Scans, welche in Dateien gespeichert sind, direkt zu testen. Im 
Unterordner IR-Data finden sich solche Dateien, die man dem IRMP direkt 
zum "Fraß" vorwerfen kann, nämlich folgendermaßen:

  cc irmp.c -o irmp                              # IRMP compilieren
  ./irmp.c < IR-Data/Samsung_DVD_Rec_00062C.txt  # irmp ausführen

IRMP gibt dann das erkannte Protokoll und weitere Timing-Daten aus. 
Diese Dateien haben mir bei der Entwicklung des IRMP enorm geholfen, 
Dank an Vlad Tepesch, der diese Dateien mittels 10000Hz-ISR gescannt und 
über UART protokolliert hat!

Achja: Der Decoder für das RECS80-Protokoll ist ungetestet und wurde 
anhand von Dokumentationen im Internet erstellt und lediglich mittels 
künstlich erzeugten Scan-Dateien getestet... daher: keine Gewähr!

Viel Spaß damit!

Frank M.

von I. E. (anfaenger69)


Bewertung
0 lesenswert
nicht lesenswert
Sehr geil, ich werde mal schauen, ob ich es zum laufen bekomme. Ich habe 
eine ähnliche Sache gebaut: Eine lernbare Fernbedienung.

Ich verwende jedoch keine 10000Hz Routine, die die Sachen einscannt, 
sondern ich lege den IR Eingang auf den externen IRQ0 Pin und erkenne 
das Ende des IR Codes mit dem ISR(TIMER1_OVF_vect). Die Hauptroutine hat 
in dieserm Fall gar nichts mehr zu machen und kann sich auf etwas ganz 
anderes konzentrieren, man spart sich die Preprozessor-Konstante:

int main(){
    TCNT1 = 0;          //Timer1 gestoppt lassen, bei 65ms Überlauf
    IRQ0_aktivieren();    //INT0_vect wartet auf erste IR Signal flanke


    while (etwas_empfangen){
        empfangspuffer_auswerten();
        ausgabe_auf_dem_lcd_display();
        etwas_empfangen = 0;
    }
}

ISR(INT0_vect){
    empfangspuffer(position) = TCNT1;   //gemessene Flankenlänge
                                        // abspeichern
    position++          //für die nächste Abspeicherung vorbereiten
    TCNT1 = 0;                //Timer auf 0 zur Messung der nächsten
                              //Flankenlänge
    Timer1_aktivieren();
}

ISR(TIMER1_OVF_vect){         //IR Ende wenn 65ms keine Flankenänderung
    Timer1_deaktivieren();
    etwas_empangen = 1;       //nun kann main es auswerten
    empfangspuffer(position) = 60000  //IR Ende Markierung in den Puffer
                                      // schreiben. Eindeutig, weil
                                      //keine IR Flanke wäre 60ms lang
}


Der Empfangspuffer sieht dann so aus:

17382   //erste Messung ist müll, je nach dem wann erste IR Flanke kam
09000   //Start Bit 9000ms
00560   //erstes Pausensignal 560ms
00560   //erstes Datenbit
00560   //Pausensignal zum Datenbit
01200   //zweites Datenbit
00560   //Pausensignal zum Datenbit
.
.
.
60000   //Ende Markierung

Die Auswertung ist dann einfach, wie z.B. Du sie selbst geschrieben 
hast. Ich selbst habe keine Auswerung geschrieben, sondern ich lege die 
Daten in einem EEPROM ab und sende sie auf Befehl wieder raus:

int main(){
    pin_ir = 0;
    position ++        //erste Müllmessung im Puffer ignorieren
    TCNT1 = empfangspuffer(position);  //Timer1 füttern
    position ++        //Puffer auf nächste Position
    Timer1_aktivieren();

    while (1);               //keine weiteren Aktionen mehr,
                             // sendung erfolgt automatisch über IRQ
}

ISR(TIMER1_OVF_vect){
    port_ir ^= (1<<pin_ir);           //IR Ausgang einfach nur toggeln
    TCNT1 = (65535-empfangspuffer(position));     //Timer neu füttern
    if (empfangspuffer(position) == 60000) timer1_deaktivieren;
    position++           //Puffer auf nächste Position
}

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll? 
Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und 
das Ergebnis in eine FIFO legen. Eine Dekoderfunktion sammelt die Werte 
aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin 
liegt der Vorteil Deiner Implementierung?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll?
> Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und
> das Ergebnis in eine FIFO legen.

Das verbraucht aber dann evtl. ne Menge Speicherplatz. Wenn ich da ans 
Kaseikyo-Protokoll mit 48 Bit denke, müsste ich 48 x 2 = 92 Bytes haben, 
um die Timingwerte für jede Hell-/Dunkelsequenz zu speichern.

> Eine Dekoderfunktion sammelt die Werte
> aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin
> liegt der Vorteil Deiner Implementierung?

Der Vorteil liegt beim niedrigen Speicherbedarf. Nach dem eingetroffenen 
Startbit wird das Protokoll sofort erkannt und dann werden die weiteren 
Hell-Dunkelphasen nur noch als einzelne Bits gespeichert, weil sich die 
ISR aufs Protokoll "eingeschossen" hat. So kommt man mit 5 Bytes aus, in 
denen alles nötige gespeichert ist - hier als struct definiert:
typedef struct
{
  uint8_t   protocol;          // protocol, i.e. IRMP_NEC_PROTOCOL
  uint16_t  address;           // address
  uint16_t  command;           // command
} IRMP_DATA;


Das heisst: am Ende bekommt man dann über irmp_get_data() einfach drei 
Werte, die man über ein if oder switch checken kann, z.B. hier eine 
Routine, welche die Tasten 1-9 auf einer Fernbedienung auswertet:
   if (irmp_data.protocol == IRMP_NEC_PROTOCOL &&     // NEC-Protokoll
       irmp_data.address == 0x00FF)                   // Adresse 0x00FF
   {
      switch (irmp_data.command)
      {
         case 0x0001: key1_pressed(); break;          // Taste 1
         case 0x0002: key2_pressed(); break;          // Taste 2
         ...
         case 0x0009: key9_pressed(); break;          // Taste 9
      }
   }

Die Werte muss man natürlich für eine unbekannte Fernbedienung einmal 
auslesen und dann über ein UART oder LC-Display ausgeben, um sie dann im 
Programm hart zu kodieren. Oder man hat eine Anlernroutine, wo man 
einmal die gewünschten Tasten drücken muss, um sie anschließend im 
EEPROM abzuspeichern.

Einfacher gehts doch nicht, oder?

Gruß,

Frank

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
wie erkennst du zb wenn per Fernbedienung ein Lautstärkekomando kommt.
Soweit ich das bei deinem Code erkennen konnte wird der empfangene Code 
nur 1x ausgewertet.
Wie geht das beim Sircs Protokoll? ein Kommando wird 3x wiederholt, nach 
der wiederholung müsste man das kommando erneut auslösen.

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> eku schrieb:
>
>> In Deiner ISR wird bereits das Protokoll erkannt. Ist das sinnvoll?
>
>> Könnte man nicht den IR-Eingang im konstanten Timerraster abtasten und
>
>> das Ergebnis in eine FIFO legen.
>
>
>
> Das verbraucht aber dann evtl. ne Menge Speicherplatz. Wenn ich da ans
>
> Kaseikyo-Protokoll mit 48 Bit denke, müsste ich 48 x 2 = 92 Bytes haben,
>
> um die Timingwerte für jede Hell-/Dunkelsequenz zu speichern.
>
>
>
>> Eine Dekoderfunktion sammelt die Werte
>
>> aus der FIFO, erkennt das Protokoll und dekodiert die Sequence. Worin
>
>> liegt der Vorteil Deiner Implementierung?
>
>
>
> Der Vorteil liegt beim niedrigen Speicherbedarf. Nach dem eingetroffenen
>
> Startbit wird das Protokoll sofort erkannt und dann werden die weiteren
>
> Hell-Dunkelphasen nur noch als einzelne Bits gespeichert, weil sich die
>
> ISR aufs Protokoll "eingeschossen" hat. So kommt man mit 5 Bytes aus, in
>
> denen alles nötige gespeichert ist

Das habe ich soweit verstanden. Würdest Du die Daten jedes Protokolls
in einer Struktur zusammenfassen, bräuchtest Du nur einen Zeiger auf
die jeweilie Struktur (=Protokoll) setzen und nicht so viele statisch 
Variablen in der ISR initialisieren. Die einen Indirektion bei der 
Adressierung sollte auf Grund der anderen Ersparnis nicht ins Gewicht 
fallen. Der Code würde noch dazu leserlicher.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian___ schrieb:
> Hallo Frank,
> wie erkennst du zb wenn per Fernbedienung ein Lautstärkekomando kommt.
> Soweit ich das bei deinem Code erkennen konnte wird der empfangene Code
> nur 1x ausgewertet.

Der Code wird lediglich innerhalb einer gewissen Zeitspanne ignoriert, 
nämlich innerhalb der Wiederholungszeitspanne.

> Wie geht das beim Sircs Protokoll? ein Kommando wird 3x wiederholt, nach
> der wiederholung müsste man das kommando erneut auslösen.

Nein, soviel ich weiß, wird bei SIRCs nach den Wiederholungen dann das 
Kommando erneut gesandt, wenn Du die Taste gedrückt hältst. Aber erst 
nach einer gewissen Pause, die wesentlich größer ist als die Zeitspanne 
zwischen 2 Wiederholungen. Und dann greift die ISR wieder zu.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Das habe ich soweit verstanden. Würdest Du die Daten jedes Protokolls
> in einer Struktur zusammenfassen, bräuchtest Du nur einen Zeiger auf
> die jeweilie Struktur (=Protokoll) setzen und nicht so viele statisch
> Variablen in der ISR initialisieren. [...]

Stimmt.

> [...] Die einen Indirektion bei der
> Adressierung sollte auf Grund der anderen Ersparnis nicht ins Gewicht
> fallen. Der Code würde noch dazu leserlicher.

Hm, ob ich da tatsächlich was einspare? Werde mir den Code diesbezüglich 
demnächst nochmal anschauen.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Frank M. schrieb:
> Nein, soviel ich weiß, wird bei SIRCs nach den Wiederholungen dann das
>
> Kommando erneut gesandt, wenn Du die Taste gedrückt hältst. Aber erst
>
> nach einer gewissen Pause, die wesentlich größer ist als die Zeitspanne
>
> zwischen 2 Wiederholungen. Und dann greift die ISR wieder zu.

Mir gefällt dieses Ping-Pong zwischen ISR und main() nicht. Die ISR 
wartet mit der Erkennung bis main() vorheriges abgeholt hat. Eine 
FIFO entkoppelt die Routinen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Mir gefällt dieses Ping-Pong zwischen ISR und main() nicht. Die ISR
> wartet mit der Erkennung bis main() vorheriges abgeholt hat. Eine
> FIFO entkoppelt die Routinen.

Die ISR wartet nicht (eine ISR sollte niemals warten), sie ignoriert 
halt IR-Befehle, bis die main das letzte Kommando abgeholt hat.

Wenn der Mensch an der Fernbedienung schnell hintereinander 2 Tasten 
drückt, dann willst Du das tatsächlich durch ein FIFO puffern? Zwischen 
den beiden Tastendrücken vergeht für den µC eine Ewigkeit.... bis dahin 
hat er die erste Taste längst abgearbeitet.

Bei einer RS232 halte ich ja ein FIFO für sinnvoll, aber für eine IR-FB? 
Willst Du etwa mit einem IR-Sender Daten mit konstanter Geschwindigkeit 
übermitteln? Ja, dann wäre das sinnvoll. Sonst nicht - für mich 
jedenfalls.

Gruß,

Frank

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
bei SIRC  ist es jeden fall so das man da nicht zwischen den Repeats 
unterscheiden kann.
Taste kurz gedrückt = 3x command im 45ms Raster.
Taste länger gedrückt = nx command im 45ms Raster.
Ich habe mir das mal auf dem Oszi angeschaut. (ist ein Sony DVD Player)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian___ schrieb:
> bei SIRC  ist es jeden fall so das man da nicht zwischen den Repeats
> unterscheiden kann.
> Taste kurz gedrückt = 3x command im 45ms Raster.
> Taste länger gedrückt = nx command im 45ms Raster.

Hm, das ist wirklich blöd. Leider habe ich keine Sony-Fernbedienung, um 
das zu testen, hatte da lediglich die Scans von Vlad Tepesch.

Ich habe da gerade nochmal in den Source geschaut:
#define SIRCS_REPETITION_TIME                 (uint16_t)(F_INTERRUPTS * 50.0e-3 + 0.5)          // repetition after ~45-50 msec
...
        // if SIRCS protocol and the code will be repeated inside of 50 ms, we will ignore it.
        if (irmp_protocol != IRMP_SIRCS_PROTOCOL || last_irmp_command != irmp_tmp_command || repetition_counter > SIRCS_REPETITION_TIME)
...

Wenn also die Zeiten bei heruntergedrückter Taste tatsächlich nicht 
größer sind als die Wiederholzeit, muss man wirklich erst die Taste 
loslassen....

Dumm gelaufen. Man könnte natürlich bis 3 zählen und die vierte 
Wiederholung wieder zulassen. Fragt sich nur, ob das definitiv immer so 
ist, dass Sony-Fernbedienungen grundsätzlich jeden Code 3 mal 
wiederholen.

Gruß,

Frank

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
um sowas zu testen und solche codes zu simulieren würde ich einen 
simulator für AVRs benutzen - namentlich proteus isis.
gibt viele möglichkeiten, sich dort eine passende quelle 
zusammenzubauen.

demo und info unter: 
http://www.labcenter.co.uk/products/vsm_overview.cfm

frank, falls du das machen willst und ich dir helfen kann, schreib mich 
doch kurz an.

holli

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> um sowas zu testen und solche codes zu simulieren würde ich einen
> simulator für AVRs benutzen - namentlich proteus isis.

Ist erstmal eine gute Idee, aber der Code von irmp trägt den Simulator 
in sich mit :-) Ich kann dem Code (wenn man ihn unter Linux übersetzt) 
einfach eine Datei zum Fraß vorwerfen. Diese Datei kann ein echter Scan 
einer Fernbedienung sein oder eine künstlich erzeugte.

Ein weiterer Simulator wäre daher kein Gewinn für mich - sehe ich 
jedenfalls momentan so. Und er beantwortet mir auch nicht die Frage, ob 
jede Sony-Fernbedienung den Code immer genau 3x wiederholt.

Trotzdem danke für den Tipp, vielleicht kann ich ihn bei Gelegenheit für 
ein ganz anderes Projekt verwenden :-)

@Sebastian___

Ich werde einfach mal meine SIRCS-Scandatei nehmen, ein Telegramm 
(sprich Zeile) ver-N-fachen mit dem Editor, wobei ich eine Pause von 
45ms einbaue. Dann den Code dahingehend ändern, dass er die 4te, 7te, 
10te (usw) Wiederholung wieder auswertet statt sie zu ignorieren.

Wäre Dir damit geholfen?

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir gerade nochmal die gängigen Quellen angeschaut, wo SIRCS 
als Code beschrieben wird. Nirgendwo steht da was von 2 weiteren 
automatischen Wiederholungen (also 3 Telegramme), immer liest man nur 
solches wie dieses:

 "Commands are repeated every 45ms(measured from start to start) for as 
long as the key on the remote control is held down."

Ich habe mir daraufhin nochmal die Scan-Datei Sony_Bravia_RM-ED0009.txt 
näher angeschaut. Da sind die Wiederholungen auch drin, aber offenbar 
nicht für alle Tasten wird wiederholt, z.B.

power, rot, gelb, grün, blau, up, down, left, right, vol+, vol-: keine 
Wiederholung

theatre, digital, tools, buch(?): 2 Wiederholungen, also insg. 3 
Telegramme

Rätselhaft das ganze...

Gruß,

Frank

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Ich kann das ganze ja bei gelegenheit nochmal wiederholen.

vielleicht sind auch zu viele einsen zwischen den wiederholungen, so 
dass meine Scan-Routine, den scan schon vorher abgebrochen hat.
ich hatte da 200 samples gewartet

wenn man sich die wiederholten scans aber anschaut, sieht man, dass die 
wiederholungen nach 190 einsen kommen.
wenn das Kommando also am Ende ein paar einsen hat, dann wird die 
Abrruchbedingung überschritten.


Pack doch den code zum Scannen nochmal mit rein, dann können die anderen 
auch ein paar Scans machen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:

> Pack doch den code zum Scannen nochmal mit rein, dann können die anderen
> auch ein paar Scans machen.

Ich war einfach bisher zu faul, den Code fürs Scanning aus dem 
WordClock-Code zu extrahieren, so dass er isoliert zur Verfügung 
steht...
gebe ich ja zu :-)

Hole ich jetzt nach.

Es wäre klasse, wenn die anderen ihre Fernbedienungen, die bisher nicht 
unterstützt werden, einscannen würden. Dann kann ich den Code diesbzgl. 
erweitern.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Aktualisierung
Die IRMP-Software kann unter IRMP | Download
heruntergeladen werden.



Vlad Tepesch schrieb:

> Pack doch den code zum Scannen nochmal mit rein, dann können die anderen
> auch ein paar Scans machen.

Okay, ich habe nun die nötigen Routinen aus dem WordClock-Source 
extrahiert und direkt mit in irmp.c integriert.

In der Zeile
#define IRMP_LOGGING    0   // 1: log IR signal (scan), 0: do not (default)

kann nun das Logging eingeschaltet werden, wenn man den Wert auf 1 
setzt.

Dann werden die Hell- und Dunkelphase auf dem UART mit 9600Bd 
ausgegeben:

1=Dunkel, 0=Hell. Eventuell müssen dann die Konstanten in den Funktionen 
uart_init() und uart_putc() angepasst werden, kommt auf den verwendeten 
AVR-µC an.

README.txt ist entsprechend angepasst - am Ende der Datei.

Getestet habe ich es allerdings noch nicht... sollte aber passen.

Gruß,

Frank

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade dabei den IRMP Code auf Interrups umzubauhen.
Die Zeitbasis commt aus einem Counter mit 25Khz (per IRQ).
Somit kann das Polling entfallen und man hat eine Speichersparende 
lösung.
Das ist aber nicht ganz so einfach. ;)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian___ schrieb:
> Ich bin gerade dabei den IRMP Code auf Interrups umzubauhen.

Verstehe ich jetzt nicht so recht. Das Ding läuft doch auf 
Interrupt-Basis, nämlich einem Timer-Interrupt.

> Die Zeitbasis commt aus einem Counter mit 25Khz (per IRQ).
> Somit kann das Polling entfallen und man hat eine Speichersparende
> lösung.

Warum ist das speichersparend?

Gruß,

Frank

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ja eben,
das frisst rechenleistung wen man keinen timer irq damit blockieren 
will.
Daher ist es meiner meinung nach besser einen richtigen Init zu nehmen 
der flankengesteuert reagiert. Und nur noch ab und zu mal im timer IRQ 
auf timeout zu prüfen.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian___ schrieb:
> Daher ist es meiner meinung nach besser einen richtigen Init zu nehmen
> der flankengesteuert reagiert.

Ahso, flankengetriggert. Ich hatte da eben was von Zeitbasis gelesen... 
deshalb hatte ich das nicht direkt kapiert. Aber klar, Du brauchst bei 
jeder Flanke auch die dazugehörige Zeit.

Klingt ja ganz gut, bin gespannt.

Aber ich sehe da immer noch nicht die Speichereinsparung, ich lass mich 
da von Dir überraschen ;-)

Gruß,

Frank

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Speichereinsparung war drauf bezogen im Vergleich zu der hier geposteten 
Interruptgesteuerten Routine die ja das komplette data Frame gesichert 
hat und dann in der Main auswertet.

im prinzip geht deine Routine auch flankengetriggert, man muss nur ne 
zeitbasis hinzufügen (aus timer) und für ne abbuchbedingung sorgen wenn 
keine flanken mehr kommen.
Wenn ich soweit bin werde ich mal ein bischen was dazu posten.
Deine Defines der verschiedenen protokolle sind auf jeden fall sehr 
hilfreich.

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo ich habe noch einen kleine Fehler gefunden, das 
MATSUSHITA_PROTOCOL wird nie erkannt, nur das SAMSUNG_PROTOCOL.

die Defines für das erkennen der start Bits haben eine zu große 
Toleranz, wenn man die für :

#define MATSUSHITA_START_BIT_PULSE_LEN_MIN
#define MATSUSHITA_START_BIT_PULSE_LEN_MAX
#define MATSUSHITA_START_BIT_PAUSE_LEN_MIN
#define MATSUSHITA_START_BIT_PAUSE_LEN_MAX

und

#define SAMSUNG_START_BIT_PULSE_LEN_MIN
#define SAMSUNG_START_BIT_PULSE_LEN_MAX
#define SAMSUNG_START_BIT_PAUSE_LEN_MIN
#define SAMSUNG_START_BIT_PAUSE_LEN_MAX

auf 20% setzt, geht die Protokollerkennung.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian___ schrieb:
> die Defines für das erkennen der start Bits haben eine zu große
> Toleranz, wenn man die für :
> [...] auf 20% setzt, geht die Protokollerkennung.

Super, danke für den Tipp! Werde ich anpassen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sebastian___ schrieb:
>> die Defines für das erkennen der start Bits haben eine zu große
>> Toleranz, wenn man die für :
>> [...] auf 20% setzt, geht die Protokollerkennung.
>
> Super, danke für den Tipp! Werde ich anpassen.

Habe ich gerade mal gemacht und gegen die Scan-Datei
Samsung_DVD_Rec_00062C.txt laufen lassen: Bei 20% Toleranz für SAMSUNG 
erkennt die Routine keine Samsung mehr. Selbst bei 40% klappt das nicht 
mehr, erst bei 50% geht es. Das liegt wohl daran, dass Vlads Samsung-FB 
stark von den Timingwerten abweicht... Die 50%, die ich da eingestellt 
hatte, kamen nicht von ungefähr ;-)

Das heisst: Wir haben hier einen Konflikt, beide Startbits (von Samsung 
und Matsushita) sind ähnlich lang - jedenfalls innerhalb der großzügigen 
Toleranzen von 50%.

Wenn Du in der Zeile

#define IRMP_SUPPORT_SAMSUNG_PROTOCOL      1

die 1 auf 0 setzt, sollte die Matsushita auch erkannt werden - ohne 
Änderung der Toleranzen. Hat natürlich den Nachteil, dass immer nur eins 
von beiden Protokollen gleichzeitig erkannt werden kann....

Es gibt einen großen Unterschied zwischen Samsung und Matsushita:

Die Anzahl der Bits pro Telegramm und das Sync-Bit mit sehr langer 
Dunkelphase zwischendrin bei der Samsung, d.h. nach den ersten 16 Bit. 
Damit kann man beide Protokolle definitiv auseinanderhalten.

Kannst Du mir so eine Scan-Datei für die Matsushita erstellen? Dann 
würde ich die Unterscheidung anhand des Sync-Bits einbauen.

Gruß,

Frank

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das ist leider nicht so einfach mit den Daten schicken. Da ich nur 
kleine Teile aus deinem Code nutze und die Codes auf einem Oszi anschaue 
und mit einer Universalfernbedinung teste.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Sebastian___ schrieb:
> Das ist leider nicht so einfach mit den Daten schicken. Da ich nur
> kleine Teile aus deinem Code nutze und die Codes auf einem Oszi anschaue
> und mit einer Universalfernbedinung teste.

Auch gut, dann erstelle ich die Matsushita-Daten künstlich. Die 
Timing-Daten zur Matsushita-FB kannst Du aber schon so bestätigen, oder?

Gruß,

Frank

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
hast du die Abbruchbedingung für die Scans ein wenig angehoben?
200 scheint ja zu kurz zu sein.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> hast du die Abbruchbedingung für die Scans ein wenig angehoben?
> 200 scheint ja zu kurz zu sein.

Nein, habe ich nicht gemacht. Werde ich nachholen.

Gruß,

Frank

von Bastler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hat evtl. jemand von euch ne Apple Fernbedienung aus Alu?

von IR (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Frank M. (ukw):
Ich fände es sehr hilfreich, wenn du den Code mit ein paar kleinen 
Erläuterungen als Artikel hier mit reinstellst und am Besten im "Word 
Clock" Artikel darauf verweist. Das ganze kann man ja schon als 
eigenständig betrachten.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
IR schrieb:
> Ich fände es sehr hilfreich, wenn du den Code mit ein paar kleinen
> Erläuterungen als Artikel hier mit reinstellst und am Besten im "Word
> Clock" Artikel darauf verweist. Das ganze kann man ja schon als
> eigenständig betrachten.

Ich hatte den Code für die IR-Decodierung absichtlich isoliert und hier 
reingestellt, damit er unabhängig vom WordClock-Projekt Verwendung 
findet.

Gern lege ich einen Artikel an, hatte mir Vlad sowieso schon 
vorgeschlagen ;-)

Mache ich am Wochenende.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es gibt nun einen eigenen Artikel zu IRMP. Das hat auch den Vorteil, 
dass die Software zum Download immer auf dem neuesten Stand ist und hier 
der Leser nicht immer erst alle Beiträge lesen muss, um die letzte 
Version zu finden.

Artikel-Link: http://www.mikrocontroller.net/articles/IRMP

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

Software-Stand: 05.02.2010

In dieser Version wurde auch der Konflikt zwischen dem Samsung- und dem 
Matsushita-Protokoll ausgeräumt, beide Protokolle werden nun ohne 
Klimmzüge zuverlässig erkannt.

@Vlad: Sorry, die Scan-Länge habe ich noch nicht vergrößert, hole ich 
nach.

Gruß,

Frank

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi!

Erstmal: danke für dieses schöne Stück code :)

Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir 
bestellt habe ;)
Leider (bestimmt mache ich irgendwas falsch) kann ich mit der IRMP-Lib 
meine "alte" rc5-Fernbedienung nichtmehr auslesen, die ich bisher für 
meine Steuerung verwendet habe. Gibt es eine möglichkeit, dass das alte 
rc5-protokoll auch von der IRMP-Lib erkannt wird?

Gruß, DiPi

p.s.: bisher habe ich diese rc5-routine benutzt: 
Beitrag "Fernbedien RC5 Empfänger"

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Di Pi schrieb:

> Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir
> bestellt habe ;)

Sag mal bitte die Bestellnummer, interessiert mich immer wieder, welche 
FBs damit so laufen...

> Leider (bestimmt mache ich irgendwas falsch) kann ich mit der IRMP-Lib
> meine "alte" rc5-Fernbedienung nichtmehr auslesen, die ich bisher für
> meine Steuerung verwendet habe. Gibt es eine möglichkeit, dass das alte
> rc5-protokoll auch von der IRMP-Lib erkannt wird?

RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe, 
sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir 
nochmal ;-)

Gruß,

Frank

von RC5 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe,
> sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir
> nochmal ;-)

So ziemlich alle FB bei mir laufen auf RC5. Gerade bei Universal-FBs ist 
das noch weit verbreitet und sollte der Vollstädigkeit halber mit 
eingebunden werden. Gerade einfache Projekte im µC Bereich nutzen of 
noch RC5.

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
>> Damit kann ich endlich die Reichelt-RGB-Fernbedienung lesen, die ich mir
>> bestellt habe ;)
>
> Sag mal bitte die Bestellnummer, interessiert mich immer wieder, welche
> FBs damit so laufen...
LED RGB REMOTE
http://www.reichelt.de/?;ARTICLE=92594

von Toralf W. (willi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> RC5 wird von IRMP nicht unterstützt, weil ich RC5 als obsolet ansehe,
> sorry. Wenn Du mir einen triftigen Grund nennst, überlege ich es mir
> nochmal ;-)
>
Stimmt schon, wenn man sich so umsieht bentutzen nur noch die "soliden 
alten deutschen Marken" den RC5 Code. Auf der anderen Seite, ist er sehr 
verbreitet gewesen und deswegen sind Massenhaft gebrauchte RC5 im 
Umlauf, die noch gut weiter verwendet werden könnten. Das spricht für 
RC5.
Ist aber auch so ein Super "gemeinnütziges Projekt".

GrußWilli

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich meinte genau die Remote, die Michael M. genannt hat.

Es wäre eine schöne sache, wenn neben den sechs bereits implementierten 
Protokollen auch noch RC5 vertreten wäre (genauso ein- und 
ausschaltbar), um letztlich so gut wie alle gängigen Protokolle mit 
einer Lib abzudecken.
Dem Programmierer ist dann überlassen, welche Protokolle "gehört" werden 
sollen.

Viele Grüße, DiPi

von Michael M. (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
ich vermute übrigens, die RGB FB sendet NEC-code.
hier mal ein csv-file und bild mit einem scan der off-taste. sample rate
50kHz.
T->A: 9,14ms
A->B: 4,42ms
B->C: 660us

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stimmt: Es wird code 2 (NEC, Pioneer, JVC, Toshiba, NoName etc.) 
erkannt.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> ich vermute übrigens, die RGB FB sendet NEC-code.
> hier mal ein csv-file und bild mit einem scan der off-taste. sample rate
> 50kHz.
> T->A: 9,14ms
> A->B: 4,42ms
> B->C: 660us

Ja, das ist das NEC-Protokoll.

Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel 
dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte 
:-)

Gruß,

Frank

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel
> dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte
> :-)
klar, gerne!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> Frank M. schrieb:
>> Ich habe nun die einzelnen Protokolle vom Timing her im IRMP-Artikel
>> dokumentiert. Wäre nett, wenn ich Dein Bildchen da mit reinhängen dürfte
>> :-)
> klar, gerne!

Danke, ist eingebaut:

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

Gruß,

Frank

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Danke, ist eingebaut
ui, da hat es aber eine prominente position bekommen =)
danke!

grüße,
michael

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> ui, da hat es aber eine prominente position bekommen =)

Ich wollte ein wenig Farbe in den Artikel bekommen ;-)

Aber das Bild ist zweimal drin, weiter unten nochmal miniaturisiert 
unter Angabe Deiner gemessenen Zeiten.

Gruß,

Frank

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
da fällt mir grade was auf:
in dem bild "Anschluß eines IR-Empfängers an µC" ist der im datenblatt 
vorgeschlagene RC tiefpass falsch aufgebaut.
der aufbau in dem bild dürfte die empfindlichkeit um einiges 
verschlechtern.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> in dem bild "Anschluß eines IR-Empfängers an µC" ist der im datenblatt
> vorgeschlagene RC tiefpass falsch aufgebaut.

Du hast Recht: eigentlich gehört der Kondensator direkt zwischen Pin1 
und Pin2 des TSOP, mein Fehler.

> der aufbau in dem bild dürfte die empfindlichkeit um einiges
> verschlechtern.

Davon ist witzigerweise nichts zu merken ;-) Genau mit diesem Fehler 
habe ich mir einen IR-Empfänger aufgebaut, der bei einer Distanz von 5m 
überhaupt keine Probleme hat.

Trotzdem danke für den Tipp, ich habe das Schaltbild korrigiert (evtl. 
muss man einmal im Browser Refresh drücken). Ich werde das bei 
zukünftigen Schaltungen berücksichtigen.

Gruß,

Frank

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der 
Hinweis auf eine noch fehlende Implementierung ist weg.)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Di Pi schrieb:
> Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der
> Hinweis auf eine noch fehlende Implementierung ist weg.)

Nein, der Hinweis ist mir leider beim Bearbeiten der Tabellen 
flötengegangen. Ist nun wieder drin.

Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich 
die spezielle Wiederholungs-Sequenz augesandt wird. Bei meiner Toshiba-, 
Xoro- und Media-Player-Fernbedienung, die allesamt das NEC-Protokoll 
benutzen, wird davon jedenfalls kein Gebrauch gemacht. Stattdessen wird 
einfach der jeweilige Code solange wiederholt, bis man die Taste 
loslässt.

Die Sache mit Erkennung der Wiederholungssequenz steht trotzdem auf 
meiner TODO-Liste.

Gruß,

Frank

von M. K. (kichi)


Bewertung
0 lesenswert
nicht lesenswert
Di Pi schrieb:
> Es wäre eine schöne sache, wenn neben den sechs bereits implementierten
> Protokollen auch noch RC5 vertreten wäre (genauso ein- und
> ausschaltbar), um letztlich so gut wie alle gängigen Protokolle mit
> einer Lib abzudecken.
> Dem Programmierer ist dann überlassen, welche Protokolle "gehört" werden
> sollen.

Der Meinung bin ich auch. Das sollte ja kein großer Mehraufwand sein und 
macht das Projekt auf jeden Fall nicht uninteressanter.

von Frank B. (frank_boe)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich
> die spezielle Wiederholungs-Sequenz augesandt wird.

Meine "Cyberhome" (alter DVD-Player) sendet sie.

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
meine yamaha-fb auch.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> [RC5]
> Der Meinung bin ich auch. Das sollte ja kein großer Mehraufwand sein und
> macht das Projekt auf jeden Fall nicht uninteressanter.

Leider ist das schon einiges an Mehraufwand, denn RC5 passt überhaupt 
nicht in das Schema rein, wie die meisten anderen Protokolle aufgebaut 
sind. RC5 ist bi-phasen-kodiert (Manchester) und damit kann man die Bits 
nicht in das Schema:

0-Bit: m µsec hell, n µsec dunkel
1-Bit: x µsec hell, y µsec dunkel

pressen. Sondern:

0-Bit: m µsec hell, n µsec dunkel
1-Bit: x µsec dunkel(!), y µsec hell(!)

Und da liegt das Problem: je nach Folge der 1en und 0en gibt es 
verschieden lange Hell- oder Dunkelphasen.

Siehe auch: http://www.sbprojects.com/knowledge/ir/rc5.htm

Konsequenz: RC5 muss durch einen Extra-Code geschleust werden. Allein 
schon die Erkennung des Start-Bits als RC5-Code gestaltet sich als 
schwierig. Ursprünglich gab es 2 Start-Bits, die beide "1" sein mussten:

1. Start-Bit: 889µs dunkel, 889µs hell
2. Start-Bit: 889µs dunkel, 889µs hell

Daran ist aussergewöhnlich, dass das Bit mit einer Dunkelphase beginnt, 
das "sieht" man also schon mal gar nicht. Aber man kann das als RC5 
durchaus erkennen, da ja nach den 889µs immer eine Dunkelphase von 
konstant 889µs folgt. Bis dahin passt das alles noch...

Aber:

Das RC5-Protokoll wurde nach einiger Zeit abgeändert ("RC5-Extended") - 
nämlich derart, dass das 2. Start-Bit zu einem invertierten Kommando-Bit 
6 umfunktioniert wurde, um mehr Kommandos umsetzen zu können.

Damit sehen die beiden ersten Bits folgendermaßen aus:

Entweder:

  Start-Bit:      889µs dunkel, 889µs hell
  Kommando-Bit 6: 889µs dunkel, 889µs hell

oder:

  Start-Bit:      889µs dunkel, 889µs hell
  Kommando-Bit 6: 889µs hell, 889µs dunkel

Das heisst: wir haben entweder eine Hellphase von 1 x 889µs bei den 
ersten beiden Bits oder eine Hellphase von 2 x 889µs.

Peter Daneggers RC5-Decoder hat es da wesentlich einfacher: Dieser ist 
fest auf RC5 und dessen Manchester-Codierung fixiert und hart drauf 
programmiert. Wenn man nichts anderes berücksichtigen muss, ist das sehr 
sehr einfach.

Ich werde mir jedoch erst einmal Gedanken machen müssen, wie man 
RC5-Code als solchen überhaupt erkennen kann. Der Rest ist dann einfach: 
sobald klar ist, dass es sich um RC5 handelt, muss dann in der 
State-Machine in einen Manchester-Decoder gesprungen werden - also in 
eine Sonderbehandlung. Da kann dann der Code von Peter Dannegger 
herhalten.

Also bitte etwas Geduld, RC5 kann man nicht einfach durch 
Preprocessor-Konstanten parametrisieren, wie ich das mit den anderen 
Protokollen gemacht habe.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank Boe schrieb:
>> [Wiederholungs-Sequenz beim NEC-Protokoll]
> Meine "Cyberhome" (alter DVD-Player) sendet sie.
Michael M. schrieb:
> meine yamaha-fb auch.

Okay, ich baus ein, ist ja nicht wirklich schwierig :-)

Gruß,

Frank

von Toralf W. (willi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Daran ist aussergewöhnlich, dass das Bit mit einer Dunkelphase beginnt,
> das "sieht" man also schon mal gar nicht. Aber man kann das als RC5
> durchaus erkennen, da ja nach den 889µs immer eine Dunkelphase von
> konstant 889µs folgt. Bis dahin passt das alles noch...
>
Du tastest doch recht oft ab, wenn Du 1x 889µs erkennst passt das doch 
nur als RC5 Startbit.
Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die 
ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt 
wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher 
und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs 
Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den 
Bitspeicher eingeschoben. Das dann bis alle 14 Bits eingesammelt sind.

Gruß Willi

P.s.: ich bewundere Euch, was ihr so alles auf die Reihe bekommt. Seit 
Ihr alle noch ledig, oder habt ihr einfach nur tollerante Frauen? Meine 
hat diese Woche Nachtdienst, da bleibt dann auch mal wieder etwas mehr 
Zeit.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Toralf Wilhelm schrieb:
> Du tastest doch recht oft ab, wenn Du 1x 889µs erkennst passt das doch
> nur als RC5 Startbit.

Fast: es können 1x889µs oder 2x889µs sein - jedenfalls beim extended 
RC5, also da, wo das ursprüngliche 2. StartBit als Kommando-Bit No. 6 
benutzt wird. Aber vielleicht vernachlässige ich das und kümmere mich 
erstmal einfach um das Classic-RC5.

> Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die
> ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt
> wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher
> und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs
> Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den
> Bitspeicher eingeschoben. Das dann bis alle 14 Bits eingesammelt sind.

Danke für den Tipp, das werde ich mir nochmal durch die Gehirnwendungen 
laufen lassen.

> P.s.: ich bewundere Euch, was ihr so alles auf die Reihe bekommt. Seit
> Ihr alle noch ledig, oder habt ihr einfach nur tollerante Frauen?

Verheiratet, Frau ist tolerant und auch toll-erant ;-)

Gruß,

Frank

von Toralf W. (willi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Fast: es können 1x889µs oder 2x889µs sein - jedenfalls beim extended
> RC5, also da, wo das ursprüngliche 2. StartBit als Kommando-Bit No. 6
> benutzt wird. Aber vielleicht vernachlässige ich das und kümmere mich
> erstmal einfach um das Classic-RC5.

Genauso mache ich es, einfach immer extended RC5 und das Bit invertiert 
als Bit6 einfügen.

> Verheiratet, Frau ist tolerant
Du glücklicher!
> und auch toll-erant ;-)
Mist da war sie wieder, meine Legasthenie.

Gruß Willi

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Toralf Wilhelm schrieb:
> Frank M. schrieb:
> Danach muß man ja nicht "ala" Peter weitermachen. Ich zähle einfach die
> ankommenden Pulse, wobei ein 889µs mit 1 und ein 1778µs mit 2 gezählt
> wird. Beim erkannten Startbit schiebe ich die erste 1 in den Bitspeicher
> und dann wird immer wenn der Pulszähler ungerade ist, bei einem 889µs
> Puls das letzte Bit erneut bzw. bei 1778µs letzte Bit invertiert in den
> Bitspeicher eingeschoben.

Habe das jetzt so eingebaut, aber mit einer leichten Änderung des 
Algorithmus: ob das neue Bit invertiert oder nicht invertiert neu 
eingeschoben wird bei einem kurzen Puls, ist nicht abhängig von der 
letzten Pulsdauer, sondern von der Pause davor.

Lange Pause vor kurzem Puls: neues Bit = letztes Bit invertiert
Kurze Pause vor kurzem Puls: neues Bit = letztes Bit

Wahrscheinlich hatte ich Dich da nicht genau verstanden, auf jeden Fall 
läuft das nun. Den Code stelle ich heute abend oder morgen zum Download 
bereit.

Dank und Gruß,

Frank

von Toralf W. (willi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Toralf Wilhelm schrieb:
>> Frank M. schrieb:
>
> Lange Pause vor kurzem Puls: neues Bit = letztes Bit invertiert
> Kurze Pause vor kurzem Puls: neues Bit = letztes Bit
>
> Wahrscheinlich hatte ich Dich da nicht genau verstanden, auf jeden Fall
> läuft das nun. Den Code stelle ich heute abend oder morgen zum Download
> bereit.
>
Ja da habe ich mich nicht sehr deutlich ausgedrückt, ich messe jeden 
Flankenwechsel egal ob Puls oder Pause. Mich interessiert nur die Länge. 
Aber Du hast das schon richtig verstanden.
Gruß Willi

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
RC5 ist nun implementiert, der vom Compiler generierte Code ist kaum 
größer geworden, weil ich noch ein paar Sachen optimiert habe. Download 
findet Ihr im IRMP-Artikel:

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

Noch ein Tipp am Rande:

Jedes von IRMP unterstützte IR-Protokoll "verbrät" ungefähr 200 Byte an 
Code. Wer sparen muss, weil ihm der Flash-Speicher ausgeht, der sollte 
die Unterstützung von KASEIKYO und/oder RECS80 ausschalten. Beides sind 
eher exotische Protokolle, ausserdem ist die Modulationsfrequenz von 
56Khz beim Kaseikyo-Protokoll weit ab von den Frequenzen, die von den 
anderen Protokollen verwendet werden.

Über Feedback zum RC5 würde ich mich freuen, ich habe hier nur mit 
künstlich generierten Scan-Dateien getestet, da ich selbst keine RC5-FB 
habe.

Viel Spaß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version unter http://www.mikrocontroller.net/articles/IRMP#Download 
:

Beim NEC-Protokoll werden nun auch die "Repetition Frames" erkannt. Wenn 
die FB so eine Wiederholungssequenz aussendet, ersetzt IRMP diese 
einfach durch das zuletzt empfangene Kommando.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Habe noch einen Bug korrigiert:

Die Puls/Pausen-Counter waren immer um 1 zu niedrig, das gab manchmal 
Probleme bei der SIRCS-Erkennung bei Sony-FBs mit stark abweichenden 
Timings.

Download-Zip-Datei habe ich aktualisiert.

Gruß,

Frank

von Simon K. (simon) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wie testest du das eigentlich? Hast du von jedem Protokoll ne 
Fernbedienung zuhause? ;) Oder haste bei nem Pollin 
1kg-Fernbedienungspaket zugegriffen hehe.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Wie testest du das eigentlich?

Steht im ersten Beitrag ganz oben, nicht gelesen? ;-)

irmp kann man auch unter Linux compilieren und dann mit einer Scan-Datei 
füttern. Wie man eine Scan-Datei mit IRMP erstellt, ist ebenso oben 
beschrieben. Ich teste den Code ausschließlich unter Linux, das geht 
wesentlich einfacher und schneller. Wenn dann alles wie gewünscht läuft, 
schicke ich den Source noch einmal durch den AVR-Compiler und flashe ihn 
dann.

> Hast du von jedem Protokoll ne Fernbedienung zuhause? ;)

Nein, 7 von 9 Fernbedienungen bei mir arbeiten mit dem NEC-Protokoll. 
Dann habe ich noch eine Samsung. Den Rest teste ich entweder mit 
Scan-Dateien, die mir Vlad Tepesch zur Verfügung gestellt hat (steht 
auch oben) oder mit künstlich erzeugten Dateien, die man einfach mit 
einem ASCII-Editor erstellt. Jedes Telegramm wird einfach pro Zeile mit 
0en (Puls) und 1en (Pause) beschrieben, fertig. Beispiel-Dateien sind im 
ZIP-Archiv enthalten.

> Oder haste bei nem Pollin 1kg-Fernbedienungspaket zugegriffen hehe.

Tatsächlich habe ich mir einen Packen Technisat-FBs für 95 Cent das 
Stück von Pollin kommen lassen, diese wurden (jedenfalls vor ein paar 
Wochen) nicht von IRMP erkannt. Entweder ist das RC5 (welches erst 
kürzlich auf besonderen Wunsch dazukam) oder noch was anderes... Mal 
sehen, bin zum Testen mit realer Hardware schon länger nicht mehr 
gekommen.

Wenn mir jemand Scan-Dateien schickt, welche von IRMP nicht erkannt 
wird, prüfe ich das und baue den Decoder dafür ein, wenn ich das für 
sinnvoll halte. Aber ich bin der Meinung, dass IRMP bereits jetzt über 
90% aller Fernbedienungen, die heutzutage so im Umlauf sind, bereits 
erkennt.

Gruß,

Frank

von Toralf W. (willi)


Bewertung
0 lesenswert
nicht lesenswert
> Tatsächlich habe ich mir einen Packen Technisat-FBs für 95 Cent das
> Stück von Pollin kommen lassen, diese wurden (jedenfalls vor ein paar
> Wochen) nicht von IRMP erkannt. Entweder ist das RC5 (welches erst
> kürzlich auf besonderen Wunsch dazukam)

Genau so ist es!

RC5: fast alle Philips, Grundig, Metz, Loewe, Technisat, (ich glaube 
auch alles was Thomson war - Telefunken/Saba/Nordmende)

Gruß Willi

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Toralf Wilhelm schrieb:
> Genau so ist es!
>
> RC5: fast alle Philips, Grundig, Metz, Loewe, Technisat, (ich glaube
> auch alles was Thomson war - Telefunken/Saba/Nordmende)

Da wäre ich mir nicht so sicher. Laut

http://www.mikrocontroller.net/attachment/67261/Pollin-IR-Codes.txt

gibt es bei der Fernbedienung "Technisat DSR-B" (Pollin-Bestellnummer 
620062) zwei Ausführungen. Da bei mir kein 9V-Block einzusetzen ist, 
nehme ich an, dass es die erste im Text aufgeführte FB ist. Und diese 
enthält einen SAA3004 (SA2004 gibt es nicht, das scheint ein Vertipper 
zu sein) als IR-Encoder. Durch das Datenblatt steige ich noch nicht ganz 
durch, habe auch erstmal nur flüchtig draufgeguckt.

Kandidat könnte RECS80 sein, welches ja die zweite FB mit der 
Bestellnummer 620062 benutzt. Spricht auch deswegen dafür, weil eine 
LED, die beim damaligen Test vom µC synchron geschaltet wurde, um das 
Signal sichtbar zu machen, nur ganz ganz schwach leuchtete, wenn ich 
eine Taste drückte. Bei RECS80 sind die Impulse ultrakurz, nämlich nur 
158µs. Die Pausen hingegen sind 32 mal länger! Ein echter Batteriesparer 
also ;-)

Bei einer Timerfrequenz von 10000 kHz macht das gerade mal 1 oder 2 
Impulse. Da ich erst gestern den Bug gefixed habe, dass der Pulscounter 
immer 1 zu niedrig war, könnte das schon der Grund sein, warum die FB 
damals beim flüchtigen Test nach dem Auspacken nicht erkannt wurde. Da 
wurde nämlich schnell mal aus einem Puls gar keiner mehr ;-)

Da hilft alles nix: Ich muss das mit der "echten" Hardware und mit dem 
aktuellen IRMP-Code nochmal testen, im Notfall einen Scan machen...
Wenn sie dann aber funktionieren, sind das unschlagbar billige Teile ;-)

Gruß,

Frank

von siegmar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Leute,
tolles Projekt !!
Ich habe aber leider ein gänzlich anderes Problem.
Weiß Jemand ob es eine Art Datenbank gibt, wo man herausfinden kann, 
welches IR Protokoll ein Gerät benutzt ?
Hintergrund meiner Frage ist, das ich einen Digital Sat receiver 
(Philips DIS 2221) ohne Fernbedienung rumliegen habe und keine bisher 
von mir getestete Universalfernbedienung funktioniert.
Der IR Epfänger funktioniert.
Habe mir die Signale mit dem Scope angeschaut.
Würde den Sat Receiver ungern wegwerfen, denn wenn ich bedenke wieviel 
Dreck bei der Produktionen einen Neuen ensteht ...
Vielleicht hat ja Jemand einen guten Tip.

Wünsche allen noch schönen Tag
Gruß
Siegmar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
siegmar schrieb:

> Hintergrund meiner Frage ist, das ich einen Digital Sat receiver
> (Philips DIS 2221) ohne Fernbedienung rumliegen habe und keine bisher
> von mir getestete Universalfernbedienung funktioniert.

Mein erster Gedanke wäre die Lirc-DB.

Sicher, dass der Receiver tatsächlich was empfängt?

Google sagt, dass der Receiver öfters Wärmeprobleme hat und deswegen 
sehr oft der IR-Empfang nach einiger Zeit ausfällt. Andere konnten den 
Empfang verbessern, indem sie die Blende vor dem IR-Sensor ausgebaut 
haben. Aber einen Hinweis, wie man eine Universal-FB damit zum Laufen 
bekommt, habe ich nicht gefunden.

Gruß,

Frank

von siegmar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Sicher, dass der Receiver tatsächlich was empfängt?

Hallo Frank,
ja, ich hab das Oszi dran gehabt und saubere Impulse gesehn.
Eine Universalfernbedienung hat alle mölichen Protokolle durchgepulst 
und ich hab mir dann auf dem Oszi die Signale angeschaut.
Die Originalfernbedienung hab ich leider nicht mehr !!

Danke für deinen Tipp
Noch einen schönen Abend
Gruß
Siegmar

von M. K. (kichi)


Bewertung
0 lesenswert
nicht lesenswert
Von der Philips-Universal-FB-Seite (http://www.pronto.philips.com) 
gibt's einen Link auf http://onlyoneremote.com. Dort kann eine Datenbank 
für sehr viele Hersteller heruntergeladen werden, darunter auch viele 
Philips-Codesets. Öffnen kann man die Datei mit den Konfigurationstools 
von Philips, die man kostenlos herunterladen kann, nachdem man sich 
registriert hat.

Leider kann man in den Philips-Tools nur die Bitfolgen ansehen, die man 
selbst aufgezeichnet hat. Vielleicht kannst du ja aber mit etwas reverse 
engineering was brauchbares aus der Datenbank holen. Vielleicht kennst 
du ja auch jemanden mit einer Philips-UFB der dir helfen könnte.

von Klaus L. (kllei)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

cooles Projekt, ich habe es gestern mal provisorisch aufgebaut und 
gleich ein paar Anmerkungen und Fragen dazu:
RC5: wird weitgehend erkannt, allerdings habe ich festgestellt, das z.B. 
die Taste 2 einer Löwe FB öfter mal 4 oder 5 zurückgibt, manchmal stimmt 
auch die Adresse nicht. Die 6 "spinnt" ebenfalls öfter, andere Tasten 
gehen sehr stabil.
Eine andere RC5 FB (Inverto) zeigt ein fast identisches Verhalten (auch 
Taste 2 und 6 besonders auffällig)

Außerdem habe ich noch eine neuere Philips FB (TV) die nicht erkannt 
wird, er versucht RC5, findet aber nichts. ich habe einen Portscan mal 
angehängt, vielleicht kommt Dir die bekannt vor? Achtung, der Portscan 
ist invertiert, dann wird das Bitvergleichen einfacher.

An Protokollen fehlt mir noch DENON, zumindest die älteren DENON Codes 
werden nicht erkannt. Link zum Protokoll kann ich mal raussuchen, wenn 
Du hier unterstützen kannst/möchtest.

SIRCS und NEC werden anscheinend sicher erkannt, andere FB konnte ich 
noch nicht testen.

Mangels GCC "Übung" habe ich das Projekt nach Codevision "portiert" und 
auch gleich den DEBUG Mode in die AVR Variante eingebaut. Ich denke mal 
dabei ist nichts schiefgegangen. Allerdings scheint der output manchmal 
das Ergebnis zu beinflussen. Die Abweichungen habe ich allerdings auch 
ohne DEBUG bzw. IRMP_LOGGING

Kann das an dem von mir verwendeten Quarz liegen? Du hattest ja den 
Oszillaor benutzt. Könnte am Timing etwas verändern, oder? Ich habe um 
die Abarbeitung zu beschleunigen einen 16MHz Quarz und den Compiler auf 
maximalen speed optimiert.
Der Interrupt ist ebenfalls mit 10kHz eingestellt.

Kannst Du mir ein paar Tipps geben wo ich ansetzen kann?

Vielen Dank für den Code und Deine Unterstützung.

Grüße,
Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus,

Klaus Leidinger schrieb:
> RC5: wird weitgehend erkannt, allerdings habe ich festgestellt, das z.B.
> die Taste 2 einer Löwe FB öfter mal 4 oder 5 zurückgibt, manchmal stimmt
> auch die Adresse nicht. Die 6 "spinnt" ebenfalls öfter, andere Tasten
> gehen sehr stabil.

Da wäre eine über den UART übertragene Scan-Datei klasse, wenn Du da mal 
die Tasten 0-9 aufzeichnen könntest.

> Eine andere RC5 FB (Inverto) zeigt ein fast identisches Verhalten (auch
> Taste 2 und 6 besonders auffällig)

Dito.

> Außerdem habe ich noch eine neuere Philips FB (TV) die nicht erkannt
> wird, er versucht RC5, findet aber nichts. ich habe einen Portscan mal
> angehängt, vielleicht kommt Dir die bekannt vor? Achtung, der Portscan
> ist invertiert, dann wird das Bitvergleichen einfacher.

Werde ich mir mal näher anschauen und dann noch was dazu schreiben. Wenn 
Du schon beim Einscannen über UART bist, kannst Du das ja auch direkt 
mal für diese FB tun.

> An Protokollen fehlt mir noch DENON, zumindest die älteren DENON Codes
> werden nicht erkannt. Link zum Protokoll kann ich mal raussuchen, wenn
> Du hier unterstützen kannst/möchtest.

Doku zu älterem DENON-Protokoll ist mir mal über den Weg gelaufen, wenn 
Du da einen Link hättest, wäre nett.

> SIRCS und NEC werden anscheinend sicher erkannt, andere FB konnte ich
> noch nicht testen.

Prima.

> Mangels GCC "Übung" habe ich das Projekt nach Codevision "portiert" und
> auch gleich den DEBUG Mode in die AVR Variante eingebaut.

Das ist schlecht. Die DEBUG-Variante ist eigentlich nur zum Testen unter 
Linux gedacht, auf dem AVR verändern Dir direkte printf-Ausgaben zu sehr 
das Zeitverhalten. Daher halte ich das für überhaupt nicht sinnvoll.

> Ich denke mal
> dabei ist nichts schiefgegangen. Allerdings scheint der output manchmal
> das Ergebnis zu beinflussen.

Eben. Lass das besser mit dem DEBUG-Modus auf dem AVR. Schalte lediglich 
IRMP_LOGGING ein. Die empfangenen Bytes werden gepuffert und sollten 
daher das Zeitverhalten während der Aufzeichnung nicht beeinflussen.

> Kann das an dem von mir verwendeten Quarz liegen? Du hattest ja den
> Oszillaor benutzt. Könnte am Timing etwas verändern, oder?

Mit einem Quarz sollte es eher besser sein. Wie gesagt, der DEBUG-Modus 
ist nicht für die Ausgabe geeignet, da er in der ISR direkt ausgeführt 
ist. Unter Linux oder Windows ist das absolut zeitunkritisch, weil da 
die Daten ja dann aus der Datei gelesen werden.

Gruß,

Frank

von Albert K. (datasec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Klaus, steht die "portierte" Version für CV zum Download an?

Grüße,
Albert

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Albert K. schrieb:
> Hallo Klaus, steht die "portierte" Version für CV zum Download an?
>
Hallo Albert,

Du hast Post.

Wennn der Code "stabil" ist, stelle ich die gerne zur Verfügung.

Falls mehr Leute Interesse daran haben, könnte Frank dann die
#ifdef CV
vielleicht in den Original Code mit reinnehmen?

Mal sehen wieviel Aufwand das wird ;-)

Grüße,
Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klaus Leidinger schrieb:

> Falls mehr Leute Interesse daran haben, könnte Frank dann die
> #ifdef CV
> vielleicht in den Original Code mit reinnehmen?

Klar, mache ich. Schick mir bitte die geänderten Dateien zu.

Gruß,

Frank

von siegmar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael K. schrieb:
> Leider kann man in den Philips-Tools nur die Bitfolgen ansehen, die man
> selbst aufgezeichnet hat. Vielleicht kannst du ja aber mit etwas reverse
> engineering was brauchbares aus der Datenbank holen. Vielleicht kennst
> du ja auch jemanden mit einer Philips-UFB der dir helfen könnte.

Danke für den Tip.
Ob es micht weiter bringt ?
Wenn ich nur wüßte, welche Codierung der SAT Receiver benutzt.
Nun ja ....... mal sehn.
Trotzdem Danke und noch einen schönen Tag
Gruß
Siegmar

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Di Pi schrieb:
>> Werden jetzt auch Wiederholungen beim NEC-Protokoll erkannt? (der
>> Hinweis auf eine noch fehlende Implementierung ist weg.)
>
> Nein, der Hinweis ist mir leider beim Bearbeiten der Tabellen
> flötengegangen. Ist nun wieder drin.
>
> Aber bis jetzt habe ich noch keine FB in der Hand gehabt, wo wirklich
> die spezielle Wiederholungs-Sequenz augesandt wird. Bei meiner Toshiba-,
> Xoro- und Media-Player-Fernbedienung, die allesamt das NEC-Protokoll
> benutzen, wird davon jedenfalls kein Gebrauch gemacht. Stattdessen wird
> einfach der jeweilige Code solange wiederholt, bis man die Taste
> loslässt.

Die Reichelt-RGB-FB sendet die spezielle Wiederholungssequenz. :)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Di Pi schrieb:
> Die Reichelt-RGB-FB sendet die spezielle Wiederholungssequenz. :)

Danke für die Info. Mit der Download-Version vom 13.02. im IRMP-Artikel 
sollte das auch von IRMP erkannt werden.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine neue Version von IRMP zum Download:

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

Änderungen:

 - Erkennung von NEC-Protokoll-Varianten, z.B. Apple-Fernbedienung
 - Neuer Decoder: RC6
 - Neuer Decoder: Denon und Denon-Varianten
 - Verbesserung des RC5-Decoders (Bugfixes)

Vielen Dank an  Klaus Leidinger, der mich mit den entsprechenden 
Scan-Dateien versorgte ;-)

Desweiteren gibt es nun im Unterverzeichnis IR-Data ein irmp.exe, mit 
dem man Scan-Dateien auch unter Windows analysieren kann.

Beispiel:

1. Eingabeaufforderung starten
2. In das Verzeichnis irmp\IR-Data wechseln
3. Aufruf von:

   irmp.exe <rc5x.txt

Da manche Ausgaben sehr lang werden, empfiehlt es sich, diese in eine 
Datei zu lenken oder in den more weiterzuleiten, damit man seitenweise 
blättern kann:

   irmp.exe <rc5x.txt | more


Viel Spaß,

Frank

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
...
und für die Codevision Nutzer ist die main.c entsprechend angepasst...
einfach das //#define CODEVISION auskommentieren.

Danke an Frank, auch für die Nachtschichten ;-)

Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klaus Leidinger schrieb:
> ...
> und für die Codevision Nutzer ist die main.c entsprechend angepasst...
> einfach das //#define CODEVISION auskommentieren.

Upps, hab ich doch tatsächlich vergessen... ich schreibs noch mit in den 
Artikel.

Gruß,

Frank

von Chris M. (shortie)


Bewertung
0 lesenswert
nicht lesenswert
ich habe mal eine Liste von 6 Fernbedienungen dem Artikel hinzugefügt - 
u.a. auch eine mit KASEIKYO Protokoll - die ich mal spontan 
durchgetestet habe.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Chris M. schrieb:
> ich habe mal eine Liste von 6 Fernbedienungen dem Artikel hinzugefügt -
> u.a. auch eine mit KASEIKYO Protokoll - die ich mal spontan
> durchgetestet habe.

Hey, und es hat funktioniert? Das Kaseikyo-Protokoll hatte ich lediglich 
nach Infos aus dem Internet implementiert, ohne es jemals testen zu 
können.

Gute Idee, eine Liste von Fernbedienungen in den Artikel einzufügen, 
vielleicht ist die Angabe der Adresse aber besser in Hex sinnvoll?

Wer noch weitere FBs mit IRMP getestet hat, kann diese ja auch noch im 
Artikel eintragen, zum Beispiel die Reichelt-RGB-FB.

Gruß,

Frank

von Chris M. (shortie)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:

> Hey, und es hat funktioniert? Das Kaseikyo-Protokoll hatte ich lediglich
> nach Infos aus dem Internet implementiert, ohne es jemals testen zu
> können.

Ja problemlos - mit der Version die Du um den 10.02. veröffentlicht 
hattest ging noch nichts und ich dachte schon die wird noch ein ganz 
anderes Protokol nutzen. Auch die RC5 Codes stimmen nun mit der anderen 
Software von Peter Dannegger die ich nutze überein.

von Michael U. (murban)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

habe den Code heute zum ersten Mal ausprobiert. Läuft auf einem Atmega16 
einwandfrei mit NEC Protokoll.

Eine kleine Erweiterung habe ich eingebaut: Die Datenstruktur irmp_data 
habe ich um ein Flag erweitert, das anzeigt, ob das Kommando aus einem 
Repetition-Frame stammt. Damit kann ich dann im Programm entscheiden, ob 
ich einen Auto-Repeat haben möchte oder nicht.

Mag vielleicht auch noch für andere hilfreich sein...

Viele Grüsse
Michael

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael Urban schrieb:

> Eine kleine Erweiterung habe ich eingebaut: Die Datenstruktur irmp_data
> habe ich um ein Flag erweitert, das anzeigt, ob das Kommando aus einem
> Repetition-Frame stammt. Damit kann ich dann im Programm entscheiden, ob
> ich einen Auto-Repeat haben möchte oder nicht.

Ist das generell sinnvoll und damit von allgemeinem Interesse?

Ich meine, nicht nur für NEC, auch bei RC5 und RC6 könnte man das gewiss 
einbauen...

@Michael: Für was brauchst Du das?

Gruß,

Frank

von Di Pi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich bin sehr daran interessiert, unterscheiden zu können, ob es eine 
Wiederholung oder ein neuer tastendruck (auch derselben taste) ist.

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
was versteht ihr unter Wiederholung?
a) den mehrfachen Empfang eines Frames, weil das Protokoll so 
implementiert ist, dass es jeden Frame 3x verschickt
b) eine Wiederholung durch dauerhaft gedrückte Taste

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Vlad Tepesch schrieb:
> was versteht ihr unter Wiederholung?
> a) den mehrfachen Empfang eines Frames, weil das Protokoll so
> implementiert ist, dass es jeden Frame 3x verschickt
> b) eine Wiederholung durch dauerhaft gedrückte Taste

b)

Das Protokoll "darunter" soll ja gerade für die Applikation 
unsichtbar/uninteressant sein.

Gruß,

Frank

von Michael U. (murban)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich meinte die Erkennung, ob ein Kommando erstmalig gesendet wird oder 
aufgrund eines Wiederholungsframes erzeugt wurde.

Ich brauchte das, weil ich die Fernbedienung zur Eingabe von Daten 
verwende - und wenn man da nicht kurz genug drückt, dann "prellt" die 
Sache eben...

Ich habe das ganz einfach gelöst:

Die Datenstruktur IRMP_DATA habe ich durch ein viertes Feld ergänzt:
typedef struct
{
  uint8_t               protocol;                                                               // protocol, i.e. NEC_PROTOCOL
  uint16_t              address;                                                                // address
  uint16_t              command;                                                                // command
  uint8_t               repetition;                                                               // repetition frame
} IRMP_DATA;

an der entsprechenden Stelle für die Erkennung von repetition frames:
          if (irmp_tmp_protocol == IRMP_NEC_PROTOCOL && irmp_bit == 0)                            // repetition frame
          {
            irmp_protocol = irmp_tmp_protocol;
            irmp_address = last_irmp_address;                                                     // address is last address
            irmp_command = last_irmp_command;                                                     // command is last command
            irmp_repetition = 1;   // Marker repetition flag
          }

(Variablendeklarationen, etc. habe ich hier jetzt mal weggelassen)

Das funktioniert bei allen Protokollen, die einen repetition frame 
besitzen

In der Auswerteroutine im Programm kann mann jetzt irmp_data.repetition 
auswerten und selbst entscheiden, ob man die Wiederholung haben will 
oder nicht.

Ich habe z.B. für die Zahlentasten, die ich zur Eingabe verwende, die 
Wiederholungen ignoriert, für Cursortasten sie aber eingeschaltet 
gelassen.

Ob das jetzt Allgemein interessant ist, mag ich nicht beurteilen - für 
mich ist es ein nutzbares Feature.

Viele Grüsse
Michael

von Michael U. (murban)


Bewertung
0 lesenswert
nicht lesenswert
Ach ja, vergessen:

Variante b) - das "Auto-Repeat" bei länger gedrückter Taste (schlägt bei 
mir schon bei einer gefühlten 1/10 Sek. zu...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
> Ob das jetzt Allgemein interessant ist, mag ich nicht beurteilen - für
> mich ist es ein nutzbares Feature.

Okay, ich bau das so ähnlich ein, aber etwas allgemeingültiger:
#define IRMP_FLAG_REPETITION    0x01
#define IRMP_FLAG_WASWEISSICH   0x02
....

typedef struct
{
  uint8_t          protocol;           // protocol, i.e. NEC_PROTOCOL
  uint16_t         address;            // address
  uint16_t         command;            // command
  uint8_t          flags;              // flags, e.g. repetition frame
} IRMP_DATA;

Denn wer weiß, vielleicht kommen da noch ein paar Flags hinzu?

Dann wird bei länger gedrückter Taste das Bit IRMP_FLAG_REPETITION in 
flags gesetzt - nicht nur bei NEC, sondern auch bei RC5 und RC6. Bei den 
anderen Protokollen ist das schwerlich möglich, ausser ich arbeite mit 
Timeouts ("wenn derselbe Befehl innerhalb X Millisekunden reinkommt, 
dann hat der User schon länger den Finger auf der Taste")... mal sehen.

In main() kann man das dann so abfragen:
   if (irmp_data.flags & IRMP_FLAG_REPETITION)
   {
      finger_blau();
   }
   else
   {
      normale_taste();
   }

Gruß,

Frank

von Di Pi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Timeouts würde ich dafür nicht verwenden (oder abschaltbar machen). Was 
ich an diesem Projekt nämlich am meisten schätze ist die Möglichkeit, 
alles nicht benötigte per Flag abzuschalten.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Di Pi schrieb:
> Timeouts würde ich dafür nicht verwenden (oder abschaltbar machen). Was
> ich an diesem Projekt nämlich am meisten schätze ist die Möglichkeit,
> alles nicht benötigte per Flag abzuschalten.

Ich dachte einfach an einen Zähler, der bei jedem Call der ISR 
hochgezählt wird. Wenn

a) ein neuer Frame erkannt wird und
b) der Zähler einen gewissen Wert (REP_TIMEOUT) nicht übersteigt und
c) erkanntes ProtoKoll = letztes Protokoll und
d) Adresse = letzte Adresse und
e) Kommando = letztes Kommando

dann setze das Repetition-Flag.

Der Zähler wird bei jedem erkannten Protokoll einfach wieder auf 0 
gesetzt.

REP_TIMEOUT müsste auf ca. 0,2 Sekunden stehen. Jede FB schafft bei 
Festhalten einer Taste ca. 10 Frames pro Sekunde. Aber keiner klickt so 
schnell einzeln auf der FB rum.

Meinetwegen kann ich das auch abschaltbar machen, aber ich schätze den 
zusätzlichen Aufwand an µC-Code auf max. 50 Bytes.

Gruß,

Frank

von Di Pi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wenn es wirklich nur 50 Bytes sind, ists meiner Meinung nach nicht 
nötig, es per Flag abschaltbar zu machen.

Ich habe mir noch nicht so detaillierte Gedanken über die konkrete 
Umsetzung gemacht. Dein Ansatz aber klingt für mich sehr plausibel und 
wirklich klein.

Er könnte sogar diverse Togglebits komplett ablösen (und dadurch den 
code verkleinern), wenn man davon ausgeht, dass

"
>Jede FB schafft bei
>Festhalten einer Taste ca. 10 Frames pro Sekunde. Aber keiner klickt so
>schnell einzeln auf der FB rum.
"

immer gilt.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine neue Version von IRMP zum Download:

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

Einzige Änderung: Neue Variable flags in IRMP_DATA zur Erkennung von 
langen Tastendrücken

Um zu unterscheiden, ob eine Taste lange gedrückt wurde oder lediglich 
einzeln, dient das Bit IRMP_FLAG_REPETITION. Dieses wird im 
Struct-Member flags gesetzt, wenn eine Taste auf der Fernbedienung 
längere Zeit gedrückt wurde und dadurch immer wieder dasselbe Kommando 
innerhalb kurzer Zeitabstände ausgesandt wird.

Beispiel:
    if (irmp_data.flags & IRMP_FLAG_REPETITION)
    {
      finger_blau (irmp_data.command);
    }
    else
    {
      einzeln (irmp_data.command);
    }

Dies kann zum Beispiel dafür genutzt werden, um die Tasten 0-9 zu 
"entprellen", indem man Kommandos mit gesetztem Bit IRMP_FLAG_REPETITION 
ignoriert. Bei dem Drücken auf die Tasten VOLUME+ oder VOLUME- kann die 
wiederholte Auswertung ein und desselben Kommandos aber durchaus 
gewünscht sein - zum Beispiel, um LEDs zu faden.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Es gibt eine neue Version vom IRMP zum Download:

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

Änderungen:

1. SIRCS: Korrekte Erkennung und Unterdrückung von automatischen 
Frame-Wiederholungen

Eine Sony-Fernbedienung wiederholt automatisch jeden Frame 2-3 mal. Das 
wurde nicht immer korrekt als solche erkannt. Solche Wiederholungen 
werden nun weggefiltert.

2. SIRCS: Device-ID-Bits werden nun in irmp_data.command und nicht mehr 
in irmp_data.address gespeichert

Je nach Sony-FB-Tasten (z.B. für TV-Kanal oder für Videotext) werden 
unterschiedliche ID-Kennungen mitgeschickt. IRMP hat diese bisher in der 
Adresse abgebildet. Das ist aber nicht praxisgerecht, weil dann ein- und 
dieselbe Fernbedienung unterschiedliche Adressen aufweist. Die 
ID-Kennung wird nun zusammen mit dem Kommando in der Variablen 
irmp_data.command abgelegt. Somit hat nun jede Sony-FB ein- und dieselbe 
Adresse, nämlich 0.

Ausnahme: Ist der Frame 20 Bits statt 12 oder 15 Bits lang (nur bei 
neueren FBs), werden die letzten 5 Bits in der Adresse abgelegt.

3. Vergrößerung des Scan-Buffers (zwecks Protokollierung)

Der Scan-Buffer wurde vergrößert, um solche automatischen 
Wiederholungen, wie sie z.B. von Sony-FBs ausgesandt werden, überhaupt 
zu erkennen und als solche für Scans zu protokollieren. Da der 
Scan-Buffer im Normalfall abgeschaltet ist, hat das keine Auswirkung auf 
die Größe des Programms.

Gruß,

Frank

von Peter K. (peko)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

zunächst mal vielen Dank für das große Engagement bei diesem 
Softwareprojekt. Das trifft genau mein Thema, ich habe gerade ein 
Projekt geatartet um verschiedene Kommandos der "vielen" Fernbedienungen 
meiner Anlage aufzufangen um dann Zusatzfunktionen auszulösen.
Vielleicht hier mal kurz meine Erfahrungen mit deiner Software nach den 
ersten 2..3 h herumspielen:
Mit 8Mhz internem Oszillator hatte ich massive Probleme mit dem Timing, 
(gleiche Tastendrücke führen zu unterschiedlichen Codes). Nun, mit 16MHz 
externem Quarz läuft es wesentlich besser.

Zu den Protokollen, die ich mit original FB testen kann:

SIRCS läuft gut, allerdings ist eine Sony Videorecorder-FB offenbar mit 
ihrem Timing etwas grenzwertig, es kommt immer mal vor, daß verschiedene 
Codes bei gleichem Tastendruck gezeigt werden.
NEC von einer Yamaha-FB läuft richtig super.
KASEIKYO von einer Panasonic Blueray FB läuft auch super.
SAMSUNG von einer TV-FB geht überhaupt nicht, null Output.
Dann kann ich noch eine Kathrein-Sat-Rx FB bieten - dort meldet IRMP zu 
90% RC5(x) und ab und zu RC6. (Timing-Problem?) Am funktionieren dieses 
Protokolls wäre ich am stärksten interessiert...

Noch eine Anmerkung zu der neuesten Änderung vom 2.3.: Meiner Meinung 
nach hat der Wegfall der Systemadresse bei SIRCS keinen Sinn bzw. es 
kommt auf den Anwendungsfall (?) an. Wenn ich an der TV-FB Power drücke 
will ich das doch von z.B. Power beim DVD-Player unterscheiden. Das geht 
nun nicht mehr, alles sieht gleich aus.

Und eine letzte Sache ist mir noch aufgefallen: Die Kommandos die IRMP 
ausgibt sind in der Bitorder verdreht. Ok, das mag egal sein, denn 
eindeutig ist es auch so, aber typischerweise haben Zifferntasten 1..9 
aufsteigende Codes, in welchem Bereich auch immer. Daran kann man das 
Problem ganz gut erkennen. Dreht man die Bits um, sieht es sowohl bei 
SIRCS, NEC und KASEIKYO "schön" aus. Ggf. sind auch die Systemadressen 
bitverdreht, konnte ich noch nicht checken.

Ok, langer Beitrag, sorry ;) Wenn ich mit meinem FB-Fundus irgendwie zum 
Fortgang dieses Projektes beitragen kann, würde ich es im Rahmen meines 
Zeitbudgets gerne tun.

-Peter

von Di P. (drpepper) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter Kostov schrieb:
> typischerweise haben Zifferntasten 1..9
> aufsteigende Codes

Da habe ich mit einer NoName-RC5 FB andere Erfahrungen gemacht. Da 
scheinem mir die Kommandos rein zufällig vergeben worden zu sein (sowohl 
1..9 als auch alle anderen Tasten). Sicher, dass dein Hersteller nicht 
vllt einfach absteigend nummeriert?

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

Peter Kostov schrieb:

> Mit 8Mhz internem Oszillator hatte ich massive Probleme mit dem Timing,
> (gleiche Tastendrücke führen zu unterschiedlichen Codes). Nun, mit 16MHz
> externem Quarz läuft es wesentlich besser.

Interessant, die anderen, die mich mit IR-Scans und anderen Infos 
versorgen, benutzen den internen Oszillator und haben keine 
Timing-Probleme.

> SIRCS läuft gut, allerdings ist eine Sony Videorecorder-FB offenbar mit
> ihrem Timing etwas grenzwertig, es kommt immer mal vor, daß verschiedene
> Codes bei gleichem Tastendruck gezeigt werden.

Da bräuchte ich einen Scan von mehreren Tasten. Dazu bitte IRMP_LOGGING 
einschalten, über den UART mitprotokollieren und mir die Scans schicken 
- am besten mit einem Kommentar "# Taste 1" vor jeder Zeile. 
Beispiel-Dateien sind im Ordner IR-Data.

> KASEIKYO von einer Panasonic Blueray FB läuft auch super.

Hier würden mich auch Scans interessieren, weil ich nämlich gerade das 
Programm für eine IR-Sende-Funktion schreibe, welcher man die 
IRMP-Datenstruktur übergibt. Diese Funktion rekonstruiert aus den 
IRMP-Daten wieder den Original-Frame und gibt diesen dann über eine 
IR-Diode aus. Beim Kaseikyo-Protokoll sind das aber 48 Bits, von welchen 
ich beim Decodieren einige ignoriere, um sie überhaupt in die 
IRMP-Datenstruktur pressen zu können. D.h. beim Decodieren gehen 
Informationen verloren. Diese sind zwar fürs Decodieren der Tasten nicht 
wichtig, aber für das Encodieren des kompletten Frames. Wäre also nett, 
wenn Du mir da entsprechende Scans schicken könntest, da ich selber noch 
nie eine Kaseikyo-kompatible FB gesehen habe ;-)

> SAMSUNG von einer TV-FB geht überhaupt nicht, null Output.

Bitte Scans her. Ich passe das dann an.

> Dann kann ich noch eine Kathrein-Sat-Rx FB bieten - dort meldet IRMP zu
> 90% RC5(x) und ab und zu RC6. (Timing-Problem?) Am funktionieren dieses
> Protokolls wäre ich am stärksten interessiert...

RC6 sieht verschiedene Modes vor und kann ziemlich kompliziert werden. 
Ich habe bisher nur Mode 0 implementiert, der auch hier

http://www.sbprojects.com/knowledge/ir/rc6.htm

dokumentiert ist. Da RC6 teilweise(!) dieselben Timings wie RC5 benutzt, 
kann das dann schnell "verwechselt" werden - jedenfalls dann, wenn der 
Frame nicht den Mode 0, sondern irgendeinen anderen verwendet.

Auch hier helfen mir nur Scans.

> Noch eine Anmerkung zu der neuesten Änderung vom 2.3.: Meiner Meinung
> nach hat der Wegfall der Systemadresse bei SIRCS keinen Sinn bzw. es
> kommt auf den Anwendungsfall (?) an. Wenn ich an der TV-FB Power drücke
> will ich das doch von z.B. Power beim DVD-Player unterscheiden. Das geht
> nun nicht mehr, alles sieht gleich aus.

Die Infos gehen ja nicht verloren, die Device-IDs landen halt nun im 
Byte "command" statt "address". Daher sollte die TV-Power- und die 
DVD-Power-Taste durchaus ein unterschiedliches Kommando liefern. Vor 
dieser Änderung waren halt die Adressen verschieden aber die Kommandos 
gleich.

Bist Du sicher, dass da alles gleich aussieht? Dann muss es auch vor 
dieser Änderung gleich ausgesehen haben.

> Und eine letzte Sache ist mir noch aufgefallen: Die Kommandos die IRMP
> ausgibt sind in der Bitorder verdreht. Ok, das mag egal sein, denn
> eindeutig ist es auch so, aber typischerweise haben Zifferntasten 1..9
> aufsteigende Codes, in welchem Bereich auch immer. Daran kann man das
> Problem ganz gut erkennen. Dreht man die Bits um, sieht es sowohl bei
> SIRCS, NEC und KASEIKYO "schön" aus. Ggf. sind auch die Systemadressen
> bitverdreht, konnte ich noch nicht checken.

Einige Protokolle senden mit MSB-First, andere mit LSB-First. Die 
Arbeit, die Bits in der jeweils "richtigen" Reihenfolge zu speichern, 
wollte ich mir nicht machen. Hauptsache, die empfangenen Codes sind 
verschieden. Ist die Bitreihenfolge für Dich wichtig?

> Ok, langer Beitrag, sorry ;) Wenn ich mit meinem FB-Fundus irgendwie zum
> Fortgang dieses Projektes beitragen kann, würde ich es im Rahmen meines
> Zeitbudgets gerne tun.

Danke im voraus für die Scans ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Di Pi schrieb:
> Da habe ich mit einer NoName-RC5 FB andere Erfahrungen gemacht. Da
> scheinem mir die Kommandos rein zufällig vergeben worden zu sein (sowohl
> 1..9 als auch alle anderen Tasten).

Interessant, bei RC5 sind die Codes für die Tasten eigentlich fest 
definiert, d.h. jede RC5-FB sollte das gleiche Command senden, wenn man 
die Taste "1" drückt. Die Adressen können natürlich voneinander 
abweichen.

> Sicher, dass dein Hersteller nicht vllt einfach absteigend nummeriert?

Das Problem ist die Bitreihenfolge. Einige Protokolle arbeiten mit 
MSB...LSB, andere mit LSB...MSB. Diese verschiedenen Bitreihenfolgen 
beachte ich nicht. Halte ich auch (bisher) nicht für wichtig. 
Hauptsache, jede Taste wird mit einem unterschiedlichen Code empfangen.

RC5 sendet übrigens mit MSB first, d.h. die Bitreihenfolge ist hier im 
IRMP "richtig" herum. Die Commands müssen dann für die Tasten 1-9 immer 
folgendermaßen aussehen:

Taste 1: command 0x0001
Taste 2: command 0x0002
...
Taste 9: command 0x0009

Ich werde die Bitreihenfolge im IRMP-Artikel mal dokumentieren. Dann 
kann sich jeder selbst überlegen, ob er die Bits nach dem Empfang 
nochmal "drehen" will oder nicht. Ich würde es nicht tun, halte ich für 
unnötigen Verschleiss des µCs ;-)

Gruß,

Frank

von Peter K. (peko)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

anbei Scans von verschiedensten Codes. Insbesondere die letzten Tests 
mit der Kathrein FB sehen sehr merkwürdig aus, da IRMP meistens SIRCS 
meldet, es ist definitiv kein SIRCS. Ich vermute sehr stark RC5 / RC6, 
irgendetwas mit einem Toggle-Bit, damit kommt meine programmierbare FB 
nicht klar.

Interessant auch die Samsung Scans, die vom IRMP auf "höherem Layer" gar 
nicht angezeigt werden.

Getestet wurde das Ganze mit einem ATMEGA32@16MHz.

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

Peter K. schrieb:
> anbei Scans von verschiedensten Codes.

Vielen Dank für die Arbeit, die Du Dir gemacht hast. Ich schaue sie mir 
im Laufe des Tages an und melde mich dann.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun die einzelnen Scans von Peter durchgearbeitet:

Sony-RM-S-310:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RMT-V406:

  Protokoll: SIRCS
  Erkennung: 100%

Sony-RM-U305C:

  Protokoll: SIRCS
  Erkennung : 100% (nach Anpassung der SIRCS-Toleranzen)

Sony-RMT-D142P-DVD:

  Protokoll: SIRCS
  Erkennung : 100%

Panasonic-Blue-Ray:

  Protokoll: KASEIKYO
  Erkennung: 100% (nach Anpassung der Kaseikyo-Toleranzen)

  Prinzipiell kommt jeder Code 2x, beim 2. Mal ist Repetition-Flag
  gesetzt.
  @Peter: Du hast die Tasten aber nur kurz gedrückt? Wenn ja, muss ich
  Kaseikyo-Wiederholungen wegfiltern

Yamaha-RAV388:

  Protokoll: NEC
  Erkennung: 100%

  Auch hier kommt jeder Code 2x, Repetition-Flag ist ebenso gesetzt.
  Beim NEC-Protokoll habe ich das bisher aber noch nicht erlebt, dass
  Frames wiederholt werden.
  @Peter: Nochmal die Frage: auch da jede Taste nur 1x kurz gedrückt?

Samsung_TV:

  Diese FB benutzt zwar die gleichen Timings wie das bisherige SAMSUNG-
  Protokoll, aber es fehlt das längere Sync-Bit an 16. Stelle. Ausserdem
  ist die Länge nur 32 statt 37 Bits.

  Protokoll: SAMSUNG2 (NEU!)
  Erkennung: 100% (nach Anpassung des Source auf IRMP_SAMSUNG2_PROTOKOL)

  Siehe auch IRMP-Artikel, wurde angepasst bzgl. SAMSUNG2

Kathrein-UFS-912-Remote:

  Das ist echt ein harter Brocken. Das Protokoll ist RC6, aber der Frame
  besteht nicht aus 20 Bits, sondern aus 36 Bits. Der RC6-Mode ist ein
  anderer als der bisher bekannte, ausserdem liegt das Timing der
  Start-Bits sehr nahe am SIRCS-Protokoll. Da muss ich noch ein wenig
  Arbeit reinstecken...

Den Download im IRMP-Artikel werde ich heute abend aktualisieren, dann 
klappt es auch mit allen oben genannten Fernbedienungen einwandfrei. 
Ausnahme: Kathrein-FB, da kann es evtl. länger dauern.

Gruß,

Frank

von Peter K. (peko)


Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,

na das Verarbeiten der Infos geht ja schnell... Ich werde heute abend 
nochmal einige Scans jeweils mit "Taste kurz gedrückt" vs. "Taste lang 
gedrückt" schicken. Wenns interessiert, kann ich auch noch verschiedene 
andere FB mal einscannen. Z.B. noch 'ne Kathrein, Thomson und Skymaster.

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

Peter K. schrieb:

> na das Verarbeiten der Infos geht ja schnell...

Die meiste Arbeit war das Separieren in verschiedene Dateien und die 
Anpassung der Kommentare mit dem Editor ;-)

> Ich werde heute abend
> nochmal einige Scans jeweils mit "Taste kurz gedrückt" vs. "Taste lang
> gedrückt" schicken.

Prima, wäre klasse, wenn Du folgende Form wählen würdest:

1. Für jede FB eine eigene Datei
2. Vor jedem Scan eine Kommentar-Zeile, die mit '#' beginnt.

Beispiel für Sony-RM-S-310.txt:

# Taste: Power
00000000000000000000000000111100000000000000111100000000...
# Taste: 1
00000000000000000000000000111100000000000000111100000000...
usw.

> Wenns interessiert, kann ich auch noch verschiedene
> andere FB mal einscannen. Z.B. noch 'ne Kathrein, Thomson und Skymaster.

Kannst Du gerne machen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Neue Version von IRMP zum Download verfügbar:

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

Erweiterungen/Änderungen:

- Neues Protokoll: SAMSUNG32 (Mix aus SAMSUNG & NEC-Protokoll)
- Änderung/Anpassung der SIRCS- und Kaseikyo-Timing-Toleranzen

Dank an Peter K. für die Scans.

Gruß,

Frank

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Peter K. schrieb:
> KASEIKYO von einer Panasonic Blueray FB läuft auch super.

Hallo Peter,

Du hast anscheinend eine KASEIKYO FB, die müsste ja mit 56KHz senden. 
Hast Du einen TSOP1756 als Empfänger? Oder was sonst?

Ich hatte hier gerade ein Problem mit einem SFH 5110-36, der hat nicht 
mal mehr die 40KHz der Sony FB erkannt, ein TSOP1736 geht bei Sony noch, 
aber nicht bei 56KHz.

Hat eventuell jemand einen Tipp für einen breitbandigeren Empfänger?

Vielen Dank und viele Grüße an die IR Fans ;-)
Klaus

von Peter K. (peko)


Bewertung
0 lesenswert
nicht lesenswert
Hi Klaus,

ich habe hier so eine kleine Blechbüchse 1,5x1,5x1 cm als IR-Rx, vor 
Jahren mal bei "C" gekauft. Die funktioniert mit allen FB (Sony, 
Samsung, Yamaha, Panasonic) in ca. 50cm Entfernung. Das "DX"-Verhalten 
aus mehreren Metern Entfernung hab ich noch nicht getestet.

-Peter

von Peter K. (peko)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Frank,
anbei noch mal ein kurzer Scan von der Panasonic FB. Es gibt dort einen 
Unterschied bei Taste 3: Einmal ganz kurz gedrückt, einmal einen Moment 
länger. Ich wollte auch Dauerdrück aufzeichnen, allerdings stürzt dabei 
das Prog. anscheinend ab. Genauso hängt sich wohl was auf, wenn ich auf 
der Samsung32 dauernd drücke. Ich vermute, da läuft der scan-buffer 
über? Ich muss gestehen daß ich bisher mir noch nicht näher angucken 
konnte wie du das ganze implementiert hast.
Aber: Samsung wird jetzt gut erkannt, prima!

Ciao - Peter

Mehr Zeit müsste man haben :)

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Peter K. schrieb:
> ich habe hier so eine kleine Blechbüchse 1,5x1,5x1 cm als IR-Rx, vor

OK, so ein Teil habe ich auch noch aus einem alten Fernseher, aber so 
was gibts wohl nicht mal mehr bei P*llin...

Danke für die Info,
Klaus

von Michael H. (mah)


Bewertung
0 lesenswert
nicht lesenswert
ich möchte mit einer Anwendung einige wenige Tasten einer (vorab 
unbekannten) Fernbedienung aufzeichnen und diese später wiedergeben 
können (in genau diesem Protokoll).

Hat jemand einen Tip für eine dazupassende generische *Sende*routine?

-Michael

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael Haberler schrieb:
> ich möchte mit einer Anwendung einige wenige Tasten einer (vorab
> unbekannten) Fernbedienung aufzeichnen und diese später wiedergeben
> können (in genau diesem Protokoll).
>
> Hat jemand einen Tip für eine dazupassende generische *Sende*routine?

IRSND - diese hat gerade Klaus im Test ;-)

IRSND ist das Gegenstück zu IRMP. IRSND generiert aus der 
IRMP-Datenstruktur den Frame und schickt ihn auf eine IR-LED. Ich werde 
spätestens am Wochenende den IRSND zum Download ablegen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

Peter K. schrieb:
> anbei noch mal ein kurzer Scan von der Panasonic FB. Es gibt dort einen
> Unterschied bei Taste 3: Einmal ganz kurz gedrückt, einmal einen Moment
> länger.

Vielen Dank, sehr aufschlussreich. Der Frame wird nur 1x geschickt, wenn 
Du kurz drückst. Bei der Taste 3 (länger gedrückt) gab es zwei Frames, 
wobei IRMP dann korrekterweise das Repetition-Flag in irmp_data.flags 
gesetzt hat. Ist also alles okay.

> Ich wollte auch Dauerdrück aufzeichnen, allerdings stürzt dabei
> das Prog. anscheinend ab. Genauso hängt sich wohl was auf, wenn ich auf
> der Samsung32 dauernd drücke. Ich vermute, da läuft der scan-buffer
> über?

Könnte sein, da muss ich mir die Log-Funktion nochmal näher ansehen. 
Diese hatte Vlad Tepesch für das WordClock-Projekt erstellt und ich habe 
sie kurzerhand "assimiliert" ;-)

> Aber: Samsung wird jetzt gut erkannt, prima!

Freut mich. Ohne Logging stürzt das Programm auch nicht ab, oder?

> Mehr Zeit müsste man haben :)

Wie wahr...

Gruß,

Frank

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Ich zitiere mich mal selbst ;-)
>OK, so ein Teil habe ich auch noch aus einem alten Fernseher, aber so
>was gibts wohl nicht mal mehr bei P*llin...

Als universeller Empfänger wäre wohl der U2538B prinzipiell geeignet:
Beitrag "Schaltung mit IR-Empfänger (LED) gesucht"

Mal sehen, wann der verfügbar wird, im Moment hat ihn digikey auch 
nicht.

Klaus

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Hi!

Zuerst: super Arbeit hier!

Ich bin ain AVR Anfänger und habe dazu nun etwas Unsicherheit um den 
Code für den Atmeg8 zu verwenden!

1. F_CPU, benutze einen Quarz 12MHz:
main.c: #define F_CPU       12000000

2. Timer Register geändert:
TIMSK  = 1 << OCIE1A;                                                    // OCIE1A: Interrupt by timer compare (use TIMSK for ATMEGA162)

3. PD3 als Input:
/*---------------------------------------------------------------------------------------------------------------------------------------------------
 * Change hardware pin here:
 *---------------------------------------------------------------------------------------------------------------------------------------------------
 */
#define IRMP_PORT                               PORTD
#define IRMP_DDR                                DDRD
#define IRMP_PIN                                PIND
#define IRMP_BIT                                3                             // use PD3 as IR input

Habe aber etwas weiter oben im irmp.c das gefunden: static int PINB;
Muss ich denn auch auf PIND ändern?

Danke für Hilfe!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:

> 1. F_CPU, benutze einen Quarz 12MHz:
>
main.c: #define F_CPU       12000000

Wenn Du genau hinschaust, gilt das nur für den Codevision Compiler, Du 
siehst da was von

#ifdef CODEVISION
...
#define F_CPU 8000000
...
#endif

Hier nützt eine Änderung gar nichts, wenn Du den WinAVR (gcc) als 
Compiler nutzt. In diesem Fall musst Du im Projekt unter

    Project -> Configuration Options

den Processor_ und die _Taktrate einstellen.

> 2. Timer Register geändert:

Sieht gut aus.

> 3. PD3 als Input:
>  * Change hardware pin here:

Korrekt.

> Habe aber etwas weiter oben im irmp.c das gefunden: static int PINB;
> Muss ich denn auch auf PIND ändern?

Das ist nicht für Dich relevant, da dieses Statement im Block

#ifdef DEBUG
...
#endif

eingebettet ist. Das ist nur zum Debuggen unter Linux oder Windows.

Gruß,

Frank

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Das mit F_CPU habe ich mir schon gedacht. Benutze GCC und habe in den 
Optionen Atmega8+12MHz eingestellt.

Sollte dann also passen, danke!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Eine neue Version von IRMP ist unter

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

verfügbar.

Änderungen:

1) Neues Protokoll: Apple

2) Bit-Order ist nun dem jeweiligen Protokoll angepasst.

Zu 1)

Das Apple-Protokoll ist bis auf eine Kleinigkeit identisch mit dem 
NEC-Protokoll und wird mit IRMP_SUPPORT_NEC_PROTOCOL == 1 erschlagen. 
Bisher wurde die Apple-FB immer als NEC-Protokoll ausgegeben, was aber 
eigentlich "gelogen" ist. Die Apple-FB hat daher jetzt einen eigenen 
Bezeichner IRMP_APPLE_PROTOCOL erhalten, damit der zukünftige Encoder 
IRSND den Apple-Frame wieder reproduzieren kann.

Zu 2)

Es hat hier schon einige gestört, dass bei Protokollen, welche das LSB 
zuerst ausgeben, die Tasten 1-9 scheinbar willkürliche Muster in 
irmp_data.command haben. Die gesendete Bitreihenfolge wird nun von IRMP 
berücksichtigt, bisher wurde immer mit MSB first gespeichert. Nun haben 
bei vielen FBs die Tasten 1-9 auch eine aufsteigende Reihenfolge in 
irmp_data.command. Dasselbe gilt natürlich auch für die Adresse.

Nachteil: Diejenigen, die Adressen und Kommandos von bestimmten 
Fernbedienungen bisher schon aufgezeichnet, gespeichert und verwendet 
haben, müssen das leider noch mal wiederholen, da nun für die 
LSB-Protokolle (siehe IRMP-Artikel) ganz andere Werte als bisher 
herauskommen. Sorry, aber Klaus Leidinger hat mich mittlerweile davon 
überzeugt, dass diese Lösung die bessere ist ;-)

Gruß,

Frank

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Änderungen:
>
> 1) Neues Protokoll: Apple

Für alle CV Nutzer: damit stimmt diese Sequenz im aktuellen Download für 
den CodeVision Teil natürlich nicht mehr. Ich werde das anpassen und 
Frank schicken.

@Frank: Du bist immer für eine Überraschung gut ;-)

Klaus

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Klaus Leidinger schrieb:
> @Frank: Du bist immer für eine Überraschung gut ;-)

Sorry, aber danke für Deine Anpassung in der main-Funktion des 
Codevision-Teils. Beim nächsten mal denke ich dran :-)

Den Download habe ich eben aktualisiert.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Eine neue Version von IRMP ist unter

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

verfügbar.

Grund:

Bugfix: Zurücksetzen der Statemachine nach einem unvollständigen 
RC5-Frame oder anderen "Schrott-Daten"

Der Fehler sorgte dafür, dass bei nachfolgenden Frames anderer 
Protokolle das Bit 6 im command prinzipiell immer gesetzt war. Durch 
Plausibilitätskontrollen wurden dann weitere empfangene Nicht-RC5-Frames 
verworfen oder falsch abgebildet - bis zum Reset des AVR oder bis wieder 
ein vollständiger RC5-Frame empfangen wurde.

Vielen Dank an Klaus Leidinger, der diesem Fehler durch unermüdliches 
nächtelanges Suchen auf die Spur kam :-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie bereits angekündigt, gibt es nun eine Alpha-Version von IRSND.

IRSND ist das Gegenstück zu IRMP: es reproduziert aus den Daten, die mit 
IRMP empfangen wurden, wieder den Original Frame, der dann über eine 
Infrarot-Diode ausgegeben werden kann.

IRSND unterstützt die folgenden Protokolle:

    * SIRCS
    * NEC
    * SAMSUNG
    * SAMSUNG32
    * MATSUSHITA
    * RECS80
    * RC5
    * DENON
    * APPLE

IRSND unterstützt folgende Protokolle (noch) nicht:

    * KASEIKYO
    * RC6


Näheres dazu steht im IRMP-Artikel, nämlich unter

  http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

Der Download-Link ist dort auch zu finden.

Vielen Dank an Klaus Leidinger, der mich bei der Entwicklung von IRSND 
tatkräftig als Tester unterstützt hat :-)

Gruß,

Frank

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich hätte da noch eine Frage zu dem Timer.

Ich habe Irmp mit V-USB kombiniert.

Bei einem PC geht es ohne Probleme, bei einem anderen PC wird der AVR 
nicht als USB-Gerät erkannt.

Durch testen habe ich rausgefunden, wenn ich den Timer-Init raus lasse, 
geht es:
int main(void)
{
uchar   i;


    wdt_enable(WDTO_2S);
    /* Even if you don't use the watchdog, turn it off here. On newer devices,
     * the status of the watchdog (on/off, period) is PRESERVED OVER RESET!
     */
    DBG1(0x00, 0, 0);       /* debug output: main starts */
    /* RESET status: all port bits are inputs without pull-up.
     * That's the way we need D+ and D-. Therefore we don't need any
     * additional hardware initialization.
     */
    odDebugInit();
    usbInit();
    usbDeviceDisconnect();  /* enforce re-enumeration, do this while interrupts are disabled! */
    i = 0;
    while(--i){             /* fake USB disconnect for > 250 ms */
        wdt_reset();
        _delay_ms(1);
    }
    usbDeviceConnect();

  //clear irmp_data
  irmp_data.protocol = 0;
  irmp_data.address = 0;
  irmp_data.command = 0;
  irmp_data.flags = 0;

  irmp_init();                                                              // initialize irmp code
  //timer_init();                                                             // initialize timer

    sei();

    DBG1(0x01, 0, 0);       /* debug output: main loop starts */
    for(;;){                /* main event loop */
        DBG1(0x02, 0, 0);   /* debug output: main loop iterates */
        wdt_reset();
        usbPoll();
    }
    return 0;
}

Wie kann ich das Problem umgehen? Danke!

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
vermutlich bekommst du probleme mit dem timing seitens usb, wenn die 
v-usb routinen vom timer interrupt unterbrochen werden.
die v-usb routinen müsstest du also mit cli()...sei() umklammern. ob das 
der funktion guttut, steht auf einem anderen blatt.

von Hugo P. (portisch)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Schaffe es einfach nicht!

Habe schon vieles Probiert - jedoch kein Erfolg.

Es geht Problemlos bei diesem Board:
http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2624

Bei diesem geht es nicht:
http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=3141

Im Anhang der derzeitige Source.
Atmega8 mit 12MHz Quarz.

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
ja, das wird ein timing-problem sein.
erstell doch einfach einen eigenen thread, das wird sicher noch ne 
längere angelegenheit.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> die v-usb routinen müsstest du also mit cli()...sei() umklammern. ob das
> der funktion guttut, steht auf einem anderen blatt.

Vermutlich geht das so nicht, weil die V-USB-Funktionen laut 
http://www.obdev.at/products/vusb/index-de.html einen "edge triggered 
interrupt" benötigen.

Da müsste man schon gezielt den Timer1-Interrupt ein-/ausschalten.

@Hugo: Klappt es denn mit der USB-Erkennung, wenn Du in irmp_ISR() einen 
vorzeitigen return einbaust?

Gruß,

Frank

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hm, wo steht das denn? ich hab nur das hier gefunden:
> No UART, timer, input capture unit or other special hardware is required

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> hm, wo steht das denn? ich hab nur das hier gefunden:
>> No UART, timer, input capture unit or other special hardware is required

Direkt in der Zeile darunter:

"No UART, timer, input capture unit or other special hardware is 
required (except one edge triggered interrupt)."

Gruß,

Frank

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
puh... dann nehm ich mal die tomaten runter ^^
sorry

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
@Hugo: Klappt es denn mit der USB-Erkennung, wenn Du in irmp_ISR() einen
vorzeitigen return einbaust?

Gruß,

Frank

Ja, wenn ich irmp_ISR(); auskommentiere dann geht es!

Das komische ist halt, dass an einem PC ohne Probleme geht.
An dem PC wo ich den Empfänger eigentlich einsetzen will geht es nicht 
:(

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Da ich leider den Beitrag nicht editieren kann:

V-USB benötigt ja die D+ Line auf einen Interrupt Pin. Am besten INT0.
Beim Atmega8 PD2.

Die TSOP1736 habe ich auf PD3 (INT1) gelegt.
Irmp braucht ja keinen Interrupt Pin da es ja mit Polling arbeitet, 
oder?
Vielleicht hilft es, wenn man einen anderen Port als PD3 verwendet?

von Sebastian___ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das problem beim V-USB ist, das ein anderer IRQ den externen IRQ für den 
USB um max 20µs verzögern darf. Dh. wenn man andere IRQs mit dem USB 
nutzen will muß man dafür sorgen das der USB IRQ immer möglichst ohne 
latenz abgearbeitet werden kann, sonst passt das timeing für die USB 
frames nicht mehr.
Das Polling vom usb in der Main ist unktitisch. Wichtig ist NUR das der 
externe IRQ für den USB immer sofort bearbeitet werden kann.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:

> Irmp braucht ja keinen Interrupt Pin da es ja mit Polling arbeitet,
> oder?

Richtig.

> Vielleicht hilft es, wenn man einen anderen Port als PD3 verwendet?

Nein, das wird nichts bringen. Aber da es mit dem einen Board geht und 
mit dem anderen nicht, liegt der AVR wohl knapp am Timing vorbei. 
Schalte doch mal in irmp.c diejenigen Protokolle ab, die Du nicht 
brauchst. Vielleicht hilft das schon... obwohl, solange kein IR-Signal 
reinkommt, macht die ISR auch so gut wie gar nichts.

Gruß,

Frank

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Man O Man, ich dreh noch durch!

Bei auskommentieren des irmp_ISR(); geht es bei beiden PCs.
Mit der Funktion geht es nur bei einem.

Auch ein "Abspecken" der IR-Funktionen auf NEC, RC5 & RC6 bringt nichts.

Kann man es irgendwie machen, dass der Timer1 erst ~ 2 Sekunden nach dem 
Reset/Boot gestartet wird?

Ich schätze einmal, das wenn nach dem Einstecken (Reset) das USB-Init 
mit dem Host vorbei ist es keine Probleme mehr geben sollte...

Danke!

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:

> Kann man es irgendwie machen, dass der Timer1 erst ~ 2 Sekunden nach dem
> Reset/Boot gestartet wird?

Dafür gibt es mehrere Möglichkeiten, zum Beispiel könntest Du 
timer_init() erst nach 2 Sekunden aufrufen, z.B. so:
  _delay_ms (2000);
  timer_init ();

> Ich schätze einmal, das wenn nach dem Einstecken (Reset) das USB-Init
> mit dem Host vorbei ist es keine Probleme mehr geben sollte...

Gruß,

Frank

von Hugo P. (portisch)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe es geschafft!

Dem _delay habe ich nicht getraut, da warscheinlich auch das USBPoll 
benötigt wird.

Ich starte nun den Timer0 beim Reset.
Nach 0xFF durchläufen wird Timer0 abgeschaltet und der Timer1 für das IR 
Polling gestartet.

Somit fängt der IR Timer erst ~5s nach dem Reset an.

AVR wird als USB Gerät erkannt und funktioniert einwandfrei!

Ist zwar nicht so schön geht aber nun!

Anbei das neue Projekt!

Danke für Hilfe und für Irmp!

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Hi, nochmal ich!

Kann die Beiträge einfach nicht editieren :(

Da es nun am zweiten PC läuft habe ich mir den Empfang der IR Codes 
angesehen.
Es geht sehr träge und es wird nicht jeder Code erkannt.

Beim anderen PC geht es ohne Probleme, schnelle Erkennung und es werden 
auch alle Tasten erkannt.

NEC wird z.B am 2. PC gar nicht erkannt.

Woran kann das jetzt noch liegen, oder wie kann ich dem Problem auf die 
Spur kommen?

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hugo Portisch schrieb:
> Habe es geschafft!
Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du 
den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und 
funktioniert es einwandfrei?

Hugo Portisch schrieb:
> Kann die Beiträge einfach nicht editieren :(
Das geht nur ein paar Minuten (10?) nach dem Verfassen eines Beitrages, 
danach nicht mehr.

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:
> Hugo Portisch schrieb:
>> Habe es geschafft!
> Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du
> den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
HID ist nicht zwingend eine tastatur oder maus.
siehe http://en.wikipedia.org/wiki/USB_human_interface_device_class

> Hugo Portisch schrieb:
>> Kann die Beiträge einfach nicht editieren :(
> Das geht nur ein paar Minuten (10?) nach dem Verfassen eines Beitrages,
> danach nicht mehr.
15 min sind es. und es geht auch dann nicht mehr, wenn jemand nach dem 
zu editierenden betrag etwas geschrieben hat.
dass der link zum editieren auch nach 15min noch angezeigt wird, ist ein 
(schon bekannter) fehler.

sry für den OTp

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir deinen Quelltext nicht im Detail angesehen: betreibst du
den AVR als USB-HID, sprich "Tastaturersatz"? Falls ja wofür und
funktioniert es einwandfrei?

Kein "Tastaturersatz"...

Per USB-Polling des AVRs können die Codes gelesen werden (Protokoll, 
Adress, Command & Flags). Er wird als USB-HID betrieben, somit sind 
keine Treiber notwendig.

Bei HID ist ein Feature Transfer von <=8 Bytes recht einfach. Die 
Struckt von Irmp sind ja nur 6Bytes ;).

Was man mit den Daten dann macht ist jedem selber überlassen.
Ich z.B. benütze es als Input-Plugin für DVBViewer.
Der AVR lernt auch den ersten empfangen Befehl. Per Flag kann dann 
dieser Befehl zum schalten eines Optokopplers verwendet werden um die 
Powertaste des PCs zu betätigen (Einschalten des PCs per Fernbedienung).
Werde dann noch eine Beispiel-Host Anwendung bereitstellen.

Man könnte aber auch ein Programm schreiben, dass die Codes in 
Tastendrücke umwandelt. So ist ja die Idee von Irmp.
Jedoch will ich das nicht im AVR machen, sondern auf der Host Seite.
Somit muss ich für neue Befehle den AVR nicht neu programmieren.

Ein kleines Update zu dem USB Problem bei dem einem Mainboard.
Ich glaube fast, dass es am USB von Mainbaord liegt.
Die Codes werden schon richtig vom AVR ausgewertet, jedoch funktioniert 
das Polling über USB nur sehr träge.

Beim anderen PC flutschen die Daten sofort rüber. Steuerung des 
DVBViewer geht Super.

Werde mir einmal eine PCI-USB Karte ausleihen, damit ich den Fehler 
weiter eingrenzen kann.

von Peter K. (peko)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

geniale Sache, dieses IRSND. Habe heute mal damit etwas rumgespielt und 
kann bestätigen, daß SIRCS funktioniert (andere Protos hab ich noch 
nicht getestet). Allerdings ist es ziemlich unempfindlich, kann sein daß 
es an meiner IR-Diode liegt oder aber am Timing. Zu weitergehenden 
Untersuchungen bin ich leider noch nicht gekommen.

Da einige Timerregister insbesondere beim Mega32 anders heißen und auch 
der Output-Pin anders liegt, habe ich mal in die beiden *.c - files ein 
paar "if defined" reingebaut. Es wäre schön, wenn du dies in deine 
sourcen übernehmen könntest, das würde helfen, die Software leicht auf 
einem Mega32 oder Mega644P (mit den beiden hab ich herumgespielt) laufen 
zu lassen. Weitere AVR-Typen könnte man bei Bedarf hinzufügen.
Die modifizierten sourcefiles sind hier angehängt.

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

Peter K. schrieb:

> Da einige Timerregister insbesondere beim Mega32 anders heißen und auch
> der Output-Pin anders liegt, habe ich mal in die beiden *.c - files ein
> paar "if defined" reingebaut.

Danke für Deine Vorschläge, werde ich so übernehmen.

Gruß,

Frank

von Hugo P. (portisch)


Bewertung
0 lesenswert
nicht lesenswert
Um nicht zu sehr Off-Topic zu werden habe ich einmal einen neuen Thread 
aufgemacht: Beitrag "Irmp + V-USB, geht nicht an jedem USB-Port"

Es geht um Irmp + V-USB, Probleme an verschiedenen USB-Ports.

von Christian F. (bleuicebox)


Bewertung
0 lesenswert
nicht lesenswert
IRMP löft auch auf einen PIC

danke für die Arbeit

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christian F. schrieb:
> IRMP löft auch auf einen PIC

Super! Kann man Deine Portierung irgendwie in den Source übernehmen? 
Wäre doch eine echte Bereicherung.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

irmp_ISR() macht mehrfach IRMP_PIN & (1 << IRMP_BIT) zu 
unterschiedlichen (Lauf-)Zeiten bei immer gleichen irmp_pulse_time. 
Außerdem geht der Code davon aus, dass der IR-Empfänger low-aktiv ist.

Ich würde den Code zum Einlesen aus irmp_ISR() herausziehen und den 
aktuellen Wert per Argument übergeben, z.B.:
--- Irmp.org/irmp.c     2010-03-07 11:54:40.000000000 +0100
+++ Irmp/irmp.c 2010-03-12 18:06:15.105627851 +0100
@@ -668,7 +668,7 @@
  *---------------------------------------------------------------------------------------------------------------------------------------------------
  */
 void
-irmp_ISR (void)
+irmp_ISR (const uint8_t data)
 {
     static uint8_t    irmp_start_bit_detected;                                  // flag: start bit detected
     static uint8_t    wait_for_space;                                           // flag: wait for data bit space
@@ -705,7 +705,7 @@
     {                                                                           // yes... wait for application to get data
         if (! irmp_start_bit_detected)                                          // start bit detected?
         {                                                                       // no...
-            if (!(IRMP_PIN & (1 << IRMP_BIT)))                                  // receiving burst?
+            if (!data)                                                          // receiving burst?
             {                                                                   // yes...
                 irmp_pulse_time++;                                              // increment counter
             }
@@ -734,7 +734,7 @@
         {
             if (wait_for_start_space)                                           // we have received start bit and are counting the dark...
             {
-                if (IRMP_PIN & (1 << IRMP_BIT))                                 // still dark?
+                if (data)                                                       // still dark?
                 {                                                               // yes
                     irmp_pause_time++;                                          // increment counter

@@ -1111,7 +1111,7 @@
             {                                                                   // counting the dark....
                 uint8_t got_light = FALSE;

-                if (IRMP_PIN & (1 << IRMP_BIT))                                 // still dark?
+                if (data)                                                       // still dark?
                 {                                                               // yes...
                     if (irmp_bit == complete_len && stop_bit == 1)
                     {
@@ -1368,7 +1368,7 @@
             }
             else
             {                                                                   // counting the light (pulse)...
-                if (!(IRMP_PIN & (1 << IRMP_BIT)))                              // still light?
+                if (!data)                                                      // still light?
                 {                                                               // yes...
                     irmp_pulse_time++;                                          // increment counter
                 }
diff -rBuw Irmp.org/irmp.h Irmp/irmp.h
--- Irmp.org/irmp.h     2010-03-05 11:24:18.000000000 +0100
+++ Irmp/irmp.h 2010-03-12 17:40:14.600896408 +0100
@@ -194,7 +194,7 @@
  *  ISR routine
  *  @details  ISR routine, called 10000 times per second
  */
-extern void                           irmp_ISR (void);
+extern void                           irmp_ISR (const uint8_t);

 #ifdef __cplusplus
 }

Der Aufrufer kann dann auch die Phase umkehren, falls der IR-Empfänger 
high-aktiv ist.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> irmp_ISR() macht mehrfach IRMP_PIN & (1 << IRMP_BIT) zu
> unterschiedlichen (Lauf-)Zeiten bei immer gleichen irmp_pulse_time.
> Außerdem geht der Code davon aus, dass der IR-Empfänger low-aktiv ist.

In meinem aktuellen Source ist es mittlerweile ein Makro. Das habe ich 
im Zusammenhang mit Christians PIC-Portiertung gemacht. Ich werde dafür 
sorgen, dass dieses Makro zukünftig nur noch einmal aufgerufen wird, 
nämlich am Anfang von irmp_ISR().

> Der Aufrufer kann dann auch die Phase umkehren, falls der IR-Empfänger
> high-aktiv ist.

Das kann er dann im Makro direkt tun.

Danke für die Anregung,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Eine neue Version von IRMP ist unter

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

verfügbar.

Zum einen ist die PIC-Portierung von Christian F. (blueicebox) in den 
Source eingeflossen, zum anderen habe ich die Anregung von eku 
übernommen, den Input-Pin nur noch an einer Stelle und immer zur 
gleichen Zeit abzufragen.

Vielen Dank an Christian für seine Tipps zur PIC-Portierung.

Gruß,

Frank

von Markus B. (mb27)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

könnte mir jemand einen Tip oder Code geben wie ich die drei Telegramme

1. ID für verwendetes Protokoll
2. Adresse bzw. Herstellercode
3. Kommando

auf meinem LCD ausgebe. Benutze das Programm von Peter Fleury.
So bekomme ich immer eine Fehlermeldung:
if (irmp_get_data (&irmp_data))
    {
    /* clear display and home cursor */
        lcd_clrscr();
        // ir signal decoded, do something here...

        // irmp_data.protocol is the protocol, see irmp.h
    lcd_puts(irmp_data.protocol);
        // irmp_data.address is the address/manufacturer code of ir sender
        lcd_puts(irmp_data.address);
        // irmp_data.command is the command code
        lcd_puts(irmp_data.command);

../../main.c:182: warning: passing argument 1 of 'lcd_puts' makes 
pointer from integer without a cast
muss ich hier itoa anwenden?

Bin Anfänger und sitze schon drei Tage dran und bekomms nicht hin.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Markus B. schrieb:
> ../../main.c:182: warning: passing argument 1 of 'lcd_puts' makes
> pointer from integer without a cast
> muss ich hier itoa anwenden?

lcd_puts möchte einen C-String, Du übergibst aber Zahlen. Das geht 
nicht. Also musst Du vorher die Zahlen in Strings - z.B. mit itoa() - 
umwandeln, z.B. so:
#include <stdlib.h>
...

main ()
{
   char protocol[10];
   char address[10];
   char command[10];

...
   if (irmp_get_data (&irmp_data))
   {
        itoa(irmp_data.protocol, protocol, 10);
        itoa(irmp_data.address, address, 10);
        itoa(irmp_data.command, command, 10);

        lcd_clrscr();
        lcd_puts(protocol);
        lcd_puts (" ");
        lcd_puts(address);
        lcd_puts (" ");
        lcd_puts(command);
   }

Das dritte Argument gibt die Zahlenbasis an. Eventuell ist es 
sinnvoller, address & command in Hex auszugeben statt dezimal. Dann muss 
das dritte Argument für itoa() 16 sein.

Gruß,

Frank

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
lcd_putS puttet einen string. was es als parameter erwartet ist eine 
adresse (pointer) zum ersten zeichen dieses strings, den es anzeigen 
soll.
was du übergibst, ist eine zahl.

du kannst also entweder deine zahlen zu einem string konvertieren (itoa) 
und dann anzeigen lassen.
oder du schaust mal, ob peter nicht genau für diesen falle eine funktion 
geschrieben hat, die zahlen aus einer variablen anzeigen lässt.

von Markus B. (mb27)


Bewertung
0 lesenswert
nicht lesenswert
Frank fettes Danke für die schnelle Antwort und für IRMP  :-)

von Michael M. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
:*-(

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe Probleme mit den Timer-Einstellungen auf einem Atmega8. Timer 1 
ist leider schon durch PWM belegt, so dass ich Timer 2 verwenden muss. 
Ich verwende als F_CPU 8Mhz (interner Takt).

Ich habe mit einer Universalfernbedienung getestet. Manche Protokolle 
kennt er anscheinend, auf andere reagiert er nicht.

Grundsätzlich die Frage: Geht das mit dem 8-Bit Timer überhaupt?

Hier meine Timer-Init mit Prescaler 8:
OCR2   =  ((F_CPU/8) / F_INTERRUPTS) - 1; // compare value: 1/10000 of CPU frequency/prescaler  = 99
  
TCCR2  |= (1 << WGM21); // switch CTC Mode on, 
TCCR2  |= (1 << CS20); 
TCCR2  |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21
  
TIMSK  |= (1 << OCIE2); // OCIE1A: Interrupt by timer compare

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:

> Ich habe mit einer Universalfernbedienung getestet. Manche Protokolle
> kennt er anscheinend, auf andere reagiert er nicht.

Welche Protokolle werden von IRMP erkannt, welche nicht?

> Grundsätzlich die Frage: Geht das mit dem 8-Bit Timer überhaupt?

Ja, solange er hinreichend genau geht.

> Hier meine Timer-Init mit Prescaler 8:
>
> OCR2   =  ((F_CPU/8) / F_INTERRUPTS) - 1; // compare value: 1/10000 of
> CPU frequency/prescaler  = 99
> 
> TCCR2  |= (1 << WGM21); // switch CTC Mode on,
> TCCR2  |= (1 << CS20);
> TCCR2  |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21
> 
> TIMSK  |= (1 << OCIE2); // OCIE1A: Interrupt by timer compare
> 

Das sieht eigentlich ganz gut aus...

Gruß,

Frank

von Werner B. (werner-b)


Bewertung
0 lesenswert
nicht lesenswert
Ich musste bei lsb in irsnd.c lange grübeln um herauszufinden was da 
erreicht werden soll (IMHO ist der Name auch irreführend).
Darum habe ich mir auch gleich eine (wenigstens für mich) leichter 
vertändliche Version gebastelt. Die hat auch ein besseres 
Laufzeitverhalten da für jedes Bit nur zwei mal geschoben wird. Die 
Bitschiebe-Orgie entfällt ;-).
static uint16_t
lsb (uint16_t x, uint8_t len)
{
#if 0
    uint16_t    xx = 0;
    uint8_t     i;

    for (i = 0; i < len; i++)
    {
        if (x & (1<<i))
        {
            xx |= (1<<(len - i - 1));
        }
    }
    return xx;
#else
    uint16_t    xx = 0;

    while(len)
    {
        xx <<= 1;
        if (x & 1)
        {
            xx |= 1;
        }
        x >>= 1;
        len--;
    }
    return xx;
#endif
}

von Chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe per Interrupt einen Pin "blinken" lassen und die Frequenz 
gemessen: Weit von 10khz entfernt. Durch Probieren kam ich auf OCR2=25.

Verstehe ich nicht. F_CPU stimmt auf jeden Fall, sonst würden andere 
Sachen auch nicht funktionieren.

Damit konnte ich folgende Protokolle empfangen:
Code: 9 Address: 0x00 Command: 0x00
Code: A Address: 0x2D2D Command: 0xA758
Code: 7 Address: 0x05 Command: 0x02
Code: 2 Address: 0xF708 Command: 0x02

Ein Preset auf der Fernbedienung wird nicht erkannt, wahrscheinlich ist 
das ein Exot.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Ich habe per Interrupt einen Pin "blinken" lassen und die Frequenz
> gemessen: Weit von 10khz entfernt. Durch Probieren kam ich auf OCR2=25.

Dein Denkfehler liegt wohl hier:

  TCCR2  |= (1 << CS20);
  TCCR2  |= (1 << CS21); //set prescaler to 8 mit cs20 und cs21

Damit wird der Prescaler lt. ATMega8-Datenblatt nicht auf 8, sondern auf 
32 gesetzt. Demnach müsste OCR2 dann 24 sein:

OCR2   =  ((F_CPU/32) / F_INTERRUPTS) - 1; // compare value: 1/10000 of

Mit Deinem empirisch ermittelte Wert von 25 lagst Du also schon fast 
richtig ;-)

Um den Prescaler auf 8 zu setzen, müsstest Du lediglich CS21 setzen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Werner B. schrieb:
> Ich musste bei lsb in irsnd.c lange grübeln um herauszufinden was da
> erreicht werden soll (IMHO ist der Name auch irreführend).

Nenne mir bitte einen besser geeigneten Namen, mir ist auch kein 
besserer eingefallen ;-)

> Darum habe ich mir auch gleich eine (wenigstens für mich) leichter
> vertändliche Version gebastelt. Die hat auch ein besseres
> Laufzeitverhalten da für jedes Bit nur zwei mal geschoben wird. Die
> Bitschiebe-Orgie entfällt ;-).

Wow, Deine Version spart wirklich einiges ein!

Vielen Dank, werde ich so übernehmen.

Gruß,

Frank

P.S.
Es gibt noch eine kürzere (und damit auch schnellere) Version:
static uint16_t
lsb_neu (uint16_t x)
{
   x = ((x >>  1) & 0x5555) | ((x <<  1) & 0xaaaa);
   x = ((x >>  2) & 0x3333) | ((x <<  2) & 0xcccc);
   x = ((x >>  4) & 0x0f0f) | ((x <<  4) & 0xf0f0);
   x = ((x >>  8) & 0x00ff) | ((x <<  8) & 0xff00);
   return x;
}

Nur arbeitet hat das Ding einen Nachteil: es arbeitet konstant mit der 
Länge 16 ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Da ich heute zufällig beim Durchforsten des Sources nach 
Optimierungsmöglichkeiten bemerkt habe, dass die RECS80-Startbit-Timings 
komplett falsch in IRMP definiert waren, habe ich die Timings nicht nur 
angeglichen, sondern auch noch zusätzlich die Erkennung des "RECS80 
Extended-Protokolls" eingebaut, damit ich endlich mal selbst ein paar 
Technisat-FBs von Pollin (für 95 Cent!), die den SAA3008 (und damit das 
RECS80EXT-Protokoll) benutzen, testen kann.

Vorab schon mal eine neue Version von IRMP unter

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

Die Erweiterung auf RECS80EXT kostete nur 50 Bytes im Binary, ist aber 
selbstverständlich - wie alle anderen Protokolle auch - abstellbar.

Und noch eine Neuigkeit:

Das kompilierte Binary von IRMP ist - trotz der Erweiterung auf 
RECS80EXT - durch diverse Code-Optimierungen, die ich in den letzten 
Tagen vorgenommen habe, nun ca. 350 Bytes kleiner geworden :-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
IRSND ist nun auch angepasst, Änderungen:

 - Korrektur der RECS80-Startbit-Timings
 - Neues Protokoll: RECS80 Extended
 - Diverse Codeoptimierungen, u.a. die von Werner, siehe oben.

Download:

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

Gruß,

Frank

von Werner B. (werner-b)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Nenne mir bitte einen besser geeigneten Namen, mir ist auch kein
> besserer eingefallen ;-)

z.B. bitsreverse

Edit:
  ich sehe gerade deinen Coding Style. Also besser bits_reverse.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Werner B. schrieb:

> z.B. bitsreverse

Sehr gut. Habe ich gerade übernommen. Ebenso noch eine Korrektur für 
TCCR2,
Dank an Werner. Download ist aktualisiert.

> Edit:
>   ich sehe gerade deinen Coding Style. Also besser bits_reverse.

Nö, die erste Version finde ich besser. Man kanns mit den Underscores 
auch übertreiben ;-)

Gruß,

Frank

von DiPi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In der Anwendung beim CRC wird diese Prozedur "reflect" genannt...

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
DiPi schrieb:
> In der Anwendung beim CRC wird diese Prozedur "reflect" genannt...

mirror() bzw. mirror_bits() habe ich auch schon mal gesehen, 
bitsreverse() finde ich aber am aussagekräftigsten.

Gruß,

Frank

von Peter K. (peko)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

habe heute die neuen IRMP für neue scans genutzt. Anbei 2 scans, einmal 
von meiner Kathrein UFS912 FB - ein RC6 Code. Da stimmt wohl irgendetwas 
noch nicht... Ich habe 2 Tasten jeweils 3mal einzeln gedrückt. Das 
Einzige, was sich im Command ändert, ist das LSB. Dies ist jedoch das 
Togglebit wie es mir scheint. Mehr ändert sich am Command nicht, egal 
welche Taste gedrückt wird. Auch bei RC5 Commands habe ich den Effekt 
beobachtet. Leider kann ich keinen RC5 scan machen weil der Controller 
abstürzt.

Der zweite scan in der zip ist ein bisher von IRMP nicht erkanntes 
Protokoll von einer Nubert (Lautsprecherhersteller) Subwoofer-FB.

Soviel für heute...

-Peter

von Peter K. (peko)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

hier noch ein Nachtrag zum Thema IRMP und IRSND: Habe einige Tests mit 
Kaseikyo (Panasonic Blue Ray) gemacht.
Die Commands werden weitestgehend stabil decodiert und angezeigt (Ob sie 
jedoch stimmen?). Wenn ich mit einer solchen IRMP_DATA Struktur den Code 
wieder mit IRSND aussende, passiert am Player nichs.
IRSND läuft dagegen gut und schaltet mein Samsung TV mit Samsung32 
Protocol ein. Auch SIRCS und NEC werden von IRSND zuverlässig erzeugt.

Gerne würde ich IRMP / IRSND mit RC6 nutzen, jedoch gibts da ja noch 
einige Problemchen - siehe meinen vorherigen post.

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

Peter K. schrieb:

> Die Commands werden weitestgehend stabil decodiert und angezeigt (Ob sie
> jedoch stimmen?). Wenn ich mit einer solchen IRMP_DATA Struktur den Code
> wieder mit IRSND aussende, passiert am Player nichs.

Siehe IRMP-Artikel:

http://www.mikrocontroller.net/articles/IRMP#IRSND_-_Infrarot-Multiprotokoll-Encoder

Zitat:

| IRSND unterstützt folgende Protokolle (noch) nicht:
|
|     * KASEIKYO
|     * RC6

Um aus den 32-bit-IRMP-Daten wieder das 48-Bit-Kaseikyo-Protokoll zu 
reproduzieren, ist noch ein wenig Gehirnschmalz bzw. Verständnis 
meinerseits bzgl. Kaseikyo notwendig. IRMP filtert aus dem 
Kaseikyo-Protokoll nur das raus, was zum Decodieren interessant ist, 
Parity-Bits und andere Infos gehen dabei verloren. Beim Encodieren 
braucht man sie dann aber wieder. Da muss ich noch ein wenig forschen, 
um die Parity-Bits und den Rest im IRSND wieder zu rekonstruieren: 32 
Bit IRMP -> 48 Bit Kaseikyo.

> IRSND läuft dagegen gut und schaltet mein Samsung TV mit Samsung32
> Protocol ein. Auch SIRCS und NEC werden von IRSND zuverlässig erzeugt.

Freut mich :-)

> Gerne würde ich IRMP / IRSND mit RC6 nutzen, jedoch gibts da ja noch
> einige Problemchen - siehe meinen vorherigen post.

RC6 ist ein komplexes System von variablen Modi: je nach RC6-Modus sind 
die RC6-Daten komplett anderes strukturiert. Im Moment ist RC6 ein 
erhebliches Problem, da IRMP im Moment nur den sogenannten Mode0 
unterstützt. Die Kathrein-FB benutzt aber einen anderen Mode - mit 
erheblich mehr Bits im Telegramm. Da sind dann nur spärliches Infos zu 
finden. Ich bin aber weiterhin dran.

Danke für die Scans, werde ich mir anschauen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter K. schrieb:

> Der zweite scan in der zip ist ein bisher von IRMP nicht erkanntes
> Protokoll von einer Nubert (Lautsprecherhersteller) Subwoofer-FB.

Ich habe mir das Protokoll angeschaut, das ist was ganz Neues, aber auch 
ziemlich triviales. Ich habe es mal eingebaut in den IRMP, verbrät 
zusätzliche 50 Bytes an Code, ist natürlich abschaltbar.

Wie die anderen Protokolle auch ist das "NUBERT-Protokoll" (so habe ich 
das mal getauft, solange es da keine Vergleichsvariante gibt) im 
IRMP-Artikel dokumentiert.

Es hat 1 Start-Bit + 10 Daten-Bits + 1 Stop-Bit und wird immer 2x 
gesendet.
Die Timings habe ich empirisch aus dem Scan ermittelt.

Die automatische Wiederholung wird von IRMP unterdrückt, eine 
Wiederholung durch langen Tastendruck wird von IRMP im Flags-Byte 
gekennzeichnet - so wie sich das gehört ;-)

Wie sich diese 10 Bit Daten in Adresse + Kommando aufteilen, weiß ich 
nicht, da ich keine Dokumentation dazu gefunden habe. Hat Deine 
Nubert-FB noch mehr Tasten? Deine 2 Tasten zur Analyse, wie sich Adresse 
und Kommando aufteilen, sind da als Vergleich ziemlich mager ;-)

Ich habe daher alle 10 Daten-Bits in das Kommando gelegt, d.h. als 
Adresse gibt IRMP immer 0 zurück.

Achja: Deine beiden Volume-Tasten senden das Kommando 0x0082 und 0x0084.

Neue Version von IRMP unter

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

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Nun gibt es auch eine neue Version von IRSND.

Download:

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

Änderungen:

* Neues Protokoll: Nubert

  Damit kann Peter nun seine Subwoofer auch über IRSND voll
  aufdrehen ;-)

* Korrektur der Pausen zwischen Wiederholungen von Frames

Gruß,

Frank

von Klaus L. (kllei)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

damit zur Software auch ein Stück Hardware zum ausprobieren kommt, habe 
ich heute mein kleines IR-LCD Projekt online gestellt.

Die Hardware basiert auf der IRMP und IRSND Software von Frank mit ein 
paar kleinen Erweiterungen. Die Software wird auch noch ein bischen 
wachsen ;-)

Schaut es Euch mal an, Feedback auch gerne hier im Forum, so lange es 
Frank nicht zu lästig wird ;-) sonst eröffne ich einen neuen Beitrag.

Viele Grüße und viel Spaß,
Klaus

Das komplette Projekt findet Ihr hier:
http://www.mikrocontroller-projekte.de -> IR-LCD

von Werner B. (werner-b)


Bewertung
0 lesenswert
nicht lesenswert
@Klaus Leidinger,

da IR Sendedioden (zumindest meine hier) im Impulsbetrieb bis zu 3A für 
10uS verkraften, kannst du R2 auf fast 1 Ohm verkleiner (Ich verwende 
1,2 Ohm).
Das erhöht die Reichweite beträchtlich. R3 begrenzt den Strom falls sich 
der AVR mal "aufhängt" (Wobei ich nicht verstehe warum die Sendediode 
und der TSOP beide hinter R3 liegen. Lieber den TSOP mit 100 Ohm an Vcc 
und die Sendediode mit ca. 40 Ohm direkt an Vcc und noch einen weiteren 
C spendieren).

Gruß
Werner

von Klaus L. (kllei)


Bewertung
0 lesenswert
nicht lesenswert
Werner B. schrieb:
> (Wobei ich nicht verstehe warum die Sendediode
> und der TSOP beide hinter R3 liegen. Lieber den TSOP mit 100 Ohm an Vcc
> und die Sendediode mit ca. 40 Ohm direkt an Vcc und noch einen weiteren
> C spendieren)

Senden und Empfangen wird ja nicht gleichzeitig benutzt, und die 
Sendediode soll ja aus dem Elko gespeist werden. Außerdem war es schon 
recht eng ;-)

Je nach Verwendungszweck ist ja eine unterschiedliche Bestückung 
machbar. Für eine Entwicklungsplattform war mir der Weg mit lieber "zu 
großen" Widerständen sicherer.

Reichweitentests habe ich noch nicht gemacht, ich werde aber gerne Deine 
/ Eure Erfahrungen dokumentieren.

Danke für Dein Feedback.

Viele Grüße,
Klaus

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Eine Frage zum Source von IRMP:
#define DEBUG_PUTCHAR(a)                        { if (! silent) { putchar (a);              } }
#define DEBUG_PRINTF1(a)                        { if (! silent) { printf (a);               } }
#define DEBUG_PRINTF2(a,b)                      { if (! silent) { printf (a,b);             } }
#define DEBUG_PRINTF3(a,b,c)                    { if (! silent) { printf (a,b,c);           } }
#define DEBUG_PRINTF4(a,b,c,d)                  { if (! silent) { printf (a,b,c,d);         } }
#define DEBUG_PRINTF5(a,b,c,d,e)                { if (! silent) { printf (a,b,c,d,e);       } }
#define DEBUG_PRINTF6(a,b,c,d,e,f)              { if (! silent) { printf (a,b,c,d,e,f);     } }
#define DEBUG_PRINTF7(a,b,c,d,e,f,g)            { if (! silent) { printf (a,b,c,d,e,f,g);   } }

Warum verwendest Du keine Variadic Macros 
(http://en.wikipedia.org/wiki/Variadic_macro) in der Form:
#define DEBUG_PRINTF(...)   {if (!silent) printf(__VA__ARGS__);}

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

> Warum verwendest Du keine Variadic Macros

Weil ich ein alter Knochen bin, der C 1984 unter UNIX kennengelernt 
habe. Die Variadic Macros gibt es erst seit 1999. Ich hatte es zwar mal 
am Rande mitbekommen, dann aber wieder verdrängt, da ich es damals nicht 
brauchte.

Ich werde es bei Gelegenheit umstellen, vielen Dank für den Hinweis.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!

Zwei meiner Fernbedienungen können nicht dekodiert werden:

 Nokia Dbox2
 Siemens Gigaset M740AV

Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1 
aufzeichne?

von Micha (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

was hältst du davon sämtliche Konfigurationsmöglichkeiten in eine 
separate Header-Datei (z.B. irmpconfig.h) auszulagern? Ich finde das 
momentan etwas unübersichtlich: jede Menge defines und diese dann auch 
noch im .h und im .c verteilt, so dass man (zumindest ich) nicht so 
recht weiß an welcher Schraube man drehen kann und was man besser so 
belassen sollte.

Ansonsten finde ich dieses Projekt großartig und möchte mich vielmals 
dafür bedanken.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
eku schrieb:
> Reicht für die Analyse wenn ich die UART-Ausgaben mit IRMP_LOGGING=1
> aufzeichne?

Ja, müsste reichen, am besten so viele Tasten wie möglich und dann in 
der Form:

# Taste 1
000011110000.......
# Taste 2
000011110000.......

Also pro Taste ein Kommentar, eingeleitet mit '#' und alle Tasten einer 
FB in derselben Datei.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Micha schrieb:

> was hältst du davon sämtliche Konfigurationsmöglichkeiten in eine
> separate Header-Datei (z.B. irmpconfig.h) auszulagern?

Ja, ist wohl sinnvoll. Mache ich.

Gruß,

Frank

von Christoph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wäre es nicht eine gute Idee den Sourcecode in das neue svn 
einzustellenß
Dann müsste man nicht immer den aktuelllen Sourcecode herunterladen.

von Peter K. (peko)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,

ich habe gestern mal bezüglich RC6 etwas im IRMP geforscht und komme mit 
dem Verhalten von IRMP irgendwie nicht klar. Dazu anbei die kleine 
Log-Datei. Ich habe mal jedes Bit, das irmp_store_bit bekommt, in ein 
Array schreiben lassen und schaue es mir nach empfangenen Code an.

Beim RC5 sieht das richtig gut aus, alle Bits kommen so wie sie sollen 
und man kann am Binärcode Adresse und Command gut erkennen.

Beim RC6 trudeln allerdings irgendwelche Bits herein, die ich mir 
überhaupt nicht erklären kann. Vor allem das Togglebit, das ja auch 
relativ weit vorne im RC6-Frame kommt erscheint, (wenn es das überhaupt 
ist...) erst an 21. Stelle.

Könntest Du da bitte etwas Aufklärungsarbeit leisten? Danke... ;)

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Peter K. schrieb:

> ich habe gestern mal bezüglich RC6 etwas im IRMP geforscht und komme mit
> dem Verhalten von IRMP irgendwie nicht klar.

Ich bin selbst nicht mit der Umsetzung des RC6-Protokolls im IRMP 
zufrieden. Es funktioniert zwar mit der RC6-Fernbedienung von Klaus 
Leidinger, welche im sog. "Mode 0" läuft, aber nicht mit RC6-FBs, die 
einen anderen Mode benutzen.

Der "Mode 0" ist hier dokumentiert:

http://www.sbprojects.com/knowledge/ir/rc6.htm

Dabei ist da was ganz fieses drin, nämlich:

"Finally the header is terminated by the trailer bit TR. Please note 
that the bit time of this symbol is twice as long as normal bits! This 
bit also serves as the traditional toggle bit, which will be inverted 
whenever a key is released. This allows the receiver to distinguish 
between a new key or a repeated key. "

Das Toggle-Bit ist also doppelt so breit wie die anderen Bits. Im 
Zusammenhang mit der Bi-Phase-Codierung haben dann die Pulse und die 
Pausen ganz blöde Längen, nämlich - je nach Nachbar-Bits(!) - die ein- 
oder 1,5-fache Länge. Das bringt den Code von IRMP arg ins Schleudern. 
Ich hatte das damals anhand der Scans von Klaus dann so "hingefrickelt", 
aber mir war klar, dass dieser Code nicht allgemeingültig funktionieren 
könne.

Mangels anderer RC6-Scans habe ich da aber nichts mehr weiter dran 
getan, hat mich schon so genug Nerven gekostet ;-)

Nun habe ich von Dir die Kathrein-Scans erhalten und musste einsehen, 
dass meine Art, wie ich Bi-Phase-Signale decodiere, an seine Grenzen 
stößt - was auch wieder mit der doppelten Länge des Toggle-Bits zu tun 
hat. Dieses folgt nämlich den sog. drei Mode-Bits. Und die haben bei Dir 
andere Werte - eben nicht "Mode 0". Und damit funktioniert die Art und 
Weise, wie ich die doppelte Länge des Toggle-Bits "behandle", nicht 
mehr.

Ich werde also den RC6-Part im IRMP neu schreiben müssen, so hat das 
keinen Zweck... einfach zu viel Code-Gebastel und Rumprobiererei.

> Beim RC5 sieht das richtig gut aus, alle Bits kommen so wie sie sollen
> und man kann am Binärcode Adresse und Command gut erkennen.

Ja, bei gleichen Signal-Längen (RC5) funktioniert der Code, bei 
wechselnden Bit-Breiten (RC6) macht er die Grätsche.

> Beim RC6 trudeln allerdings irgendwelche Bits herein, die ich mir
> überhaupt nicht erklären kann. Vor allem das Togglebit, das ja auch
> relativ weit vorne im RC6-Frame kommt erscheint, (wenn es das überhaupt
> ist...) erst an 21. Stelle.

Das sollte eigentlich überhaupt nicht auftauchen, da IRMP die 
Toggle-Bits (RC5 und RC6) ignoriert.

> Könntest Du da bitte etwas Aufklärungsarbeit leisten? Danke... ;)

Ich bin gerade an einem anderen Algorithmus für RC6 dran, habe Dich und 
Deine Kathrein-FB nicht vergessen. Allerdings wolltest Du mir noch Scans 
von einer weiteren Kathrein-FB zur Verfügung stellen, wenn ich das 
richtig in Erinnerung habe.

Achja: dass IRMP "zwischendurch" bei Deiner RC6-FB meint, da plötzlich 
RC5-Code zu erkennen, ist leicht erklärt: RC6 benutzt exakt die Hälfte 
der Bit-Breite von RC5, nämlich 444µs. Bei einer Bi-Phase-Codierung 
addieren sich dann oft die Pulse von 2 Nachbar-Bits auf die doppelte 
Breite - und damit exakt auf die Puls-Breite eines RC5-Bits von 889µs.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:
> Wäre es nicht eine gute Idee den Sourcecode in das neue svn
> einzustellenß

Danke für die Anregung, ich habe das direkt beantragt und auch schon 
einen Platz für IRMP auf dem SVN-Server von mikrocontroller.net von 
Andreas erhalten. Ich schiebe den Source demnächst ins SVN und melde 
mich dann nochmal dazu.

Trotzdem wird man die Sources auch weiterhin "klassisch" über den 
Download-Link herunterladen können.

> Dann müsste man nicht immer den aktuelllen Sourcecode herunterladen.

Das müsstest Du bei SVN ja auch ;-)

Die Verwendung eines SVN bietet eigentlich genau dann Vorteile, wenn 
mehrere Leute an einem Source arbeiten. Dafür ist es eigentlich gedacht 
- nicht zum Publizieren von Code. Das ist nur ein Seiteneffekt von SVN.

Gruß,

Frank

von eku (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank!


> Zwei meiner Fernbedienungen können nicht dekodiert werden:
>
>  Nokia Dbox2
>
>  Siemens Gigaset M740AV

LIRCD kennt die Siemens Gigaset Fernbedienung als

  bits           8
  eps            30
  aeps          100

  one             0     0
  zero            0     0
  pre_data_bits   24
  pre_data       0x10
  gap          210000
  min_repeat      2
  toggle_bit      25

von Peter K. (peko)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Frank,
danke für die prompte Antwort. Ja, die zweite Kathrein-FB... Die ist 
etwas ein Sorgenkind, wahrscheinlich ist es kein RC6 Code. Ich kann mit 
der neuesten Version von IRMP nichts scannen. IRMP in einer 
Test-Compilierung reagiert gar nicht darauf. Allerdings - und das ist 
merkwürdig, habe ich die gleiche IRMP-Version in meinem eigentlichen 
Projekt zusammen mit Softwaremodulen des U.Radig-Webservers compiliert. 
Dort zeigt IRMP an, dass diese FB RC5 machen würde. Allerdings reportet 
IRMP jedes Mal andere Cmd / Addr, so dass ich annehme, das da irgendwas 
in der Decodierung nicht stimmt. Leider ist bei diesem Projekt der RAM 
schon so voll, dass ich kein IRMP Logging mehr machen kann. Also komme 
ich momentan beim Scannen dieser 2. FB nicht so richtig voran. Mal 
schaun was ich da noch machen kann.

Hier nun auch noch ein allgemeiner Vorschlag von mir: Eine schöne 
Versionsnumerierung von IRMP / IRSND wäre gut, dann könnte man sich 
immer genau auf bestimmte Releases beziehen.

-Peter

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

Peter K. schrieb:

> Hier nun auch noch ein allgemeiner Vorschlag von mir: Eine schöne
> Versionsnumerierung von IRMP / IRSND wäre gut, dann könnte man sich
> immer genau auf bestimmte Releases beziehen.

Ja, hatte ich auch schon mal dran gedacht. Die nächste Version wird dann 
einfach mal 1.0 heißen ;-)

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi eku,

eku schrieb:

>> Zwei meiner Fernbedienungen können nicht dekodiert werden:
>>
>>  Nokia Dbox2
>>
>>  Siemens Gigaset M740AV
>
> LIRCD kennt die Siemens Gigaset Fernbedienung als
> [...]

Ich hatte Dir darauf schon mal geantwortet:

  Beitrag "Re: IRMP - Infrared Multi Protocol Decoder"

Schick mir einfach Scans und ich versuche, diese FBs einzubauen - 
entweder durch Vergrößerung der Toleranzen des jeweiligen (bekannten) 
Protokolls oder durch neue Parametrisierung.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
IRMP ist jetzt auch im SVN auf mikrocontroller.net:

http://www.mikrocontroller.net/svnbrowser/irmp/

Ich werde den Link auch noch in den IRMP-Artikel einfügen, den 
Download-Link im Artikel wird es aber auch weiterhin geben.

Gruß,

Frank

von Andreas S. (andreas) (Admin) Benutzerseite Flattr this


Bewertung
0 lesenswert
nicht lesenswert
Du kannst auch direkt auf einen aktuellen Snapshot als .tar.gz 
verlinken, dann musst du nicht von Hand ein Paket erstellen:
http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz schrieb:
> Du kannst auch direkt auf einen aktuellen Snapshot als .tar.gz
> verlinken, dann musst du nicht von Hand ein Paket erstellen:
> http://www.mikrocontroller.net/svnbrowser/irmp/?view=tar

Danke für den Tipp, hatte ich schon gesehen bzw. kenne ich schon aus 
anderen Open-Source-Projekten. Das tar.gz-Format ist in der Windows-Welt 
leider nicht so geläufig, mein Filzip kann damit jedenfalls nichts 
anfangen - erst wenn ich die Datei in .tgz umbenenne.

Wäre es auch möglich, den Tarball als "Zipball" zur Verfügung zu 
stellen? Dann wäre es ideal.

Gruß,

Frank

von M. K. (kichi)


Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Das tar.gz-Format ist in der Windows-Welt
> leider nicht so geläufig, mein Filzip kann damit jedenfalls nichts
> anfangen - erst wenn ich die Datei in .tgz umbenenne.

Mit 7-Zip funktioniert es auch unter Windows ohne Probleme.

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Das größere Problem an dem SVN repository ist, dass auf Top-Level-Ebene 
keine Ordner für Branches oder Tags angelegt wurden.

von Simon K. (simon) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen 
worden. Die Binaries und der Code für den PC könnte man doch in ein 
Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> Stimmt. Und leider sind alle Dateien lieblos in ein Verzeichnis geworfen
> worden. Die Binaries und der Code für den PC könnte man doch in ein
> Unterverzeichnis packen. Genauso mit dem AVR-spezifischen Code.

Es gibt keinen "Code für den PC" und auch keinen "AVR-spezifischen 
Code", der Source ist für beide derselbe. Das einzige, was hier 
PC-spezifisch ist, sind die beiden Executables irmp.exe bzw. irsnd.exe. 
Dafür bedarf es meiner Meinung nach keines Unterverzeichnisses.

Aber wie immer bei Simon K.: Er liest nur oberflächlich, stromert in 
vielen Threads herum, lässt seinen Mecker los und verschwindet dann 
wieder für Wochen auf Nimmerwiedersehen. Sowas kann ich nicht ernst 
nehmen.

Gruß,

Frank

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hi Vlad,

Vlad Tepesch schrieb:
> Das größere Problem an dem SVN repository ist, dass auf Top-Level-Ebene
> keine Ordner für Branches oder Tags angelegt wurden.

Hätte ich diese anlegen können/müssen? Das Repository hat Andreas 
Schwarz auf meine Bitte hin angelegt. Ich musste dann nur noch die 
Dateien reinschieben. Muss Andreas als SVN-Verwalter da was tun oder 
kann ich das auch als reiner "SVN-Anwender"?

Gruß,

Frank

von Vlad T. (vlad_tepesch)


Bewertung
0 lesenswert
nicht lesenswert
Um nicht noch mehr OT zu produzieren antworte ich dir privat

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.