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)
Gast
#1588887
Und dass funktioniert wirklich ?
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.
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?
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.
Anbei ein Bugfix. Ein kl. Fehler führte u.U. zu zusätzlich "erkannten" Bits. Jetzt noch stabilere Erkennung.
Wie kann ich die Buggy-Version von ganz oben löschen ?
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
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
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.
Gast
#3377311
Ach, ich dachte, http://www.mikrocontroller.net/articles/IRMP macht das auch per Hash. Stimmt aber nicht.
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.
Gast
#3668016
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?