Universeller IR-Receiver für viele Protokolle

[Frank B. (frank_boe)]

Anbei ein Stückchen Code zum IR-Empfang.
Es ist theoretisch für so gut wie alle Fernbedienungsprotokolle 
einsetzbar.

Die Idee dahinter:
Die Kenntnis des Übertragungsprokolls ist nicht notwendig, es kommt nur 
darauf an, für jede Taste auf der FB einen anderen Wert zu bekommen.

Das Programm misst die Hi-und Lo Zeiten der Übertragung, speichert sie 
in einer temporären Tabelle, normiert sie und wendet dann eine 
Hashfunktion (hier der Einfachheit halber CRC32, weil der STM32 das in 
Hardware kann, es gehen aber auch andere nicht zu einfache 
Hashfunktionen) darauf an.

Ergebnis ist ein 32-Bit Wert, der für jede Taste auf der FB anders ist.

Bei manchen Protokollen bekommt man mehrere Werte, das liegt an den 
Protokollen selbst. In diesem Fall einfach den ersten benutzen... :-)

Die Normierung ist der Knackpunkt, und noch verbesserungswürdig, 
allerdings gehen bereits jetzt sämtliche bei mir im Betrieb und in den 
Schubladen "endgelagerten" befindliche Fernbedienungen problemlos :-)
Das ein oder andere Protokoll wird sicherlich nicht funktionieren, aber 
das allermeiste geht, glaube ich.
Wichtig ist, daß das zur FB passende IR-Empfänger-IC benutzt wird (u.a. 
passende Trägerfrequenz) , andernfalls sinkt die Erkennungsrate 
drastisch.


Portierbar auf so gut wie jede andere CPU (nat. auch AVR), es braucht 
nur einen Eingangspin, einen Timer, sowie eine gute Hashfkt. 
(http://de.wikipedia.org/wiki/Hash)

[Name (Gast)]

Und dass funktioniert wirklich ?

[Frank B. (frank_boe)]

Name schrieb:
> Und dass funktioniert wirklich ?

Viel besser als man angesichts des kurzen Quelltextes glauben mag.

Bei meiner SIRCs (Sony) FB die ich hauptsächlich in meinem aktuellen 
Projekt verwende z.B. habe ich bisher keinen einzigen Empfangsfehler 
festgestellt.

Man kann das ganze noch geschickter mittels eines Input-Capture machen,
zugunsten einer leichteren portierbarkeit habe ich allerdings die 
Version ohne gepostet. Wenn die CPU viel mit anderen 
(höherpriorisierten) Interrupts zu hat, ist Input-Capture auf jeden Fall 
besser.

[Di P. (drpepper)]

auch ein interessanter ansatz, einfach garnicht zu erkennen, was der 
hersteller senden wollte, sondern nur pulse durch einen CRC32 wursteln.

Wie siehts da beim rc5-protokoll mit dem togglebit aus? das wird man 
doch eigentlich nicht einzeln erkennen können, oder?

[Frank B. (frank_boe)]

Di Pi schrieb:
> auch ein interessanter ansatz, einfach garnicht zu erkennen, was der
> hersteller senden wollte, sondern nur pulse durch einen CRC32 wursteln.
>
> Wie siehts da beim rc5-protokoll mit dem togglebit aus? das wird man
> doch eigentlich nicht einzeln erkennen können, oder?

Einzeln nicht. Wozu auch - wenn man will kann man das Toggelbit - das in 
einem anderen Rückgabewert (ir_getkeypress()) resultiert - auswerten.

Auch Wiederholungscodes sind so natürlich auswertbar - wenn man möchte.

[Frank B. (frank_boe)]

Anbei ein Bugfix.
Ein kl. Fehler führte u.U. zu zusätzlich "erkannten" Bits.
Jetzt noch stabilere Erkennung.

[Frank B. (frank_boe)]

Wie kann ich die Buggy-Version von ganz oben löschen ?

[Frank B. (frank_boe)]

Hier eine Hashfunktion, die auf einem AVR wesentlich schneller und 
kürzer als CRC32 ist, und für die IR-Routine ausreichend zu sein 
scheint:

Es handelt sich um einen abgespeckten Jenkins hash 
http://en.wikipedia.org/wiki/Jenkins_hash_function

int hash;

static inline void hash_reset(void) 
{
    hash=0;
}

static inline void hash_calc(uint32_t dat) 
{
    hash += dat;
    hash += (hash << 10);
    hash ^= (hash >> 6);
}

static inline uint32_t hash_get(void) 
{
    return hash;
}

[Tommy R. (tommy_r)]

Anbei der IR Code fuer STM32f4. Vielleicht erspart das dem ein oder 
anderen etwas Arbeit.

Die urspruengliche Version war etwas inkonsistent mit der Handhabung 
einiger Konstanten -> Ebenfalls geaendert (z.B. fixe Groesse TIM6)

Ist ausgelegt fuer Pin E9.

[Info (Gast)]

Ach, ich dachte, http://www.mikrocontroller.net/articles/IRMP macht das 
auch per Hash. Stimmt aber nicht.

[Frank B. (frank_b)]

Bin ja neugierig: Hat das jemand benutzt ?

Bin gerade dabei das für Arduino auf einem Teensy (ARM 96MHZ, 128KB 
Flash, 64KB RAM) umzubasteln.

Frank.

[hobbychemiker (Gast)]

Frank Boe schrieb:
> Hier eine Hashfunktion, die auf einem AVR wesentlich schneller und
> kürzer als CRC32 ist, und für die IR-Routine ausreichend zu sein
> scheint:

Fehlt da nicht eine schleife?